Linux Audit-Framework & Dateiintegrität: `auditd`, AIDE & CIS-Compliance

Erstellt: 10.11.2026 Aktualisiert: 10.11.2026

Management Summary: Standard-Systemprotokolle (syslog, journald) protokollieren ausschließlich das, was Anwendungen freiwillig über Syslog-APIs ausgeben. Ein Angreifer mit kompromittierten Root-Rechten kann diese Logs manipulieren, Dienste stoppen oder Spuren rückstandslos verwischen. Das Linux Audit-Subsystem (auditd) setzt direkt im Linux-Kernel an und fängt Systemaufrufe über unumgehbare Hook-Points ab: Jede Dateimodifikation an sensiblen Konfigurationen, jede Rechteausweitung und jede Programmausführung wird revisionssicher erfasst. In Kombination mit AIDE (Advanced Intrusion Detection Environment) für kryptografische Dateiintegritätsprüfungen (FIM) und Lynis für automatisierte CIS-Compliance entsteht ein lückenloser forensischer Schutzschirm. Dieser Leitfaden behandelt die In-Kernel Audit-Architektur, unveränderbare Regeln (-e 2), Forensik mit ausearch/aureport, AIDE-Hashes und systematische CIS-Audits.

Kernel Audit-Architektur

Wie der Linux-Kernel Systemaufrufe über Hook-Points abfängt, über Netlink-Sockets streamt und Pufferüberläufe verhindert.
auditd Enterprise-Regeln

Überwachung kritischer Pfade (/etc/shadow, /etc/sudoers), Syscall-Filterung und Sperren der Konfiguration mit dem Unveränderlichkeits-Flag -e 2.
Forensik mit ausearch & aureport

Gezieltes Auswerten von Sicherheitsereignissen nach Event-Key (-k), Rekonstruktion menschlicher Sitzungen via auid und Management-Reports.
File Integrity Monitoring (AIDE)

Kryptografischer SHA256-Vergleich von System-Binaries (/bin/ls, /usr/sbin/sshd), Rootkit-Früherkennung und automatisierte Timer-Reports.
CIS-Compliance-Scans (Lynis)

Automatisierte Sicherheitsaudits nach CIS-Benchmarks, Ermittlung des Hardening Index und systematische Härtung von Serverflotten.
Performance & Incident-Runbook

Puffergrößen (-b 8192) gegen Datenverlust tunen, SIEM-Weiterleitung via audispd und Triage-Runbooks bei kompromittierten Systemdateien.

1. Linux Auditing-Architektur: Der In-Kernel Audit-Subsystem-Datenstrom

Das Linux-Audit-Framework ist kein Userspace-Daemon, der Logdateien parst. Es ist ein fest in den Kernel integriertes Subsystem, das vor und nach jedem Systemaufruf aufgerufen wird:

%%{init: {'flowchart': {'wrappingWidth': 350}}}%%
flowchart TB
    Process["Userspace-Prozess<br/>(execve, openat, chmod)"] ==> Kernel_Hooks["Kernel System-Call Hooks<br/>(Einstiegspunkt Ring 0)"]
    Kernel_Hooks --> Filter{"Audit-Filter-Prüfung<br/>(User / Task / Exit / Watch)"}
    Filter -->|"Kein Match"| Ignore["Syscall wird ignoriert"]
    Filter -->|"Regel greift"| Netlink["Netlink Socket<br/>(NETLINK_AUDIT Buffer)"]
    Netlink --> Auditd_Daemon["auditd Dämon<br/>(/etc/audit/auditd.conf)"]
    Auditd_Daemon --> Disk_Log["Audit-Trail auf Festplatte<br/>(/var/log/audit/audit.log)"]
    Auditd_Daemon -.-> Audispd["audispd Dispatcher<br/>(Remote SIEM / Wazuh / ELK)"]

Der entscheidende Unterschied: Die Audit-Benutzer-ID (`auid`)

Im Linux-Kernel besitzt jeder Prozess zwei Benutzer-IDs: 1. uid: Die aktuelle effektive Benutzer-ID (wechselt z. B. auf 0, wenn sudo ausgeführt wird). 2. auid (Login-UID): Die ursprüngliche Benutzer-ID, mit der sich die reale Person am System angemeldet hat (z. B. UID 1000 für nejat).

Die auid wird beim Login im Kernel unveränderbar an die Prozess-Session gebunden. Selbst wenn ein Benutzer sudo su - ausführt oder Shells wechselt: Das Audit-Subsystem protokolliert jede Aktion mit der ursprünglichen auid! Damit ist für Auditoren und Forensiker jederzeit zweifelsfrei beweisbar, welcher reale Mensch hinter einem administrativen Befehl stand.

2. Enterprise `auditd`-Regelwerk (`/etc/audit/rules.d/audit.rules`)

Das Regelwerk wird modular in /etc/audit/rules.d/audit.rules definiert und vom Compiler augenrules --load in den Kernel kompiliert.

