Parameter: AUDIT_SYSLOG_LEVEL

Denne parameteren er delvis udokumentert, og mye mer nyttig enn bruken skulle tilsi. Hvor mange DBA-er kjenner og bruker denne parameteren? Svært få vil jeg anta. Jeg må nok innrømme at jeg også alt for sjeldent har benyttet denne parameteren aktivt, og at den derfor har gått litt i glemmeboken. Jeg kom over parameteren igjen i en bok jeg leser, og tenkte jeg skulle friske litt opp i gamle kunnskaper. Så hva kan vi utrette med AUDIT_SYSLOG_LEVEL?

Dokumentasjonen til Oracle sier følgende om parameteren: “AUDIT_SYSLOG_LEVEL tillatter SYS og standard OS audit records å bli skrevet til system audit logg ved å bruke SYSLOG verktøyet.”

Kanskje ikke til å bli helt klok av, men jeg skal prøve å forklare litt i denne artikkelen.
Hensikten med parameteren er at man skal kunne monitorere/logge handlinger utført av SYS og/eller database administratorer. Vi skal også se at det fra og med versjon 10g, har blitt mulig å skrive disse loggene til UNIX operativ systemets syslog deamon som er eid av root-brukeren. Dermed kan vi unngå at database brukere med utvidete rettigheter, sletter spor som de selv har lagt igjen i den aktuelle loggen. Det er dette som gjør denne parameteren svært nyttig.

I et default oppsett så logges CONNECT, STARTUP, og SHUTDOWN via SYSDBA eller SYSOPER privilegier til filer eid av oracle brukeren (som eier programvaren). SQL og PL/SQL kall, og andre aktiviteter med f.eks. DBA rollen, blir dermed ikke monitorert. Dette betyr at standard monitorering (se henholdsvis parameteren AUDIT_TRAIL) og “fine grained auditing” (se pl/sql pakken DBMS_FGA) er default slått av.

Problemet med den tradisjonelle overvåkningen (“standard auditing” via AUDIT_TRAIL) er at det har vært mulig for priviligerte brukere å slette i loggene. Standard monitorering setter man enten AUDIT_TRAIL=OS eller AUDIT_TRAIL=DB. Parameteren satt til “OS” gjør at audit trails (logg innslag) skrives til operativsystem filer eid av oracle-brukeren, mens når “DB” er satt skrives det til database tabellen SYS.AUD$. Begge disse kan endres/slettes av brukere med fortrinnsvis tilgang til oracle-brukeren eller DBA tilgang mot databasen. Monitorering via UNIX syslog funksjonaliteten gir mye høyere grad av sikkerhet og beskyttelse av loggene. Disse loggene er eid av root. For å øke sikkerheten ytterligere, kan man også vurdere å overføre logginnslagene til en alternativ node/instans. Dette er ikke gjenstand for diskusjon i denne artikkelen.
(AUDIT_SYSLOG_LEVEL og AUDIT_FILE_DEST er ikke implementert under Windows. Under Windows bruker man i stedet Windows Event Log)

AUDIT_TRAIL kan settes ved følgende kommando:

SQL> ALTER SYSTEM SET AUDIT_TRAIL={ none | os | db | db,extended | xml | xml,extended } scope=spfile;

Verdier:
none - auditing slått av
os - audit trail skrives til OS fil (eid av oracle brukeren)
db - audit trail skrives til SYS.AUD$
db,extended - I tillegg til den vanlige informasjonen som skrives til SYS.AUD$, 
     skrives det også til SQLBIND og SQLTEXT CLOB kolonnene i samme tabell
xml - audit trail skrives til XML format OS filer
xml, extended - audit trail skrives til XML format OS filer, inkludert SQLTEXT og SQLBIND verdier

Ingen av de nye valgene fra og med 10g (“db,extended”, “xml” eller “xml, extended”) gir utvidet sikkerhet.

Fra og med Oracle versjon 10g fikk vi muligheten til å skrive audit trails til syslog deamon på UNIX baserte systemer. Denne funksjonaliteten består av en deamon prosess med navn syslogd:

oracle> man syslogd

På min ubuntu linux installasjon (Ubuntu 10.04) er syslog byttet ut med den nyere rsyslog, som har en del utvidet funksjonalitet fremfor syslog.

oracle> man rsyslogd
NAME
       rsyslogd - reliable and extended syslogd

