Exemple simple de configuration auditd?
Auditd a été recommandé dans une réponse à Journalisation des commandes Linux?
L'installation par défaut sur Ubuntu semble à peine enregistrer quoi que ce soit. Il existe plusieurs exemples qui l'accompagnent (capp.rules, nispom.rules, stig.rules) mais il n'est pas clair quel serait l'impact sur les performances de chacun, ni quel type d'environnement ou d'hypothèses chacun serait le mieux adapté.
Quel serait le meilleur point de départ pour déployer auditd sur, disons, un serveur web? Cela comprendrait un fichier audit.rules, des paramètres pour permettre l'envoi du flux du journal d'audit à une machine distante en temps réel, et le plus simple des outils pour voir ce qui a été enregistré.
Ensuite, que diriez-vous d'une machine de bureau typique?
Mettre à jour: dannysauer note que pour la sécurité, il est important de commencer par l'objectif, et je suis d'accord. Mais mon intention principale est de spark quelques explications plus utiles de l'utilisation de cet outil, et de voir un exemple travaillé de celui-ci en action, ainsi que les implications en termes de performances et de stockage, etc. Si cela existe déjà et que je l'ai manqué, veuillez le signaler. Sinon, je suggère qu'un exemple soit créé pour l'un des scénarios les plus courants (par exemple un serveur Web simple, exécutant la pile de votre choix), où le but peut être de conserver les informations en cas de cambriolage pour vous aider à retrouver le début de la pénétration. S'il existe un objectif plus approprié ou réalisable à utiliser dans par exemple, une petite entreprise sans personnel informatique important, cela pourrait également aider.
Auditd est un outil de surveillance extraordinairement puissant. Comme quiconque l'a déjà examiné peut en témoigner, l'utilisabilité est la principale faiblesse. La configuration de quelque chose comme auditd nécessite beaucoup de réflexion assez approfondie sur exactement ce qui nécessite un audit sur le système spécifique en question. Dans la question, vous avez choisi un serveur Web comme exemple de système, ce qui est bien car il est spécifique.
Par souci d'argument, 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 de l'environnement de production sont effectuées dans un déploiement contrôlé.
Donc, en faisant ces hypothèses assez grandes et en nous concentrant sur le système de production, nous pouvons nous mettre au travail. En regardant la recommandation d'audit dans le référence CIS pour RHEL5 nous pouvons commencer à construire 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 fois que les appels système rmdir, unlink, stime ou setrlimit se terminent. Cela devrait nous faire savoir si quelqu'un essaie 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 d'eux, un journal d'audit sera écrit chaque fois que l'un de ces fichiers est soit:
- ouvert avec les modes O_WRONLY ou O_RDWR
- un attribut est changé
Puisque nous avons déjà fait l'hypothèse que nous parlons d'un serveur Web de production, je recommanderais d'ajouter la ligne:
-w /var/www -p wa
Cela surveillera récursivement tous les fichiers sous le /var/www arborescence de répertoires.
Nous pouvons maintenant voir la raison de l'hypothèse "d'environnement contrôlé" faite plus haut. Entre la surveillance de tous les fichiers dans la racine Web, ainsi que tous les événements de dissociation ou de rmdir, cela peut être extrêmement bruyant dans un environnement de développement. Si nous pouvons anticiper les changements du système de fichiers, comme lors des fenêtres de maintenance ou déployer des événements, nous pouvons plus raisonnablement filtrer ce bruit.
En combinant tout cela dans un fichier unique et 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 belle explication des règles auditd et donne des exemples pour chaque événement que vous souhaitez 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 qui pourraient ê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 quelque peu la question dans le mauvais sens. Vous devez décider de ce que vous souhaitez enregistrer et savoir 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 recherchez, cela gaspille juste du temps et de l'espace.
Lorsque vous décidez des éléments à enregistrer, vous devez identifier le comportement dont vous vous souciez, puis découvrir comment enregistrer cette activité. Une bonne façon de commencer serait de lire AppArmor et de parcourir la page man auditctl . apprenez ensuite quels appels système sont disponibles en apprenant à programmer pour Unix et identifiez les appels susceptibles de vous intéresser. C'est vraiment une entreprise assez importante. Je sais que c'est un peu une réponse simple 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, 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 dédiées uniquement à la journalisation du système - sans parler des différentes équipes d'administration et de sécurité qui contribuent. Ce n'est pas un petit sujet. : /