Das vollständige Produktions-Regelwerk

Erstelle /etc/audit/rules.d/audit.rules:

# /etc/audit/rules.d/audit.rules
# ==============================================================================
# Enterprise Linux Auditd Rules Baseline (CIS Benchmark konform)
# ==============================================================================

# 1. PUFFER & FEHLER-POLICIES
# Bestehende Kernel-Regeln vor dem Laden bereinigen
-D

# Puffergröße auf 8192 Pakete erhöhen (verhindert Paketverlust unter Volllast)
-b 8192

# Fehlermodus bei Pufferüberlauf: 1 = printk Warnung im Kernel, 2 = Kernel Panic (Hochsicherheit)
-f 1

# Ratenbegrenzung: 0 = unbegrenzt (kein Abschneiden forensischer Events)
-r 0

# 2. IDENTITÄTS- & AUTHENTIFIZIERUNGS-DATEIEN (File Watches)
# Überwache Änderungen an Passwörtern, Gruppen und Authentifizierungs-Konfigurationen
-w /etc/passwd -p wa -k identity_changes
-w /etc/shadow -p wa -k identity_changes
-w /etc/group -p wa -k identity_changes
-w /etc/gshadow -p wa -k identity_changes
-w /etc/security/opasswd -p wa -k identity_changes
-w /etc/pam.d/ -p wa -k pam_changes

# 3. PRIVILEGIEN-ESKALATION & SUDOERS
-w /etc/sudoers -p wa -k priv_escalation
-w /etc/sudoers.d/ -p wa -k priv_escalation

# 4. NETZWERKKONFIGURATION & FERNWARTUNG
-w /etc/issue -p wa -k system_banner
-w /etc/issue.net -p wa -k system_banner
-w /etc/hosts -p wa -k network_modifications
-w /etc/network/ -p wa -k network_modifications
-w /etc/ssh/sshd_config -p wa -k sshd_config_changes
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config_changes

# 5. SYSCALL-ÜBERWACHUNG: EXECVE MIT RECHTEWECHSEL
# Protokolliere jede Programmausführung, bei der die reale UID ungleich der effektiven UID ist (SUID)
-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k elevated_exec
-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k elevated_exec

# 6. SYSTEMAUFRUFE: DATEIRECHTE-ÄNDERUNGEN (chmod, chown)
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod

# 7. KERNEL-MODUL-MANAGEMENT
# Überwache das Laden und Entladen von Kernel-Treibern (Rootkit-Früherkennung)
-w /sbin/insmod -p x -k kernel_modules
-w /sbin/rmmod -p x -k kernel_modules
-w /sbin/modprobe -p x -k kernel_modules
-a always,exit -F arch=b64 -S init_module,finit_module,delete_module -k kernel_modules

# 8. DAS UNVERÄNDERLICHKEITS-FLAG (-e 2)
# Friert die Konfiguration ein. Keine Änderungen mehr möglich ohne Systemneustart!
-e 2

Regeln kompilieren und laden

# Kompiliere alle Fragmente aus /etc/audit/rules.d/ und lade sie in den Kernel
sudo augenrules --load

Achtung bei Regel -e 2

Das Flag -e 2 am Ende der Datei friert das Audit-Subsystem im Kernel ein. Ab diesem Moment kann selbst der Superuser root keine Regeln mehr modifizieren, löschen oder den Audit-Dämon beenden. Konfigurationsänderungen werden erst nach einem Systemneustart wirksam!

3. Forensische Log-Analyse mit `ausearch` & `aureport`

Das Audit-Log unter /var/log/audit/audit.log speichert Ereignisse im maschinenlesbaren Format. Für Menschen existieren zwei mächtige Analysewerkzeuge:

1. Gezielte Forensik mit `ausearch`

# Suche nach allen Ereignissen mit dem Tag "identity_changes"
sudo ausearch -k identity_changes

# Finde heraus, wer /etc/shadow editiert hat (inklusive Anzeige der auid)
sudo ausearch -f /etc/shadow -i

# Suche nach fehlgeschlagenen Authentifizierungsversuchen der letzten 24 Stunden
sudo ausearch -m USER_AUTH -sv no -ts yesterday

# Suche nach allen Befehlen, die ein bestimmter Benutzer (auid 1000) als Root ausgeführt hat
sudo ausearch -ua 1000 -k elevated_exec -i

Tipp: Der Parameter -i (interpret) übersetzt kryptische numerische Werte (UIDs, Syscall-IDs, Zeitstempel) automatisch in menschenlesbare Namen und Datumsangaben!

2. Management- & Compliance-Reports mit `aureport`

# Zusammenfassender Sicherheitsbericht über alle Aktivitäten
sudo aureport --summary

# Bericht über alle Benutzeranmeldungen und Terminals
sudo aureport -l

# Bericht über alle fehlgeschlagenen Systemaufrufe (Zugriffsverweigerungen)
sudo aureport -s --failed -i

