Auditd ist ein außerordentlich leistungsfähiges Überwachungstool. Wie jeder, der sich schon einmal damit beschäftigt hat, bestätigen kann, ist die Benutzerfreundlichkeit die Hauptschwäche. Das Einrichten von so etwas wie auditd erfordert eine Menge gründlicher Überlegungen darüber, was es ist das, was auf dem betreffenden spezifischen System geprüft werden muss. In der Frage haben Sie sich für einen Webserver als unser Beispielsystem entschieden, was gut ist, weil es spezifisch ist.
Nehmen wir der Argumentation halber an, dass es eine formelle Trennung zwischen Test-/Entwicklungs-Webservern und Produktions-Webservern gibt, wo Webentwickler ihre gesamte Arbeit auf den Test-/Entwicklungssystemen erledigen und Änderungen an der Produktionsumgebung in einer kontrollierten Bereitstellung vorgenommen werden.
Wenn wir also diese ziemlich großen Annahmen treffen und uns auf das Produktionssystem konzentrieren, können wir uns an die Arbeit machen. Wenn wir uns die auditd-Empfehlung im CIS-Benchmark für RHEL5 ansehen, können wir mit dem Aufbau des folgenden empfohlenen Regelsatzes beginnen:
-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
Dadurch werden Protokolle immer dann ausgegeben, wenn die Systemaufrufe rmdir, unlink, stime oder setrlimit beendet werden. Dies sollte uns wissen lassen, wenn jemand versucht, Dateien zu löschen oder mit der Zeit zu spielen. Wir richten auch spezielle Dateiüberwachungen für die Dateien ein, die Gruppen, Benutzer, Passwörter und den Sudo-Zugriff definieren. Anstatt nach Systemaufrufen für jede dieser Dateien zu suchen, wird jedes Mal ein Prüfprotokoll geschrieben, wenn eine dieser Dateien entweder:
- geöffnet mit den Modi O_WRONLY oder O_RDWR
- ein Attribut wird geändert
Da wir bereits davon ausgegangen sind, dass es sich um einen Produktions-Webserver handelt, würde ich empfehlen, die Zeile hinzuzufügen:
-w /var/www -p wa
Dadurch werden rekursiv alle Dateien unter /var/www überwacht Verzeichnisbaum.
Jetzt können wir den Grund für die zuvor gemachte Annahme einer "kontrollierten Umgebung" sehen. Zwischen der Überwachung aller Dateien im Webstamm sowie aller Unlink- oder rmdir-Ereignisse könnte dies in einer Entwicklungsumgebung unerschwinglich laut sein. Wenn wir Änderungen am Dateisystem vorhersehen können, z. B. während Wartungsfenstern oder Bereitstellungsereignissen, können wir dieses Rauschen besser herausfiltern.
Wenn wir all dies in einer einzigen, kohärenten Datei kombinieren, würden wir /etc/audit/audit.rules wollen aussehen wie
# 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
Update:Dieser Artikel ist eine nette Erklärung der auditd-Regeln und gibt Beispiele für jedes Ereignis, das Sie protokollieren möchten:
HOWTO_configure_the_auditing_of_the_system_auditd
Sehen Sie sich den Fehlerbericht hier an:
https://github.com/gds-operations/puppet-auditd/pull/1
Sie geben eine sehr lange Beispieldatei an, die viele wichtige Änderungen enthält, die an einem System vorgenommen werden können. Der Einfachheit halber unten kopiert (mit leichten Änderungen):
## 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
Du gehst die Frage etwas falsch an. Sie müssen entscheiden, was Sie protokollieren möchten, und herausfinden, wie Sie dies protokollieren. Das Generieren eines Haufens von Protokolldateien ist cool und so, aber wenn Sie sie sich nie ansehen oder nicht wissen, wonach Sie suchen, verschwenden Sie nur Zeit und Platz.
Bei der Entscheidung, was protokolliert werden soll, müssen Sie ermitteln, welches Verhalten Ihnen wichtig ist, und dann herausfinden, wie Sie diese Aktivität protokollieren. Eine gute Möglichkeit, damit anzufangen, wäre, sich über AppArmor zu informieren und die Manpage auditctl durchzulesen. lernen Sie dann, welche Systemaufrufe verfügbar sind, indem Sie lernen, für Unix zu programmieren, und identifizieren Sie die Aufrufe, die von Interesse sein könnten. Es ist wirklich ein ziemlich großes Unterfangen. Ich weiß, dass dies eine etwas oberflächliche Antwort ist und nicht "Hier ist ein Shell-Skript, das alles protokolliert, was Ihnen wichtig ist, auf Ihrem Server" - aber der Grund, warum diese Antworten nicht existieren, ist, dass jede Situation anders ist daher ist es nicht möglich, eine Antwort zu geben, die den meisten passt.
An dem (zugegebenermaßen großen) Ort, an dem ich arbeite, haben wir ein ganzes Team von Leuten, die sich ausschließlich der Systemprotokollierung widmen – ganz zu schweigen von den verschiedenen Admin- und Sicherheitsteams, die ihren Beitrag leisten. Das ist kein kleines Thema. :/