auditd beantwortet die Fragen, die erst nach dem Ereignis auftauchen: Wer hat diese Datei geändert, wann wurde dieser Benutzer angelegt, woher wurde dieser Prozess gestartet? Kein anderes Werkzeug beantwortet sie — in Anwendungsprotokollen stehen diese Angaben nicht, und die Befehlshistorie bearbeitet derjenige, der sie hinterlassen hat.

Die Schwierigkeit ist, dass die Installation des Pakets für sich genommen nichts bringt. Vorgegebene Regeln gibt es praktisch keine, das Journal wird geschrieben, ist aber inhaltlich leer — und das stellt sich im denkbar ungünstigsten Moment heraus: wenn die Daten gebraucht werden und nicht da sind.

Installation

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

Eine Besonderheit: In manchen Versionen lässt sich auditd nicht über systemctl restart neu starten — der Dienst wird über einen eigenen Befehl gesteuert. Regeln werden so neu eingelesen:

sudo augenrules --load
sudo auditctl -l

Der zweite Befehl zeigt, was tatsächlich geladen ist. Ihm glauben Sie, nicht dem Inhalt der Dateien.

Der Regelsatz

Regeln kommen als eigene Datei nach /etc/audit/rules.d/. Nachfolgend ein Mindestsatz, der sich lohnt: Er beantwortet die meisten Fragen eines Vorfalls, ohne die Platte zuzuschütten.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Benutzer und Rechte
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k privileges
-w /etc/sudoers.d/ -p wa -k privileges

## SSH-Zugang
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## Zeitgesteuerte Aufträge
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Kernelmodule
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## Verwendung von sudo und su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

Die Syntax ist kurz: -w ist ein zu beobachtender Pfad, -p wa heißt auf Schreibzugriffe und Attributänderungen reagieren, -p x auf Ausführung, -k ist der Schlüssel, nach dem später gesucht wird. Diese Schlüssel sind der eigentliche Komfort: Ohne sie wird die Suche im Journal zum Durchsehen eines Gigabytes Text.

Was nicht auf der Liste steht und warum

Anleitungen empfehlen oft, jeden execve-Aufruf aufzuzeichnen — also jeden Start jedes Programms. Die Versuchung ist verständlich: ein vollständiges Bild aller Handlungen. In der Praxis ergibt das auf einem Arbeitsserver hunderte Megabyte pro Tag, frisst einen merklichen Anteil des Prozessors und führt dazu, dass das Journal früher gekürzt werden muss, als es gebraucht wird. Ist diese Detailtiefe nötig, aktivieren Sie sie punktuell — für einen Benutzer oder für die Dauer einer Untersuchung.

Dasselbe gilt für die Beobachtung des Website-Verzeichnisses: Dort wird ununterbrochen geschrieben, und die Regel verwandelt das Journal in einen Strom bedeutungsloser Ereignisse.

Lesen

Suche nach Schlüssel, mit Auflösung numerischer Kennungen in Namen:

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

Der Schalter -i ist für die Lesbarkeit unerlässlich: Ohne ihn erhalten Sie Zahlen statt Benutzernamen und Systemaufrufen. -ts begrenzt den Zeitraum (today, recent oder ein konkretes Datum).

Eine Übersicht für einen Zeitraum:

sudo aureport --summary -i
sudo aureport --auth -i --failed

An einem Ereigniseintrag sind drei Felder interessant: auid, die Kennung des Benutzers, der die Sitzung begonnen hat, uid, die Identität, unter der die Handlung lief, und exe, das ausführende Programm. Der Unterschied zwischen auid und uid ist die Antwort auf „wer genau ist root geworden“: uid=0 mit der auid einer bestimmten Person benennt den Verantwortlichen eindeutig, ganz gleich, als wer er sich innerhalb der Sitzung ausgegeben hat.

Festplatte

Die Größeneinstellungen stehen in /etc/audit/auditd.conf:

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

Sehen Sie sich disk_full_action gesondert an. In manchen Konfigurationen ist dort das Anhalten des Systems bei voller Platte voreingestellt — ein Verhalten, das auf Maschinen mit Auditpflichten begründet und auf einem Webserver völlig fehl am Platz ist. Prüfen Sie diesen Wert, bevor die Platte volläuft.

Unveränderliche Regeln

Die Zeile -e 2 am Ende der Regeldatei verbietet Änderungen an den Regeln bis zum Neustart — auch demjenigen, der Root-Rechte erlangt hat. Das steigert den Wert des Journals merklich: Ein Angreifer kann die Beobachtung nicht abschalten, ohne die Maschine neu zu starten, und ein Neustart fällt für sich genommen auf.

Die Kehrseite liegt auf der Hand: Auch Ihre eigenen Regeln lassen sich ohne Neustart nicht mehr ändern. Aktivieren Sie das, wenn der Regelsatz sich gesetzt hat und Sie einen Monat damit gelebt haben.

Wozu das auf einem gewöhnlichen Server

auditd verhindert nichts. Sein Wert zeigt sich genau einmal — wenn die Abfolge der Ereignisse rekonstruiert werden muss und die Daten entweder da sind oder nicht. Nachträglich lassen sie sich nicht erheben, weshalb der Regelsatz im Voraus eingerichtet und dann in Ruhe gelassen wird.

Ein praktisches Zeichen dafür, dass die Einrichtung stimmt: Die Regelliste ist nicht leer, das Journal wächst nicht unkontrolliert, und Ereignisse mit den Schlüsseln identity und privileges treten selten auf und lassen sich jeweils erklären. Wie das auf einer Seite aussieht, zeigt die Demo unten.