# Bericht über alle ausgeführten Programme
sudo aureport -x --summary

4. File Integrity Monitoring (FIM) mit AIDE

Während auditd Systemaufrufe zur Laufzeit aufzeichnet, überprüft AIDE (Advanced Intrusion Detection Environment) die statische Integrität aller Dateien auf der Festplatte.

Gelingt es einem Angreifer, ein Rootkit zu installieren, ersetzt er häufig Standard-Binaries wie /bin/ls oder /bin/ps durch manipulierte Versionen, die bösartige Prozesse vor dem Administrator verstecken. AIDE entlarvt diese Manipulationen durch kryptografische Prüfsummen (SHA256).

1. Installation und Konfiguration

# Installiere AIDE unter Debian / Ubuntu
sudo apt-get install aide aide-common

In /etc/aide/aide.conf werden die Prüfregeln definiert. Für Standard-Binaries gilt die Regel NORMAL (prüft Dateigröße, Permissions, Inode, Links, User, Group und kryptografischen SHA256-Hash).

2. Initial-Datenbank erzeugen und aktivieren

# Erzeuge die kryptografische Baseline-Datenbank (kann einige Minuten dauern)
sudo aideinit

# Kopiere die neu erstellte Datenbank an ihren Produktionsort
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

3. Manuelle Integritätsprüfung ausführen

# Überprüfe alle Systemdateien gegen die gespeicherte Baseline
sudo aide --check

Liefert AIDE Ausgaben wie: Changed files: /usr/sbin/sshd wurde die Binärdatei modifiziert!

4. Automatisierte Überprüfung via systemd-Timer

Aktiviere den täglichen AIDE-Check-Timer:

# Prüfe den Status des AIDE-Timers
sudo systemctl status aidecheck.timer

# Timer für automatische tägliche Scans aktivieren
sudo systemctl enable --now aidecheck.timer

5. Automatisierte CIS-Benchmark & Baseline-Scans mit Lynis

Das Center for Internet Security (CIS) veröffentlicht weltweit anerkannte Härtungsstandards für Linux. Lynis ist das führende quelloffene Audit-Werkzeug zur Überprüfung dieser Benchmarks.

1. Installation und System-Scan durchführen

# Installiere Lynis
sudo apt-get install lynis

# Führe einen vollständigen System-Audit ohne Benutzerinteraktion durch
sudo lynis audit system --quick

2. Auswertung des Hardening Index

Am Ende des Scans berechnet Lynis den Hardening Index (Skala von 0 bis 100). Auf einem standardmäßig installierten Linux-Server liegt dieser Wert meist zwischen 55 und 65. Nach Umsetzung unserer Härtungsserie erreicht das System typischerweise Werte von > 85.

3. Warnungen und Vorschläge gezielt extrahieren

# Zeige alle konkreten Sicherheitswarnungen an
sudo grep "WARNING" /var/log/lynis.log

# Zeige priorisierte Härtungsvorschläge an
sudo grep "SUGGESTION" /var/log/lynis.log

Jeder Vorschlag verweist auf eine eindeutige Test-ID (z. B. KRNL-5830), zu der Lynis mit lynis show details <Test-ID> konkrete Handlungsempfehlungen liefert.

6. Enterprise Best Practices & Incident Runbook

AIDE-Datenbank nach legitimen Paket-Updates aktualisieren

Wenn du mit apt upgrade Systempakete aktualisierst, meldet AIDE beim nächsten Lauf hunderte modifizierte Dateien (False Positives).

Aktualisiere die Baseline nach jedem Paket-Update:

sudo aide --update
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Incident Runbook: Was tun bei Alarm?

Alarmsignal	Mögliche Ursache	Triage-Workflow
AIDE meldet modifiziertes `/usr/sbin/sshd`	Rootkit-Injektion oder unautorisiertes Update	1. Host sofort vom Netzwerk trennen. 2. `dpkg -V openssh-server` ausführen (Paket-Integrität prüfen). 3. `ausearch -f /usr/sbin/sshd -i` ausführen, um den ändernden Prozess und die `auid` zu ermitteln.
Auditd meldet `backlog limit exceeded`	Puffergröße zu klein für aktuellen I/O-Traffic	Puffer in `/etc/audit/rules.d/audit.rules` auf `-b 16384` erhöhen und neu laden.
Lynis meldet unsichere Berechtigungen	Fehlkonfiguration in `/etc/`	Berechtigungen mit `chmod 0600` auf betroffenen Dateien korrigieren.

Mit Auditd, AIDE und Lynis schließt sich der Kreis der Host-Sicherheit: Das System ist nicht nur strukturell gehärtet, sondern verfügt über eine lückenlose, manipulationssichere Beweissicherung und automatisierte Compliance-Überwachung auf Enterprise-Niveau.

Linux Audit-Framework & Dateiintegrität: auditd, AIDE & CIS-Compliance