In questo post ho indicato come è possibile configurare il demone Syslog e l’agente OMS Linux al fine di reindirizzare i vari eventi che vengono rilevati dal Syslog, verso OMS in modo da poi essere analizzati con le funzioni di Log Analyzer.
Vedremo ora come è possibile configurare il logging del DB Oracle e combinarlo con le configurazioni descritte sopra in modo da inviare gli eventi di security del Database verso OMS.
Premessa
- Oracle permette di reindirizzare i propri eventi verso Syslog soltanto dalla versione 10.2.0 nelle precedenti versioni questa funzione non era disponibile.
- Il parametro NON è modificabile “a caldo “ ma richiede un riavvio dell’istanza.
- di default questa funzione non è attivata
Configurazione del DB
Per prima cosa è necessario attivare il logging del DB (se già non lo fosse) tramite il parametro
AUDIT_TRAIL
Questo parametro abilita il database ad effettuare logging e le opzioni disponibili sono:
none
log disabilitato
os
abilita il log verso il Sistema operativo
db
abilita il log verso il DB stesso nella tabella di Sistema SYS.AUD$
db,extended
abilita il log come il precedente ma vengono anche populate le colonne SQLBIND e SQLTEXT CLOB nella tabella SYS.AUD$
xml
abilita l’auditing verso un file XML di sistema
xml,extended
come il precedente ma vengono archiviati anche I valori SqlText and SqlBind
nel nostro caso abiliteremo il log verso il sistema operativo con il comando
- alter system set audit_trail=’OS’ scope=spfile
è necessario specificare come scope SPFILE in quanto l’impostazione deve essere mantenuta a seguito di un riavvio dell’istanza
Successivamente si dovrà definire come Oracle invia i messaggi al Syslog in modo conforme alle specifiche RFC analizzate nel post citato prima.
È possibile utilizzare le varie Facilities a seconda dell’impostazione del Syslog, è possibile, ad esempio utilizzare la Facility LOCAL per differenziare I messaggi provenienti da Oracle rispetto a quelli del sistema, anche in questo caso è necessario specificare lo scope come fatto sopra.
- alter system set audit_syslog_level=’local0.info’ scope=spfile
Dopo il riavvio dell’istanza le impostazioni di logging diventeranno operative
Configurazione del demone Syslog
A questo punto è necessario modificare il file rsyslog.conf in modo da reindirizzare i messaggi della facility Local0 verso l’agent OMS che è configurato come gateway verso il servizio in Cloud
- local0.* @@10.0.0.38:2554
Interrogazione degli eventi dal Portale di Operations Management
Dal portale OMS effettuando una ricerca con ProcessName=Oracle è possibile evidenziare tutti gli eventi relativi ad Oracle in archivio.
Come si vede sopra è indicata anche la Facility utilizzata per la comunicazione Oracle–>Syslog
Analizzando più in dettaglio un messaggio archiviato possiamo rilevare le seguenti informazioni
- nome dell’host DB
- utente DB che ha effettuato l’accesso
- nome del terminale/pc da cui è stato effettuato l’accesso
- sorgente di autenticazione per il DB (interno esterno etc.) e ip da cui è stata originata la richiesta
- nome utente sulla postazione ( di Sistema Operativo)
- processo che ha generato il messaggio Syslog
Riferimenti:
https://docs.oracle.com/cd/B19306_01/server.102/b14237/initparams016.htm#REFRN10006
http://docs.oracle.com/cd/B28359_01/server.111/b28320/initparams016.htm#REFRN10263
https://docs.oracle.com/cd/B28359_01/network.111/b28531/auditing.htm#DBSEG006
un grazie particolare a Roberto Marinello @matrix975 per la preziosa collaborazione sull’ambiente Oracle
Appunti e note tecniche 