Linux Auditd – Sicherheitsereignisse richtig protokollieren

Linux Auditd protokolliert sicherheitsrelevante Ereignisse direkt aus dem Kernel und liefert mir einen lückenlosen Prüfpfad für Anmeldungen, Dateiänderungen, Befehlsausführungen und Systemaufrufe. Richtig konfiguriert, erkenne ich Angriffe früh, erfülle Compliance-Vorgaben wie ISO 27001 oder PCI DSS und analysiere Vorfälle forensisch belastbar.

Zentrale Punkte

Diese Übersicht fasse ich bewusst knapp, praxisnah und ohne Floskeln zusammen, damit du sofort verstehst, wie du Audit-Regeln definierst, Logs schützt und Erkenntnisse ableitest. Ich nenne die wichtigsten Komponenten, typische Einsatzfälle, sinnvolle Regeln und Fehlerquellen, die in vielen Umgebungen zu blinden Flecken führen. So siehst du auf einen Blick, welche Einstellungen in auditd.conf zählen und welche Werkzeuge für die Auswertung bereitstehen. Anschließend vertiefe ich jedes Thema mit Beispielen, cleanen Empfehlungen und einer Tabelle zu entscheidenden Parametern. Damit gelingt dir der Sprung von „Auditd läuft“ zu „Auditd liefert verwertbare Sicherheitssignale“.

• Audit-Trail: vollständige Nachvollziehbarkeit sicherheitsrelevanter Aktionen
• Regeln: gezielt kritische Dateien, execve, Privilegien und Konfigurationen
• Log-Schutz: Rotation, Speicher-Trigger, Reaktion bei Engpässen
• Remote: zentrale Sammlung via TCP/TLS und SIEM-Anbindung
• Analyse: ausearch, aureport, klare Keys und saubere Dokumentation

Linux Auditd im Sicherheitskonzept

Auditd ergänzt klassische Systemlogs, indem es sich gezielt auf sicherheitsrelevante Aktionen konzentriert und die Ereignisse über die Kernel-Schnittstelle erfasst. Der Daemon schreibt diese Events standardmäßig nach /var/log/audit/audit.log und hält fest, welcher Benutzer welche Aktion zu welchem Zeitpunkt ausgeführt hat. Dadurch kann ich Verdachtsmomente schnell prüfen, etwa ungewollte Änderungen an /etc/ssh/sshd_config oder an sensiblen Dateien wie /etc/shadow. In regulierten Umgebungen sichere ich damit Nachweise über Richtlinienverstöße und erfülle Anforderungen an eine belastbare Protokollierung. Gegenüber klassischen Journal- oder Syslog-Daten liefert Auditd die tiefe, sicherheitsfokussierte Sicht, die für Angriffsaufklärung zählt.

Architektur: Kernel, Daemon, Werkzeuge

