Linux Audit Log mit auditd: Änderungen nachvollziehen

1. Was auditd anders erfasst als Standard-Logs

syslog und journald erfassen nur, was Anwendungen selbst protokollieren wollen. Ein Login über SSH taucht in /var/log/auth.log auf, aber ein lesender Zugriff auf /etc/shadow durch einen kompromittierten Prozess hinterlässt dort keine Spur. auditd arbeitet auf einer anderen Ebene: Es hakt sich direkt in das Linux Kernel Audit Subsystem ein und protokolliert Systemaufrufe, bevor der Kernel sie ausführt. Damit erfasst es Dinge, die kein Anwendungslog kennt, etwa welcher Prozess mit welcher UID eine Datei geöffnet, verändert oder gelöscht hat, unabhängig davon, ob die Anwendung selbst dafür ein Log schreibt.

Für Entwickler, die ihre eigenen Server administrieren, wird das relevant, sobald Compliance-Anforderungen wie PCI DSS oder ISO 27001 ins Spiel kommen, oder sobald nach einem Sicherheitsvorfall geklärt werden muss, wer app/etc/env.php verändert oder wann ein Angreifer sudo-Rechte missbraucht hat. Mit syslog allein lässt sich das kaum rekonstruieren. auditd liefert dafür UID, AUID (die Login-UID, bleibt auch nach su oder sudo erhalten), PID, PPID, den vollständigen Executable-Pfad und den genauen Syscall, mit Zeitstempel auf Mikrosekundenebene.

2. Architektur: Kernel Audit Subsystem, auditd und auditctl

Das Linux Audit Subsystem besteht aus drei Teilen: dem Kernel-Modul, das Syscalls abfängt und Ereignisse generiert, dem Userspace-Daemon auditd, der diese Ereignisse aus dem Kernel-Ringpuffer liest und nach /var/log/audit/audit.log schreibt, und auditctl, dem Kommandozeilenwerkzeug zum Laden und Verwalten von Regeln zur Laufzeit. Die Kommunikation zwischen Kernel und auditd läuft über einen dedizierten Netlink-Socket, nicht über normale Syscalls, was die Manipulation der Audit-Pipeline durch einen Angreifer mit gewöhnlichen Benutzerrechten erschwert.

Auf Debian und Ubuntu installiert apt install auditd audispd-plugins das Paket, auf RHEL und Rocky Linux ist es meist bereits vorinstalliert. Nach der Installation läuft auditd als eigener systemd-Dienst, unabhängig von journald oder rsyslog, und startet automatisch vor den meisten anderen Diensten, damit möglichst früh im Bootvorgang protokolliert wird. auditctl -s zeigt den aktuellen Status inklusive geladener Regel-Anzahl, aktivem Backlog-Limit und Enabled-Flag.

#!/usr/bin/env bash
# Install and enable auditd on Debian/Ubuntu based systems
apt-get update
apt-get install -y auditd audispd-plugins

# Enable and start the daemon, independent from journald/rsyslog
systemctl enable --now auditd
systemctl status auditd --no-pager

# Check current status: rule count, backlog limit, enabled flag
auditctl -s
# AUDIT_STATUS: enabled=1 failure=1 pid=1284 rate_limit=0
# backlog_limit=8192 lost=0 backlog=0

# List all currently loaded rules
auditctl -l

3. Audit-Regeln für sensible Dateien schreiben

Die Grundsyntax einer Datei-Regel lautet auditctl -w <pfad> -p <berechtigungen> -k <schlüssel>. Das Flag -w setzt einen Watch auf einen Pfad, -p definiert die überwachten Zugriffsarten: r (lesen), w (schreiben), x (ausführen), a (Attributänderung wie chmod oder chown). Das Flag -k vergibt einen frei wählbaren Schlüssel, mit dem sich Ereignisse später gezielt über ausearch filtern lassen, ohne den Pfad erneut angeben zu müssen. Für /etc/passwd reicht meist -p wa, weil Lesezugriffe durch fast jeden Prozess normal sind und sonst die Logmenge unnötig aufblähen würden.

