# Auditd: Der digitale Fahrtenschreiber für Linux-Server

TL;DR / Management Summary Wer hat nachts um 02:00 Uhr die Datei /etc/shadow gelesen? Welcher Prozess hat eine Netzwerkverbindung zu einer bösartigen IP aufgebaut? Auditd (Linux Audit Dämon) liefert die Antworten. Im Gegensatz zum Standard-Logging, das nur meldet, was die Applikation will, zeichnet Auditd auf Kernel-Ebene auf, was wirklich passiert. Unverzichtbar für SOC-Analysten und Compliance-Zertifizierungen (ISO 27001, PCI-DSS).

# 1. Einführung & Architektur

Wie Auditd den Kernel belauscht.

Auditd klinkt sich direkt in die System-Calls (syscalls) des Kernels ein. Jedes Mal, wenn ein Prozess eine Datei öffnet (open), einen Prozess startet (execve) oder Berechtigungen ändert (chmod), kann Auditd dies registrieren.

graph TD
    A[User Space Process] -->|Syscall: open| B[Linux Kernel]
    B -->|Audit Hook| C[Audit Framework]
    C -->|Rules Matching| D[auditd Daemon]
    D -->|Write| E[/var/log/audit/audit.log]
    F[Admin/Analyst] -->|Query| G[ausearch / aureport]
    G --> E

# 2. Installation & Grundregeln

Den Wächter aktivieren.

# Installation

sudo apt update
sudo apt install auditd audispd-plugins

# Regeln definieren

Regeln liegen in /etc/audit/rules.d/audit.rules. Sie bestehen aus drei Typen:

1. Control Rules: Systemkonfiguration (z.B. Log-Limit).
2. File System Rules: Überwachung von Dateien/Ordnern.
3. System Call Rules: Überwachung von Kernel-Funktionen.

# 3. Praxisbeispiele: Was wir überwachen sollten

Security-Monitoring einrichten.

# Dateizugriffe überwachen

Wir wollen wissen, wenn jemand an der SSH-Konfiguration fummelt.

# -w: Watch Path, -p wa: Write/Attribute change, -k: Tag für die Suche
-w /etc/ssh/sshd_config -p wa -k sshd_change

# Ausführung von Befehlen durch Root

-a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

# Netzwerk-Sockets überwachen

-a always,exit -F arch=b64 -S connect -k network_outbound

# 4. Day-2 Operations: Analyse der Daten

Die Nadel im Heuhaufen finden.

Die Datei /var/log/audit/audit.log ist kaum lesbar für Menschen. Wir brauchen Tools.

# Suchen mit ausearch

# Suche nach allen Events mit dem Tag 'sshd_change'
sudo ausearch -k sshd_change

# Suche nach gescheiterten Dateizugriffen (Access Denied)
sudo ausearch -m AVC,USER_AVC -i

# Berichte mit aureport

Ideal für das wöchentliche Security-Review.

# Zusammenfassung aller fehlgeschlagenen Logins
sudo aureport -au

# Übersicht aller ausgeführten Befehle
sudo aureport -x --summary

# 5. Troubleshooting & “War Stories”

Wenn der Wächter das System ausbremst.

# Story 1: “Log-Flooding und Disk-Tod”

Symptom: Der Server reagiert nicht mehr, die Root-Partition ist zu 100% voll durch /var/log/audit/. Ursache: Zu aggressive Regeln (z.B. jeder read syscall auf /var/www/). Lösung: Nutzen Sie max_log_file und max_log_file_action = rotate in der /etc/audit/auditd.conf. Und: Überwachen Sie niemals read Operationen auf viel genutzten Verzeichnissen!

# Story 2: “Wer hat die Log-Files gelöscht?”

Symptom: Ein Angreifer ist eingebrochen und hat als erste Amtshandlung /var/log/audit/audit.log gelöscht. Ursache: Lokales Auditing reicht nicht aus, wenn Root kompromittiert ist. Lösung: Nutzen Sie das Plugin audisp-remote, um Audit-Logs in Echtzeit an einen gehärteten, zentralen Log-Server zu senden.

# 6. Compliance & Best Practices

• CIS Benchmark: Nutzen Sie die CIS-Vorgaben für Auditd-Regeln. Diese decken alle kritischen Pfade ab.
• Immutable Rules: Setzen Sie -e 2 am Ende Ihrer Rules-Datei. Dies sorgt dafür, dass die Regeln bis zum nächsten Reboot nicht mehr geändert werden können (selbst von Root!).
• Performance: Prüfen Sie die CPU-Last mit top. Auditd sollte selten mehr als 1-2% CPU verbrauchen.

# Anhang: Cheatsheet