# Auditd Masterclass: System Calls unter der Lupe

TL;DR / Management Summary Während die Dateiüberwachung (Artikel 030) zeigt, was geändert wurde, zeigt das Syscall-Auditing, wie ein Prozess mit dem Kernel kommuniziert. Jede Aktion (Befehl ausführen, Netzwerk-Socket öffnen, Memory-Mapping) ist ein System-Call. Ein Senior Admin nutzt auditd, um verdächtiges Verhalten wie den Missbrauch von ptrace (Process Injection) oder unautorisierte execve-Aufrufe zu erkennen. Dies ist das ultimative Werkzeug für die Post-Mortem-Analyse nach einem Einbruch.

# 1. Einführung & Architektur

Die Kernel-Schnittstelle.

Jeder System-Call durchläuft den Kernel. Auditd klinkt sich in diesen Fluss ein und prüft jedes Event gegen die geladenen Regeln.

# Der Auditing-Stack (Mermaid)

graph TD
    A[User Space: malicious script] -->|Syscall: execve| B[Linux Kernel]
    B --> C{Audit Filter}
    C -->|Match: Rule 101| D[Audit Dispatcher]
    D --> E[/var/log/audit/audit.log]
    D --> F[audisp-plugins: Real-time Alert]
    G[Admin: ausearch] --> E
    subgraph "Rule Types"
        H[Watch: File access]
        I[Syscall: Kernel function]
    end
    I --> C

# 2. Fortgeschrittene Syscall-Regeln

Den Angreifer entlarven.

Die Regeln liegen in /etc/audit/rules.d/audit.rules.

# 1. Ausführung von Befehlen (execve)

Überwacht jeden Prozessstart im System.

-a always,exit -F arch=b64 -S execve -k proc_exec

# 2. Prozess-Manipulation (ptrace)

Wird oft für Code-Injection in andere laufende Prozesse genutzt.

-a always,exit -F arch=b64 -S ptrace -k process_injection

# 3. Laden von Kernel-Modulen

Angreifer versuchen oft, Rootkits als Kernel-Module zu laden.

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

# 3. Analyse der Rohdaten

Die Wahrheit in den Logs.

Ein Audit-Event ist komplex. Nutzen Sie ausearch mit dem Tag-Filter (-k).

# Suche nach Prozess-Injektionen
sudo ausearch -k process_injection -i

Das Flag -i (interpret) übersetzt numerische UIDs und Syscall-IDs in menschenlesbare Namen (z.B. root statt 0).

# 4. Day-2 Operations: Integrität der Logs

Den Wächter schützen.

Ein Angreifer wird als erstes versuchen, auditd zu stoppen oder die Logs zu löschen.

# Unveränderliche Regeln (Immutable)

Setzen Sie diese Zeile am Ende Ihrer Rules-Datei:

-e 2

# 5. Troubleshooting & “War Stories”

Wenn das Auditing den Server bremst.

# Story 1: “Der Performance-Killer fork()”

Symptom: Ein Compile-Server oder ein hochfrequentes Build-System wird nach Aktivierung von Auditd extrem langsam. Ursache: Der Admin überwacht den fork und exit Syscall. Da das System tausende Prozesse pro Sekunde startet, wird der Kernel zum Flaschenhals bei der Protokollierung. Lösung: Überwachen Sie nur execve (echte Programmstarts) statt jedes fork. Nutzen Sie Filter, um bekannte Build-Pfade von der Überwachung auszuschließen.

# Story 2: “Die Log-Injection Verschleierung”

Symptom: Ein Angreifer führt Befehle aus, aber in den Logs erscheinen keine Einträge. Ursache: Der Angreifer nutzt statisch gelinkte Binaries, die System-Calls direkt aufrufen, ohne Standard-Binaries wie /bin/bash zu nutzen. Lösung: Verlassen Sie sich nicht auf Pfad-Watches (-w /bin/ls). Nutzen Sie immer Syscall-Watches (-S execve), da diese auf Kernel-Ebene greifen, egal wie das Binary heißt.

# 6. Fazit & Empfehlung

• Pflicht: Aktivieren Sie Auditing für execve und ptrace.
• Wahl: Nutzen Sie Go-Audit (von Slack) oder Auditbeat, wenn Sie die Daten direkt in ein ELK-System streamen wollen.
• Wartung: Nutzen Sie augenrules --check, um sicherzustellen, dass die Dateien in rules.d/ konsistent sind.

# Anhang: Cheatsheet für Forensiker