Für Verzeichnisse mit vielen sensiblen Dateien, etwa /etc/sudoers.d oder das Konfigurationsverzeichnis einer Magento-Installation, ist eine Verzeichnisregel sinnvoller als einzelne Dateiregeln, weil neu angelegte Dateien darin automatisch mit erfasst werden. Wichtig: Regeln, die per auditctl direkt gesetzt werden, gehen beim nächsten Neustart verloren, sie dienen nur zum schnellen Testen. Für den produktiven Einsatz gehören Regeln in Dateien unter /etc/audit/rules.d/, die über augenrules kompiliert und geladen werden, wie in Abschnitt 5 beschrieben.

# /etc/audit/rules.d/10-sensitive-files.rules
# Track changes to core identity and privilege files
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity

# Track sudoers changes; the whole directory, not just the main file
-w /etc/sudoers -p wa -k privilege_escalation
-w /etc/sudoers.d/ -p wa -k privilege_escalation

# Application-specific: Magento configuration files
-w /var/www/magento/app/etc/env.php -p wa -k magento_config
-w /var/www/magento/app/etc/config.php -p wa -k magento_config

# Load the rule file immediately for testing
auditctl -R /etc/audit/rules.d/10-sensitive-files.rules

4. Syscall-Auditing: Rechteausweitung und Prozessausführung erfassen

Datei-Watches erfassen nur Zugriffe über den Pfad selbst, nicht aber Systemaufrufe wie setuid, execve oder ptrace, die typische Schritte einer Rechteausweitung sind. Die Syscall-Regel-Syntax ist deutlich mächtiger: auditctl -a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k exec_commands protokolliert jede Programmausführung durch angemeldete Benutzer, nicht durch Systemdienste, inklusive der vollständigen Kommandozeile. Der Filter auid>=1000 grenzt reguläre Benutzerkonten von Systemkonten ab, auid!=unset schließt Kernel-eigene Prozesse ohne zugewiesene Login-UID aus.

Für Rechteausweitung sind vor allem setuid, setgid und die zugehörigen Capability-Syscalls interessant: Eine Regel auf setuid mit dem Schlüssel privilege_escalation zeigt zuverlässig, wenn ein Prozess seine effektive UID ändert, ein klassisches Muster bei exploitierten Diensten. Wichtig ist, auf 64-Bit-Systemen zusätzlich zu arch=b64 auch arch=b32 zu setzen, weil 32-Bit-Kompatibilitäts-Syscalls sonst unbeobachtet bleiben, ein bekannter Umgehungsweg für Angreifer, die gezielt über die 32-Bit-Schnittstelle Syscalls absetzen.

# /etc/audit/rules.d/20-syscalls.rules
# Track every command execution by real (non-system) users
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=unset -k exec_commands
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=unset -k exec_commands

# Track privilege escalation syscalls, both architectures
-a always,exit -F arch=b64 -S setuid -S setgid -S setresuid -S setresgid -k privilege_escalation
-a always,exit -F arch=b32 -S setuid -S setgid -S setresuid -S setresgid -k privilege_escalation

# Track sudo invocations specifically, by executable path
-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -k sudo_usage

# Track deletion or rename of files inside /etc
-a always,exit -F arch=b64 -S unlink -S unlinkat -S rename -S renameat -F dir=/etc -k etc_delete_rename

5. Regeln dauerhaft machen mit augenrules

Regeln, die nur per auditctl gesetzt wurden, verschwinden nach jedem Reboot, weil sie ausschließlich im Kernel-Ringpuffer existieren. Für dauerhafte Regeln legt man .rules-Dateien unter /etc/audit/rules.d/ ab, üblicherweise nach Themen sortiert, etwa 10-sensitive-files.rules und 20-syscalls.rules. Der Befehl augenrules --load kompiliert alle Dateien im Verzeichnis in der richtigen Reihenfolge zu /etc/audit/audit.rules und lädt sie sofort in den Kernel, ohne dass der auditd-Dienst neu gestartet werden muss.

