Paramètre 10g AUDIT_SYSLOG_LEVEL [Résolu]

[LeoAnderson]

Bonjour,

la doc est assez laconique au sujet de ce paramètre qui me semble pourtant très intérêssant.
http://download.oracle.com/docs/cd/B...5.htm#sthref90

AUDIT_SYSLOG_LEVEL enables OS audit logs to be written to the system via the SYSLOG utility if the AUDIT_TRAIL parameter is set to os.

The value of facility can be any of the following: USER, LOCAL0-LOCAL7, SYSLOG, DAEMON, KERN, MAIL, AUTH, LPR, NEWS, UUCP or CRON.

The value of level can be any of the following: NOTICE, INFO, DEBUG, WARNING, ERR, CRIT, ALERT, EMERG .

If you use this parameter, it is best to assign a file corresponding to every facility.level combination (especially kern.emerg) in syslog.conf . Sometimes these are assigned to print to the console in the default syslog.conf file. This can become annoying and will be useless as audit logs.Also, if you use this parameter, it is best to set the maximum length of syslog messages in the system to 512 bytes.

Quelqu'un a-t-il déjà joué avec ?

Merci de vos retours d'expérience.

Leo.

[orafrance]

Si j'ai bien compris ça permet de mettre dans un fichier différent de /etc/syslog.conf les messages OS spécifique aux process Oracle c'est bien ça ?

[LeoAnderson]

presque !

ça permet d'écrire le résultat de l'audit, quand il est vers l'OS, non pas vers les fichiers de audit_file_dest mais dans le log system standard unix /var/log/syslog

de fait, les logs d'audits ne sont plus accessibles par le DBA mais par root, ce qui est mieux (car centralisé, plus sécurisé et ça ne fait pas un log de plus à surveiller)

mais j'ai pas réussi à écrire dans un seul fichier de /var/log

[edit]
Avec LOCAL0.WARNING, ça m'écrit dans /var/log/sshd
pourquoi ???
pourquoi SSHD ?

et pourquoi SYSLOG.WARNING n'écrit plus null part ???
[/edit]

[orafrance]

Ha... regardes : http://download.oracle.com/docs/cd/B....htm#sthref809

When operating system auditing is enabled, set the AUDIT_SYSLOG_LEVEL initialization parameter to a valid value and configure /etc/syslog.conf so that Oracle OS audit records are written to a separate file.

et :

Setting the AUDIT_SYSLOG_LEVEL initialization parameter to the default value (NONE) will result in DBAs gaining access to the OS audit records.

je comprends donc le contraire : les logs systèmes sont accessibles au DBA qui n'a pas besoin d'être root

[LeoAnderson]

disons que si tu n'utilises pas ça, les logs d'audit sont des fichiers textes générés par la base.
Ils appartiennent donc au compte propriétaire des binaires et donc, le dba a accès a ce compte et/ou les fichiers appartienent au groupe dba. Donc le dba peut les lire, mais surtout les effacer.

tandis qu'avec ça, les syslog appartiennent à root, qui peut autoriser ou non le dba à les lire, mais certainement pas y écrire.
Donc les logs d'audits sont sécurisés. Si le DBA se fait craquer, l'info sera tracée et il faudra craquer root pour effacer les traces

[orafrance]

Mais là il est question des logs OS quand c'est activé sous Unix. Donc avec ou sans ce paramètre tu auras bien une log qui trace les événements OS. En revanche ce paramètre permet de mettre à part ce qui concerne spécifiquement Oracle.

Je ne vois pas dans la doc ce qui pourrait ressembler à ce que tu décris D'autant que si DBA se fait craquer... bah il change le paramètre donc ça sert à rien

[LeoAnderson]

Code :

1
2
3
4
5
6
7
8
Si audit_trail=OS ALORS
   SI AUDIT_SYSLOG_LEVEL defini ALORS
      Les logs vont dans /var/log
   SINON
      les logs vont dans AUDIT_FILE_DEST
SINON
   Les logs vont en base ou nul part
FIN SI

et avec LOCAL0.WARNING, j'écrit bien mes traces d'audit dans /var/log/sshd
ce que je comprends pas, c'est pourquoi sshd et que vient faire le warning ou quoi ?

par ailleurs, si le dba est craqué, le seul moyen de modifier l'audit, c'est d'arrêter/relancer la base.
mais il est trop tard, les logs sont écrites et inaccessibles en écriture, sauf à root. D'où l'intérêt.
Sinon, si le dba est craqué, il suffit d'effacer aud$ ou les fichiers de audit_file_dest ce qui ne pose pas de soucis.

[edit]
c'est bon, j'ai fait mon boulet...
dans /etc/syslog.conf, j'ai LOCAL0.WARNING /var/log/sshd.log
d'où le pourquoi...
[/edit]

[orafrance]

ha ouais... ça se tient...