SYNOPSIS
       rsyslogd [ -4 ] [ -6 ] [ -A ] [ -d ] [ -f config file ]
       [ -i pid file ] [ -l hostlist ] [ -n ] [ -N level ]
       [ -q ] [ -Q ] [ -s domainlist ] [ -u userlevel ] [ -v ] [ -w ] [ -x ]

DESCRIPTION
       Rsyslogd  is a system utility providing support for message logging.  
       Support of both internet and unix domain sockets enables this utility 
       to support both local and remote logging.
      ...

Jeg fant følgende link som gir en god inføring i hvordan man blant annet kan benytte rsyslog:

Logging syslog and database audit messages to an oracle database with rsyslog

Hvis jeg sjekker mitt default oppsett på min 11g R2 database, ser jeg følgende:

oracle> sqlplus system
...
SQL> show parameter audit

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest 		     string	 /u01/app/oracle/admin/ORCL/adu
						 mp
audit_syslog_level		     string
audit_sys_operations		     boolean	 FALSE
audit_trail			     string	 DB
SQL> conn /as sysdba
Tilkoblet.
SQL> select to_char(sysdate,'DD.MM.YYYY HH24:MI') from dual;

TO_CHAR(SYSDATE,
----------------
26.03.2011 22:03

Selv om AUDIT_TRAIL er satt til “DB”, ser vi allikevel at det dukket opp en ny fil under AUDIT_FILE_DEST:

oracle@ubuntu:~$ cd /u01/app/oracle/admin/ORCL/adump
oracle@ubuntu:/u01/app/oracle/admin/ORCL/adump$ ls -ltr
...
-rw-r----- 1 oracle oinstall  746 2011-03-25 22:13 orcl_ora_1649_2.aud
-rw-r----- 1 oracle oinstall  747 2011-03-25 22:13 orcl_ora_1856_3.aud
-rw-r----- 1 oracle oinstall  751 2011-03-25 22:13 orcl_ora_2230_1.aud
-rw-r----- 1 oracle oinstall  756 2011-03-26 21:58 orcl_ora_6361_1.aud

oracle@ubuntu:/u01/app/oracle/admin/ORCL/adump$ cat orcl_ora_6361_1.aud
Audit file /u01/app/oracle/admin/ORCL/adump/orcl_ora_6361_1.aud
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1
System name:	Linux
Node name:	ubuntu
Release:	2.6.32-30-generic
Version:	#59-Ubuntu SMP Tue Mar 1 21:30:46 UTC 2011
Machine:	x86_64
Instance name: ORCL
Redo thread mounted by this instance: 1
Oracle process number: 41
Unix process pid: 6361, image: oracle@ubuntu (TNS V1-V3)

Sat Mar 26 21:58:29 2011 +01:00
LENGTH : '160'
ACTION :[7] 'CONNECT'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/3'
STATUS:[1] '0'
DBID:[10] '1271859933'

oracle@ubuntu:/u01/app/oracle/admin/ORCL/adump$ 

Da jeg testet med AUDIT_TRAIL satt til “none” (og ellers de samme verdiene som over), fikk jeg det samme resultatet. Audit trail for CONNECT osv ble skrevet til AUDIT_FILE_DEST.

Så gjør jeg noen nye parameter endringer:

SQL> conn /as sysdba
Tilkoblet.
SQL> alter system set audit_trail="DB" scope=spfile; -- Setter denne tilbake etter test med "none"

Endret system.


SQL> alter system set audit_syslog_level="USER.NOTICE" scope=spfile; -- Slår på audit mot rsyslogd

Endret system.

SQL> shutdown immediate;
Databasen er lukket.
Databasen er demontert.
ORACLE-forekomsten er avsluttet.
SQL> startup
ORACLE-forekomsten er startet.

Total System Global Area 2137886720 bytes
Fixed Size		    2228200 bytes
Variable Size		 1442840600 bytes
Database Buffers	  687865856 bytes
Redo Buffers		    4952064 bytes
Databasen er montert.
Databasen er ?pnet.
SQL> conn /as sysdba
Tilkoblet. 

Hvis vi da ser på rsyslogd loggene ser vi:

root@ubuntu:/var/log# grep DATABASE *
messages:Mar 26 23:13:27 localhost Oracle Audit[12389]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
messages:Mar 26 23:16:31 localhost Oracle Audit[12573]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
syslog:Mar 26 23:16:31 localhost Oracle Audit[12573]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
user.log:Mar 26 23:13:27 localhost Oracle Audit[12389]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
user.log:Mar 26 23:16:31 localhost Oracle Audit[12573]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
root@ubuntu:/var/log# 

Så endrer jeg også AUDIT_TRAIL:

SQL> alter system set audit_trail="OS" scope=spfile;

Endret system.

SQL> shutdown immediate;
...
ORACLE-forekomsten er avsluttet.
SQL> startup
...
Databasen er ?pnet.
SQL> conn /as sysdba
Tilkoblet.

Så sjekkes rsyslogd filene igjen:

messages:Mar 26 23:13:27 localhost Oracle Audit[12389]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
messages:Mar 26 23:16:31 localhost Oracle Audit[12573]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
...
messages:Mar 26 23:26:22 localhost Oracle Audit[13429]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
syslog:Mar 26 23:16:31 localhost Oracle Audit[12573]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
syslog:Mar 26 23:25:15 localhost Oracle Audit[12573]: LENGTH : '149' ACTION :[8] 'SHUTDOWN' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[0] '' 
syslog:Mar 26 23:26:09 localhost Oracle Audit[13128]: LENGTH : '155' ACTION :[7] 'STARTUP' DATABASE USER:[1] '/' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[13] 'Not Available' STATUS:[1] '0' DBID:[0] '' 
syslog:Mar 26 23:26:09 localhost Oracle Audit[13285]: LENGTH : '148' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[0] '' 
syslog:Mar 26 23:26:17 localhost Oracle Audit[13381]: LENGTH: "339" SESSIONID:[5] "57864" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[6] "SYSMAN" USERHOST:[6] "ubuntu" TERMINAL:[7] "unknown" ACTION:[3] "100" RETURNCODE:[1] "0" COMMENT$TEXT:[96] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=12931))" OS$USERID:[6] "oracle" DBID:[10] "1271859933" PRIV$USED:[1] "5"
syslog:Mar 26 23:26:18 localhost Oracle Audit[13387]: LENGTH: "316" SESSIONID:[5] "57866" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[6] "DBSNMP" USERHOST:[6] "ubuntu" ACTION:[3] "100" RETURNCODE:[1] "0" COMMENT$TEXT:[96] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=12935))" OS$USERID:[6] "oracle" DBID:[10] "1271859933" PRIV$USED:[1] "5"
user.log:Mar 26 23:13:27 localhost Oracle Audit[12389]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
user.log:Mar 26 23:16:31 localhost Oracle Audit[12573]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
user.log:Mar 26 23:25:15 localhost Oracle Audit[12573]: LENGTH : '149' ACTION :[8] 'SHUTDOWN' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[0] '' 
user.log:Mar 26 23:26:09 localhost Oracle Audit[13128]: LENGTH : '155' ACTION :[7] 'STARTUP' DATABASE USER:[1] '/' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[13] 'Not Available' STATUS:[1] '0' DBID:[0] '' 
user.log:Mar 26 23:26:09 localhost Oracle Audit[13285]: LENGTH : '148' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[0] '' 
user.log:Mar 26 23:26:14 localhost Oracle Audit[13344]: LENGTH : '159' ACTION :[7] 'CONNECT' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
user.log:Mar 26 23:26:16 localhost Oracle Audit[13373]: LENGTH: "339" SESSIONID:[5] "57861" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[6] "SYSMAN" USERHOST:[6] "ubuntu" TERMINAL:[7] "unknown" ACTION:[3] "100" RETURNCODE:[1] "0" COMMENT$TEXT:[96] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=12927))" OS$USERID:[6] "oracle" DBID:[10] "1271859933" PRIV$USED:[1] "5"
user.log:Mar 26 23:26:17 localhost Oracle Audit[13377]: LENGTH: "316" SESSIONID:[5] "57862" ENTRYID:[1] "1" STATEMENT:[1] "1" USERID:[6] "DBSNMP" USERHOST:[6] "ubuntu" ACTION:[3] "100" RETURNCODE:[1] "0" COMMENT$TEXT:[96] "Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=12928))" OS$USERID:[6] "oracle" DBID:[10] "1271859933" PRIV$USED:[1] "5"