Die Datei /etc/audit/auditd.conf steuert das Verhalten des Daemons selbst, unabhängig von den eigentlichen Regeln: Speicherort der Logdatei, maximale Dateigröße, Rotationsverhalten und was passiert, wenn die Festplatte voll läuft. Der Parameter space_left_action ist besonders wichtig, weil ein volllaufendes Audit-Log ohne Gegenmaßnahme im schlimmsten Fall das gesamte System durch fehlenden Speicherplatz beeinträchtigen kann.

# /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log
log_format = ENRICHED
flush = INCREMENTAL_ASYNC
freq = 50

# Rotation: keep 10 files of max 50 MB each
max_log_file = 50
num_logs = 10
max_log_file_action = ROTATE

# Disk space thresholds and what happens when they are hit
space_left = 200
space_left_action = SYSLOG
admin_space_left = 100
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND
disk_error_action = SUSPEND

6. Audit-Logs durchsuchen mit ausearch

ausearch ist das primäre Werkzeug, um aus dem teils mehrere Gigabyte großen audit.log gezielt einzelne Ereignisse herauszufiltern. Der Schlüssel aus der Regel ist dabei der wichtigste Einstiegspunkt: ausearch -k identity -ts today zeigt alle heutigen Ereignisse zur Regel identity, also Änderungen an /etc/passwd oder /etc/shadow. Für forensische Auswertungen nach einem konkreten Vorfall lässt sich zusätzlich mit -ui oder -ue nach einer bestimmten Benutzer-ID filtern und mit -ts/-te ein exakter Zeitraum eingrenzen.

Die Rohausgabe von ausearch besteht aus mehreren Zeilen pro Ereignis (SYSCALL, CWD, PATH, PROCTITLE), die über dieselbe msg=audit(...)-Kennung zusammengehören. Für Skripte und Log-Aggregation ist --format json in aktuelleren auditd-Versionen deutlich praktischer, weil sich das Ergebnis direkt in jq oder eine Log-Pipeline einspeisen lässt, statt die mehrzeilige Textausgabe manuell zu parsen.

{
  "timestamp": "2026-07-12T09:14:22.412+02:00",
  "serial": 1928374,
  "node": "web01.mironsoft.de",
  "record_type": "SYSCALL",
  "syscall": "openat",
  "success": "yes",
  "exe": "/usr/bin/vim",
  "auid": "1000",
  "auid_name": "deploy",
  "uid": "0",
  "uid_name": "root",
  "key": "identity",
  "path": "/etc/passwd",
  "comm": "vim"
}

7. Reports und Auswertungen mit aureport

Während ausearch einzelne Ereignisse liefert, aggregiert aureport sie zu Übersichten und Statistiken, ideal für regelmäßige Reports statt Einzelfall-Recherche. aureport -au zeigt eine Zusammenfassung aller Authentifizierungsversuche mit Erfolg und Fehlschlag, aureport -f zeigt alle Dateizugriffs-Ereignisse gruppiert nach Datei, aureport -k listet alle verwendeten Schlüssel mit Trefferanzahl, ein guter erster Blick, um zu sehen, welche Regel am häufigsten anschlägt.

Für einen wöchentlichen Sicherheitsbericht bietet sich aureport --summary in Kombination mit einem Zeitfenster über -ts/-te an, das liefert Zahlen zu Logins, Dateiänderungen, Prozessausführungen und Anomalien in kompakter Form, geeignet für ein Cronjob-gestütztes Reporting per Mail. Beide Werkzeuge greifen standardmäßig auf /var/log/audit/audit.log zu, lassen sich mit -if aber auch auf archivierte, rotierte Logdateien anwenden, etwa bei der Aufarbeitung eines mehrere Wochen zurückliegenden Vorfalls.