Das Auditing-System gliedert sich in ein Kernel-Subsystem für die Erfassung, den User-Space-Dienst auditd für die Speicherung und Tools für Verwaltung und Auswertung. Über auditctl setze ich Regeln zur Laufzeit oder lade beim Start persistente Regeln aus /etc/audit/rules.d/*.rules. Mit ausearch filtere ich Ereignisse nach Zeit, Benutzer, Schlüssel oder Datei, während aureport kompakte Berichte erzeugt. So kombiniere ich granular gesteuerte Erfassung mit schneller Analyse und halte den Audit-Pfad durchgängig nachvollziehbar. Wichtig ist eine konsistente Benennung über -k Keys, damit spätere Abfragen sauber greifen.

Installation und Aktivierung

Unter RHEL/CentOS installiere ich audit via dnf install audit oder yum install audit, auf Debian/Ubuntu nutze ich apt install auditd audispd-plugins. Nach der Installation starte und aktiviere ich den Dienst mit systemctl start auditd und systemctl enable auditd, den Status prüfe ich mit systemctl status auditd. Sobald Audit-Subsystem und Dienst laufen, landen Ereignisse entsprechend der Regeln in /var/log/audit/audit.log. Ich verifiziere die Funktionsfähigkeit mit einem gezielten Zugriff auf eine überwachte Datei und suche das Event dann mit ausearch -k keyname. Für einen konsistenten Start bei jedem Boot sorge ich dafür, dass persistente Regeln vorhanden sind und sauber laden.

Früher Start, Backlog und Regel-Schutz

Um frühe Boot-Ereignisse nicht zu verpassen, aktiviere ich das Audit-Subsystem bereits beim Kernel-Start. Dazu setze ich Kernel-Parameter und eine ausreichende Backlog-Größe, damit Events in der Hochlaufphase nicht verloren gehen. Zusätzlich sperre ich die Regelbasis nach dem Laden gegen Manipulation.

• Kernel-Parameter: audit=1 audit_backlog_limit=8192 in /etc/default/grub ergänzen, anschließend update-grub (Debian/Ubuntu) bzw. grub2-mkconfig -o /boot/grub2/grub.cfg (RHEL/CentOS) ausführen.
• Backlog in Regeln: In den Startregeln setze ich -b 8192, um die Kernel-Queue passend zu dimensionieren.
• Regeln sperren: Nach dem Laden der endgültigen Regelbasis aktiviere ich den Immutable-Modus mit -e 2. Änderungen sind dann nur noch nach Reboot möglich – ein wirksamer Schutz vor Live-Manipulationen.
• Überlauf-Verhalten: In /etc/audit/auditd.conf definiere ich overflow_action (z. B. SYSLOG oder SINGLE), damit ich bei vollem Puffer klar definierte Reaktionen erhalte.

Audit-Regeln richtig definieren

Die Qualität des Audit-Trails hängt von klaren, fokussierten Regeln ab, die kritische Aktionen abdecken und unnötigen Lärm vermeiden. Für sensible Dateien setze ich etwa -w /etc/passwd -p warx -k passwd_changes und ergänze passende Regeln für /etc/shadow, /etc/sudoers oder /etc/ssh/. Um Befehlsausführungen zu erfassen, nutze ich -a always,exit -F arch=b64 -S execve sowie die 32-Bit-Variante, damit jede Ausführung sichtbar bleibt, auch durch root. Für Dienstprogramme wie Apache filtere ich gezielt über den Pfad der Binary, zum Beispiel -a always,exit -F arch=b64 -S all -F exe=/usr/sbin/apache2 -k apache_activity. Ich dokumentiere jede Regel mit knappen Kommentaren und eindeutigen Keys, damit Auswertungen reproduzierbar bleiben und Kolleginnen sowie Kollegen die Intention erkennen.

Erweiterte Regelbeispiele und Tuning

Für mehr Tiefe baue ich ein fokussiertes Set, das Privilegienwechsel, Kernel-Eingriffe, Zeit- und Netzwerkänderungen sowie persistente Mechanismen sichtbar macht – ohne Package- oder Backup-Rauschen.

• Nur interaktive Nutzer: -F auid>=1000 -F auid!=4294967295 ergänzt zu execve-Regeln, um Systemdienste auszuklammern.
• Privilegienwechsel: -a always,exit -F arch=b64 -S setuid,setreuid,setresuid -k priv_change und die 32-Bit-Variante. Optional: -C uid!=euid, falls Feldvergleiche unterstützt werden.
• Kernel-Module: -a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kmod_change; zusätzlich: -w /sbin/insmod -p x -k kmod_exec, -w /sbin/modprobe -p x -k kmod_exec.
• Zeitänderungen: -a always,exit -F arch=b64 -S adjtimex,settimeofday,clock_settime -k time_change sowie -w /etc/localtime -p wa -k time_change.
• Mounts und Dateisystem: -a always,exit -F arch=b64 -S mount,umount2 -k fs_mount; -w /etc/fstab -p wa -k fs_mount.
• Netzwerkbasis: -a always,exit -F arch=b64 -S sethostname,setdomainname -k net_conf; -w /etc/hosts -p wa -k net_conf, -w /etc/hostname -p wa -k net_conf, -w /etc/resolv.conf -p wa -k net_conf.
• Cron und Timer: -w /etc/crontab -p wa -k sched, -w /etc/cron.d/ -p wa -k sched, -w /var/spool/cron/ -p wa -k sched, -w /etc/systemd/system/ -p wa -k sched, -w /usr/lib/systemd/system/ -p wa -k sched.
• Persistenz über SSH: -w /root/.ssh/ -p wa -k ssh_keys, -w /home/ -p wa -k ssh_keys (engen Pfad auf authorized_keys-Dateien pro Nutzer ein, um Rauschen zu vermeiden).
• SUID-/SGID-Missbrauch eindämmen: Auf ausführbare Verzeichnisse fokussieren: -w /usr/bin/ -p wa -k bin_change, -w /usr/sbin/ -p wa -k bin_change, -w /bin/ -p wa -k bin_change, -w /sbin/ -p wa -k bin_change.
• Nur Fehlschläge loggen (für laute Syscalls): -a always,exit -F arch=b64 -S open,openat -F success=0 -k file_denied.
• Rauschen dämpfen: Paketmanager/Backups ausschließen, z. B. -a never,exit -F exe=/usr/bin/dpkg, -a never,exit -F exe=/usr/bin/apt, -a never,exit -F exe=/usr/bin/yum, -a never,exit -F exe=/usr/bin/rpm, -a never,exit -F exe=/usr/bin/rsync (Pfad je Distribution prüfen).

Log-Management und Schutz vor Logverlust

Ohne saubere Rotation und klare Schwellen laufen Audit-Logs Gefahr, wertvolle Daten zu verlieren oder das Dateisystem zu füllen. In /etc/audit/auditd.conf definiere ich unter anderem max_log_file, max_log_file_action, num_logs, space_left und Reaktionen wie space_left_action, disk_full_action oder disk_error_action. Ich bevorzuge Aktionen wie ROTATE und eine frühzeitige Benachrichtigung an Syslog, damit ich bei Engpässen rechtzeitig reagiere. Zusätzlich sichere ich Audit-Logs auf einen separaten Host, um Manipulationen auf dem betroffenen System zu erschweren und Beweise zu bewahren. Die folgende Tabelle ordnet zentrale Parameter ein und zeigt typische, praxistaugliche Einstellungen.

Parameter	Zweck	Beispiel	Hinweis
log_file	Ablageort der Audit-Logs	/var/log/audit/audit.log	Standardpfad beibehalten und rechteklar absichern
log_format	Format der Events	RAW	RAW erleichtert forensische Auswertung ohne Informationsverlust
max_log_file	Maximale Dateigröße (MB)	100 bis 500	Größe an Ereignisaufkommen und Speicher anpassen
max_log_file_action	Aktion bei Erreichen der Größe	ROTATE	Rotation verhindert Stillstand oder Überschreiben
num_logs	Anzahl vorgehaltener Dateien	5 bis 10	Genug Historie für Analysen, ohne Speicher zu fressen
space_left	Schwelle freier Speicher (MB)	1024 oder höher	Frühzeitige Alerts geben Reaktionszeit
space_left_action	Reaktion bei Unterschreitung	SYSLOG	Zusätzlich E-Mail oder SIEM-Alarm erwägen
disk_full_action	Verhalten bei vollem Datenträger	SUSPEND oder HALT	Klare Entscheidung abhängig von Risikoakzeptanz

Remote-Logging und zentrale Auswertung

Für viele Hosts setze ich auf zentrale Erfassung per TCP/TLS, gesteuert über Parameter wie tcp_listen_port und passende Gegenstellen. Über audispd-Plugins oder rsyslog leite ich Events an eine SIEM- oder Security-Plattform, korreliere Anmeldefehler, Konfigurationsänderungen und verdächtige Prozessstarts. So erkenne ich Muster, die auf einem einzelnen Server unauffällig wirken, im Verbund jedoch sofort Alarm auslösen. Wer bereits Dashboards betreibt, profitiert von Log-Aggregation im Hosting, weil Audit-Events dort mit anderen Telemetriedaten zusammenfließen. Ich sorge außerdem für eine abgesicherte Transportstrecke und klare Trennung von produktiven Systemen und der Sammelinstanz.

Analyse: ausearch und aureport zielgerichtet nutzen

Rohdaten sind wertlos, wenn ich sie nicht schnell filtern kann, daher starte ich mit klaren Keys und nutze ausearch für fokussierte Abfragen. Mit ausearch -k passwd_changes -ts today werte ich etwa aktuelle Änderungen an /etc/passwd aus; Zeitfenster und Benutzerfilter spitze ich bei Bedarf zu. Für Überblickberichte liefert aureport --summary kompakte Tabellen, die auffällige Logins, Dateiänderungen und Syscall-Häufigkeiten sichtbar machen. Zusätzlich ergänze ich die Sicht auf Prozessstarts und Ressourcennutzung mit Process Accounting, um Ketten aus Ausführungen und Lastspitzen zu korrelieren. Am Ende zählt, dass ich Fragen in Sekunden beantworten kann: Wer, was, wann, wo und über welchen Weg.

Analyse vertiefen: Event-Felder richtig lesen

Damit Auswertungen treffsicher sind, kenne ich die wichtigsten Felder und Event-Typen. SYSCALL-Einträge tragen u. a. auid (Anmelde-UID), uid/euid/suid (real/effective/saved UID), ses (Session-ID) und exe (ausführbare Datei). PATH-Blöcke zeigen betroffene Pfade, EXECVE führt die Argumente auf, CWD liefert das Arbeitsverzeichnis. Mit ausearch -m SYSCALL -sc execve -ua 1000 -ts recent fokussiere ich interaktive Ausführungen; aureport -x --summary -i gibt mir Häufigkeiten und Auffälligkeiten auf einen Blick. Wichtig: auid bleibt über sudo oder setuid-Sprünge konstant und ist daher das robustere Filterkriterium für „Wer hat’s angestoßen?“.

Typische Fehler vermeiden

Zu breit gefasste Regeln blähen die Logs auf und verstecken die wirklich wichtigen Hinweise, daher konzentriere ich mich auf kritische Dateien, execve, Privilegienwechsel und sicherheitsrelevante Konfigurationen. Fehlt eine saubere Rotation, laufen Systeme ins Risiko, daher setze ich klare Grenzen für Größe und Anzahl sowie Aktionen bei Engpässen. Ich überwache auch die Audit-Konfiguration und das Verzeichnis /var/log/audit/, weil Angreifer Spuren verwischen wollen. Und ich dokumentiere jede Regel mit Key, Ziel und kurzer Begründung, damit Auswertungen konsistent bleiben. Wer Performance-Sorgen hat, sollte punktgenau filtern, unnötige Pfade streichen und die Wirkung neuer Regeln zunächst in Tests verifizieren.

Leistung, Stabilität und Qualitätschecks

Audit darf den Betrieb nicht ausbremsen. Ich prüfe regelmäßig mit auditctl -s, ob lost-Events auftreten, und beobachte Backlog-Werte nach Regeländerungen. Bei hoher Ereignislast erhöhe ich die Dispatcher-Queue (q_depth) der audispd-Plugins und setze overflow_action bewusst. Wo execve-Regeln zu viel Volumen erzeugen, grenze ich über auid oder über exe=-Whitelists/Blacklists ein und logge bei lauten Syscalls nur Fehlschläge. Vor dem breiten Rollout validiere ich neue Regeln in Staging, messe Event-Rate und CPU-Last und vergleiche aureport --summary vor/nach der Änderung, um den Effekt zu quantifizieren.

Container- und Virtualisierungsumgebungen

Auf Container-Hosts protokolliert der Kernel auch Container-Prozesse – das ist gewollt, kann aber laut werden. Ich orientiere mich am Host-Schutz (z. B. dockerd oder Podman), sichere Binärpfade und Konfigurationen und filtere Nutzersicht über auid. Beispiele: -w /usr/bin/dockerd -p x -k container_runtime, -w /etc/docker/ -p wa -k container_conf, plus generische Host-Regeln wie execve mit auid-Filter. In VMs behandle ich Audit-Logs wie flüchtige Daten: Remote-Weiterleitung aktivieren, Rotation knapp einstellen und bei Snapshots auf Zeitkonsistenz achten. Wichtig bleibt saubere NTP/Chrony-Synchronisierung, damit Timeline-Analysen belastbar sind.

Compliance und Nachweisführung

Für ISO 27001 (u. a. A.12.4 Logging/Monitoring, A.16 Incident Management) und PCI DSS (Kap. 10) formuliere ich prüffähige Nachweise: Was wird geloggt, wie lange, wer hat Zugriff, wie wird Integrität sichergestellt? Ich halte die Regelbasis versioniert vor, dokumentiere Keys und Zwecke, signiere Archiv-Logs mit Hashes und lagere sie manipulationsresistent aus. Bei personenbezogenen Daten wende ich Datenminimierung an (fokussierte Regeln, kurze Aufbewahrungsfristen) und definiere klare Löschprozesse. So entstehen Reports, die Auditoren überzeugen und im Vorfall tatsächlich Antworten liefern.

Betrieb, Monitoring und Playbooks

Im Dauereinsatz brauche ich feste Routinen: Tägliche Stichproben mit aureport, Alarme bei lost > 0, Prüfen der freien Audit-Partition und der Remote-Weiterleitung. Ich lege Playbooks an: „Auffällige Execs“ (Filter per exe= und auid), „Kritische Datei geändert“ (korrelieren von PATH, SYSCALL, EXECVE), „Kernel-Eingriff“ (Regeln zu init_module und mount). Bekannte Event-Typen wie ANOM_PROMISCUOUS (Interface im Promisc-Mode) oder MAC_POLICY_LOAD (MAC-Policy geladen) bewerte ich priorisiert und stoße Response-Schritte an.

Fehlerbehebung und Wiederanlauf

Wenn keine Events ankommen, prüfe ich zuerst ausearch -m DAEMON -ts today und auditctl -s (Status/Backlog). Fehlen Regeln, lade ich sie mit augenrules --load neu und kontrolliere mit auditctl -l. Ist der Immutable-Modus aktiv (-e 2), hilft nur ein Reboot mit angepassten Startregeln. Bei Berechtigungsproblemen auf /var/log/audit/ stelle ich Eigentümer und Modus wieder her; falls SELinux aktiv ist, korrigiere ich Kontexte. Und ich verifiziere, dass log_format = RAW gesetzt ist – lesbarer Input für Forensik und Parser.

Auditd in Hosting-Umgebungen

Gerade in Hosting-Setups mit vielen Workloads hilft mir Auditd, Mandantentrennung nachvollziehbar zu machen und Missbrauch früh zu erkennen. Ich überwache Web-, Datenbank- und Applikationsserver mit abgestuften Regelsets und integriere die Events in bestehendes Monitoring und Incident-Response. Für eine saubere Trennung sorge ich durch zentrale Ablage, getrennte Rollen und restriktive Rechte auf Log-Verzeichnissen. Zur Ergänzung der Systemdiagnose setze ich bei Bedarf auf journalctl zur Fehlersuche, halte aber sicherheitskritische Auswertungen primär im Audit-Kanal. So entsteht ein verlässlicher Prüfpfad, der Kundeninteressen, Compliance-Anforderungen und operative Effizienz zusammenbringt.

Kurz und knapp: Meine Vorgehensweise

Ich starte mit einem klaren Zielbild, formuliere fokussierte Regeln für kritische Dateien, execve und Privilegienwechsel und sichere die Rotation gegen Datenverlust ab. Dann aktiviere ich Remote-Weiterleitung mit TLS, dokumentiere Keys und teste die Wirkung jeder Regel bevor sie breit ausgerollt wird. Für die tägliche Arbeit setze ich auf ausearch und aureport, baue gezielte Suchen und erstelle übersichtliche Reports für Betrieb und Security. Bei Auffälligkeiten korreliere ich Audit-Events mit weiteren Signalen wie Prozess- oder Netzwerkdaten, um die Ursache schnell zu isolieren. So liefert mir Linux Auditd keine Log-Flut, sondern klare Antworten auf sicherheitsrelevante Fragen in produktiven Umgebungen.