Nå ser vi at vi har fått flere logg innslag i rsyslogd. Blant annet ser vi klient innslag fra DBSNMP og SYSMAN. Dette er fortrinnsvis agent og dbconsole klienter som automatisk logger på mot databasen.

En annen parameter er AUDIT_SYS_OPERATIONS. Hvis vi setter denne til TRUE vil alle aksjoner utført med SYS bli logget. En liten test viser følgende:

SQL> show parameter audit

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest 		     string	 /u01/app/oracle/admin/ORCL/adu
						 mp
audit_syslog_level		     string	 USER.NOTICE
audit_sys_operations		     boolean	 FALSE
audit_trail			     string	 OS
SQL> conn /as sysdba
SQL> select * from lj.t;

	ID MY_TEXT
---------- ------------------------------
       100 ORA$BASE
       116 DUAL
       117 DUAL
      ...
       200 TEST

11 rader valgt.

SQL> delete from lj.t;

11 rader slettet.

SQL> rollback;

Tilbakestilling fullf?rt.

Hvis vi nå ser i syslog filene finner vi ingen spor etter slettingen:

root@ubuntu:/var/log# grep Oracle * | grep delete 
root@ubuntu:/var/log#

Så setter jeg AUDIT_SYS_OPERATIONS til TRUE:

SQL> alter system set audit_sys_operations=TRUE scope=spfile;

Endret system.

SQL> shutdown immediate;
...
ORACLE-forekomsten er avsluttet.
SQL> startup
...
Databasen er ?pnet.
SQL> show parameter audit

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest 		     string	 /u01/app/oracle/admin/ORCL/adu
						 mp
audit_syslog_level		     string	 USER.NOTICE
audit_sys_operations		     boolean	 TRUE
audit_trail			     string	 OS
SQL> delete from lj.t;

11 rader slettet.

SQL> rollback;

Tilbakestilling fullf?rt.

Hvis vi nå sjekker syslogd filene, ser vi at vi nå har fått slått på monitorering av alle SYS aktiviteter:

root@ubuntu:/var/log# grep Oracle * | grep delete
messages:Mar 27 00:13:04 localhost Oracle Audit[17764]: LENGTH : '169' ACTION :[16] 'delete from lj.t' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
syslog:Mar 27 00:13:04 localhost Oracle Audit[17764]: LENGTH : '169' ACTION :[16] 'delete from lj.t' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
user.log:Mar 27 00:13:04 localhost Oracle Audit[17764]: LENGTH : '169' ACTION :[16] 'delete from lj.t' DATABASE USER:[1] '/' PRIVILEGE :[6] 'SYSDBA' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/3' STATUS:[1] '0' DBID:[10] '1271859933' 
root@ubuntu:/var/log# 

Hva har vi så lært av dette?

  1. CONNECT, STARTUP og SHUTDOWN med SYSDBA (eller SYSOPER) rettigheter, blir automatisk logget til AUDIT_FILE_DEST og *.aud filer. Dette skjer selv om AUDIT_TRAIL er satt til “none”.
  2. Hvis vi slår på AUDIT_SYSLOG_LEVEL vil fremdeles alle aktiviteter som skal logges når vi ikke har en åpen instans, logges til AUDIT_FILE_DEST (f.eks. STARTUP). Mens alle aktiviteter som skjer når vi har en åpen instans logges til syslog.
  3. Ved å sette AUDIT_SYSLOG_LEVEL og AUDIT_SYS_OPERATIONS=TRUE får vi slått på monitorering av SYS til syslog filene. Dette er faktisk uavhengig av hva AUDIT_TRAIL er satt til (ikke vist her, men dette kan dere jo selv teste ut).
  4. Ved logging til syslogd eller rsyslogd vil man ikke kunne slette audit trails uten root tilgang. Dette er en viktig forbedring, når vi sammenligner med standard auditing som skriver til AUDIT_FILE_DEST eller SYS.AUD$.
  5. Det vil fremdeles være mulig for en bruker med oracle-bruker tilgang eller SYSDBA tilgang å endre AUDIT_SYSLOG_LEVEL settingene. Men dette vil kreve en restart av databasen, og vil ved bruk av spfile også bli logget.
  6. Ved vedlikeholdsarbeid (maintenance) mot databasen anbefales det å sette AUDIT_SYS_OPERATIONS=FALSE, for å unngå svært store syslog logg filer.

Post a Comment

Your email is never published nor shared. Required fields are marked *