8. Performance-Kosten aggressiver Audit-Regeln

Jede zusätzliche Audit-Regel kostet CPU-Zeit, weil der Kernel bei jedem passenden Syscall zusätzlich zur eigentlichen Operation die Filterbedingungen auswerten und ein Ereignis in den Ringpuffer schreiben muss. Watches auf einzelne Dateien wie /etc/passwd sind praktisch kostenlos, weil sie selten ausgelöst werden. Syscall-weite Regeln wie eine ungefilterte Beobachtung von open oder read auf stark frequentierten Verzeichnissen können dagegen spürbar Last erzeugen, insbesondere auf I/O-intensiven Systemen wie Datenbankservern oder Magento-Webservern mit vielen gleichzeitigen PHP-FPM-Workern.

Der Parameter -b (Backlog-Limit) in auditd.conf bestimmt, wie viele Ereignisse im Kernel-Puffer warten dürfen, bevor sie verworfen werden oder das System laut failure_flag blockiert. Bei failure=2 (panic) kann ein überlaufender Puffer im schlimmsten Fall dazu führen, dass Syscalls blockieren, bis auditd wieder Kapazität hat, ein reales Risiko für Produktionssysteme unter Last. Die Empfehlung: Regeln so eng wie möglich mit -F-Filtern (auid, exe, path) fassen, statt pauschal ganze Syscall-Klassen zu beobachten, und den Backlog mit -b 8192 oder höher großzügig dimensionieren, statt failure=2 im Produktivbetrieb zu riskieren.

9. auditd im Vergleich zu Standard-Logging

Standard-Logging über syslog oder journald und Kernel-Level-Auditing über auditd lösen unterschiedliche Probleme und schließen sich nicht gegenseitig aus, sie sollten parallel betrieben werden. Die folgende Übersicht zeigt, wo auditd einen echten Mehrwert gegenüber reinem Anwendungslogging bringt.

In der Praxis bedeutet das: syslog und journald bleiben für Anwendungsereignisse und Debugging zuständig, auditd übernimmt die sicherheitsrelevante, manipulationsresistente Nachvollziehbarkeit auf Kernel-Ebene. Wer beides kombiniert und die Audit-Logs zusätzlich per audisp-remote oder rsyslog-Weiterleitung auf ein separates Log-System auslagert, verhindert außerdem, dass ein Angreifer mit Root-Rechten auf dem kompromittierten Host die eigenen Spuren vollständig verwischen kann.

10. Zusammenfassung

Das Linux Audit Log mit auditd löst ein Kernproblem, das Standard-Logging strukturell nicht abdecken kann: Nachvollziehbarkeit auf Kernel-Ebene, unabhängig davon, ob eine Anwendung selbst protokolliert. Watches wie -w /etc/passwd -p wa -k identity erfassen Änderungen an sensiblen Dateien, Syscall-Regeln auf execve, setuid und setresuid erfassen Prozessausführung und Rechteausweitung. Regeln unter /etc/audit/rules.d/ und augenrules --load machen die Konfiguration reboot-fest, ausearch und aureport liefern die Werkzeuge für gezielte Einzelfall-Recherche und aggregierte Reports.

Der entscheidende Punkt ist die Balance zwischen Erfassungstiefe und Performance: Pauschale, ungefilterte Syscall-Regeln auf stark frequentierten Systemen erzeugen spürbare Last und riskieren im schlimmsten Fall blockierende Syscalls bei vollem Backlog. Präzise -F-Filter, ein großzügig dimensioniertes Backlog-Limit und die klare Trennung zwischen wenigen kritischen Datei-Watches und gezielten Syscall-Regeln machen auditd auch auf produktiven Magento- und PHP-Servern praktikabel, ohne die Systemlast unkontrolliert zu erhöhen.

11. FAQ: Linux Audit Log mit auditd