Auditd est un outil de surveillance extraordinairement puissant. Comme tous ceux qui l'ont déjà regardé peuvent en témoigner, la convivialité est la principale faiblesse. Configurer quelque chose comme auditd nécessite beaucoup de réflexion assez approfondie sur exactementquoi c'est ce qui nécessite un audit sur le système spécifique en question. Dans la question, vous avez choisi un serveur Web comme système d'exemple, ce qui est bien car il est spécifique.
Pour les besoins de la discussion, supposons qu'il existe une division formelle entre les serveurs Web de test/développement et les serveurs Web de production où les développeurs Web effectuent tout leur travail sur les systèmes de test/développement et les modifications apportées à l'environnement de production sont effectuées dans un déploiement contrôlé.
Donc, en partant de ces hypothèses assez larges et en nous concentrant sur le système de production, nous pouvons nous mettre au travail. En examinant la recommandation auditd dans le benchmark CIS pour RHEL5, nous pouvons commencer à élaborer l'ensemble de règles suggéré suivant :
-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa
-b 1024
-e 2
Cela entraînera l'écriture des journaux à chaque sortie des appels système rmdir, unlink, stime ou setrlimit. Cela devrait nous permettre de savoir si quelqu'un tente de supprimer des fichiers ou de jigger avec le temps. Nous avons également mis en place des surveillances de fichiers spécifiques sur les fichiers qui définissent les groupes, les utilisateurs, les mots de passe et l'accès sudo. Au lieu de regarder les appels système pour chacun de ces fichiers, un journal d'audit sera écrit chaque fois que l'un de ces fichiers est :
- ouvert avec les modes O_WRONLY ou O_RDWR
- un attribut est modifié
Comme nous avons déjà supposé qu'il s'agissait d'un serveur Web de production, je recommanderais d'ajouter la ligne :
-w /var/www -p wa
Cela surveillera de manière récursive tous les fichiers sous le /var/www arborescence de répertoires.
Maintenant, nous pouvons voir la raison de l'hypothèse "d'environnement contrôlé" faite plus tôt. Entre la surveillance de tous les fichiers dans la racine Web, ainsi que tous les événements unlink ou rmdir, cela pourrait être excessivement bruyant dans un environnement de développement. Si nous pouvons anticiper les modifications du système de fichiers, comme pendant les fenêtres de maintenance ou les événements de déploiement, nous pouvons plus raisonnablement filtrer ce bruit.
En combinant tout cela dans un seul fichier cohérent, nous voudrions /etc/audit/audit.rules ressembler
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed
# to auditctl.
# First rule - delete all
-D
# Increase the buffers to survive stress events.
# Make this bigger for busy systems
-b 1024
-a exit,always -S unlink -S rmdir
-a exit,always -S stime.*
-a exit,always -S setrlimit.*
-w /var/www -p wa
-w /etc/group -p wa
-w /etc/passwd -p wa
-w /etc/shadow -p wa
-w /etc/sudoers -p wa
# Disable adding any additional rules - note that adding *new* rules will require a reboot
-e 2
Mise à jour :cet article est une bonne explication des règles d'auditd et donne des exemples pour chaque événement que vous pourriez souhaiter enregistrer :
HOWTO_configure_the_auditing_of_the_system_auditd
Consultez le rapport de bogue ici :
https://github.com/gds-operations/puppet-auditd/pull/1
Ils donnent un très long fichier d'exemple qui contient de nombreuses modifications importantes pouvant être apportées à un système. Copié ci-dessous pour plus de commodité (avec de légères modifications) :
## Remove any existing rules
-D
## Buffer Size
## Feel free to increase this if the machine panic's
-b 8192
## Failure Mode
## Possible values are 0 (silent), 1 (printk, print a failure message),
## and 2 (panic, halt the system).
-f 1
## Audit the audit logs.
## successful and unsuccessful attempts to read information from the
## audit records; all modifications to the audit trail
-w /var/log/audit/ -k auditlog
## Auditd configuration
## modifications to audit configuration that occur while the audit
## collection functions are operating.
-w /etc/audit/ -p wa -k auditconfig
-w /etc/libaudit.conf -p wa -k auditconfig
-w /etc/audisp/ -p wa -k audispconfig
## Monitor for use of audit management tools
-w /sbin/auditctl -p x -k audittools
-w /sbin/auditd -p x -k audittools
## special files
-a exit,always -F arch=b32 -S mknod -S mknodat -k specialfiles
-a exit,always -F arch=b64 -S mknod -S mknodat -k specialfiles
## Mount operations
-a exit,always -F arch=b32 -S mount -S umount -S umount2 -k mount
-a exit,always -F arch=b64 -S mount -S umount2 -k mount
## changes to the time
##
-a exit,always -F arch=b32 -S adjtimex -S settimeofday -S stime -S clock_settime -k time
-a exit,always -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time
## Use stunnel
-w /usr/sbin/stunnel -p x -k stunnel
## cron configuration & scheduled jobs
-w /etc/cron.allow -p wa -k cron
-w /etc/cron.deny -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /etc/cron.monthly/ -p wa -k cron
-w /etc/cron.weekly/ -p wa -k cron
-w /etc/crontab -p wa -k cron
-w /var/spool/cron/crontabs/ -k cron
## user, group, password databases
-w /etc/group -p wa -k etcgroup
-w /etc/passwd -p wa -k etcpasswd
-w /etc/gshadow -k etcgroup
-w /etc/shadow -k etcpasswd
-w /etc/security/opasswd -k opasswd
## monitor usage of passwd
-w /usr/bin/passwd -p x -k passwd_modification
#Monitor for use of tools to change group identifiers
-w /usr/sbin/groupadd -p x -k group_modification
-w /usr/sbin/groupmod -p x -k group_modification
-w /usr/sbin/addgroup -p x -k group_modification
-w /usr/sbin/useradd -p x -k user_modification
-w /usr/sbin/usermod -p x -k user_modification
-w /usr/sbin/adduser -p x -k user_modification
## login configuration and information
-w /etc/login.defs -p wa -k login
-w /etc/securetty -p wa -k login
-w /var/log/faillog -p wa -k login
-w /var/log/lastlog -p wa -k login
-w /var/log/tallylog -p wa -k login
## network configuration
-w /etc/hosts -p wa -k hosts
-w /etc/network/ -p wa -k network
## system startup scripts
-w /etc/inittab -p wa -k init
-w /etc/init.d/ -p wa -k init
-w /etc/init/ -p wa -k init
## library search paths
-w /etc/ld.so.conf -p wa -k libpath
## local time zone
-w /etc/localtime -p wa -k localtime
## kernel parameters
-w /etc/sysctl.conf -p wa -k sysctl
## modprobe configuration
-w /etc/modprobe.conf -p wa -k modprobe
## pam configuration
-w /etc/pam.d/ -p wa -k pam
-w /etc/security/limits.conf -p wa -k pam
-w /etc/security/pam_env.conf -p wa -k pam
-w /etc/security/namespace.conf -p wa -k pam
-w /etc/security/namespace.init -p wa -k pam
## GDS specific secrets
-w /etc/puppet/ssl -p wa -k puppet_ssl
## postfix configuration
-w /etc/aliases -p wa -k mail
-w /etc/postfix/ -p wa -k mail
## ssh configuration
-w /etc/ssh/sshd_config -k sshd
## changes to hostname
-a exit,always -F arch=b32 -S sethostname -k hostname
-a exit,always -F arch=b64 -S sethostname -k hostname
## changes to issue
-w /etc/issue -p wa -k etcissue
-w /etc/issue.net -p wa -k etcissue
## this was to noisy currently.
# log all commands executed by an effective id of 0 aka root.
-a exit,always -F arch=b64 -F euid=0 -S execve -k rootcmd
-a exit,always -F arch=b32 -F euid=0 -S execve -k rootcmd
## Capture all failures to access on critical elements
-a exit,always -F arch=b64 -S open -F dir=/etc -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/bin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/usr/sbin -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/var -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/home -F success=0 -k unauthedfileacess
-a exit,always -F arch=b64 -S open -F dir=/srv -F success=0 -k unauthedfileacess
## Monitor for use of process ID change (switching accounts) applications
-w /bin/su -p x -k priv_esc
-w /usr/bin/sudo -p x -k priv_esc
-w /etc/sudoers -p rw -k priv_esc
## Monitor usage of commands to change power state
-w /sbin/shutdown -p x -k power
-w /sbin/poweroff -p x -k power
-w /sbin/reboot -p x -k power
-w /sbin/halt -p x -k power
## Make the configuration immutable
-e 2
Vous abordez un peu la question dans le mauvais sens. Vous devez décider ce que vous voulez enregistrer et découvrir comment l'enregistrer. Générer un tas de fichiers journaux est cool et tout, mais si vous ne les regardez jamais ou ne savez pas ce que vous cherchez, cela ne fait que perdre du temps et de l'espace.
Lorsque vous décidez quoi enregistrer, vous devez identifier le comportement qui vous intéresse, puis découvrir comment enregistrer cette activité. Une bonne façon de commencer serait de lire sur AppArmor et de parcourir la page de manuel auditctl. puis apprenez quels appels système sont disponibles en apprenant à programmer pour Unix, et identifiez les appels qui peuvent vous intéresser. C'est vraiment une très grosse entreprise. Je sais que c'est un peu une réponse désinvolte et ne fournit pas "voici un script shell qui enregistrera tout ce qui vous intéresse sur votre serveur" - mais la raison pour laquelle ces réponses n'existent pas est que, eh bien, chaque situation est différente il n'est donc pas possible de donner une réponse "taille unique".
À l'endroit (certes grand) où je travaille, nous avons toute une équipe de personnes qui se consacrent uniquement à la journalisation du système - sans parler des différentes équipes d'administration et de sécurité qui y contribuent. Ce n'est pas un petit sujet. :/