Einleitung
Linux auditd ist eines der mächtigsten, aber zugleich sperrigsten Telemetrie-Subsysteme im Linux-Ökosystem. Mit über 100 unterschiedlichen Event-Typen liefert auditd extrem detaillierte Informationen zu Prozessen, Systemaufrufen, Berechtigungen und Benutzeraktionen. In der Praxis stellt sich für Wazuh-Administratoren jedoch schnell eine ernüchternde Frage: Gibt es einen vollständigen auditd-Decoder, der alle Event-Typen sinnvoll abdeckt?
Die kurze Antwort lautet: nein. Die lange Antwort ist technisch interessant – und erklärt, warum ein monolithischer „Full Auditd Decoder“ in Wazuh nicht realistisch ist und welche Architekturansätze stattdessen tragfähig sind.
Ausgangslage / Problemstellung
- auditd erzeugt über 100 verschiedene Record Types (SYSCALL, EXECVE, PATH, PROCTITLE, USER_AUTH, AVC, u. v. m.)
- Viele auditd-Events bestehen aus mehreren logisch zusammengehörenden Zeilen, die über eine gemeinsame Event-ID korreliert werden müssen
- Wazuh (OSSEC-Engine) arbeitet zeilenbasiert, nicht event-basiert
- Vorhandene Decoder:
- Default-Wazuh-Decoder: decken nur eine Teilmenge ab
- Community-/Third-Party-Decoder (z. B. SOCFortress): ebenfalls bewusst eingeschränkt
Ergebnis: Entweder man bekommt zu wenig Struktur – oder man verliert Kontext und Korrelation.
Technische Analyse
1) Warum ein vollständiger auditd-Decoder technisch kaum machbar ist
auditd ist kein klassisches Logformat. Ein einzelnes „Ereignis“ besteht häufig aus:
- SYSCALL-Record
- mehreren PATH-Records
- EXECVE (Argumente)
- PROCTITLE (hex-encodiert)
- optional USER_*, CWD, SOCKADDR, AVC etc.
Diese Records:
- kommen in separaten Logzeilen
- teilen sich nur eine Event-ID
- sind inhaltlich erst zusammen aussagekräftig
Die Wazuh-Analyse-Engine kann:
- einzelne Logzeilen dekodieren
- Felder extrahieren
- Regeln darauf anwenden
Sie kann jedoch keine mehrzeiligen auditd-Events zuverlässig zusammenführen, wenn auditd im aggregierten Modus arbeitet. Genau hier scheitert die Idee eines „vollständigen“ Decoders.
2) Aggregiertes auditd vs. unaggregiertes auditd: Lose-Lose
Es gibt zwei typische Betriebsarten:
Aggregierter Modus (auditd fasst Events zusammen)
- Vorteil: vollständiger Kontext
- Nachteil: extrem komplexe, verschachtelte Logzeilen
- In Wazuh: praktisch nicht robust parsbar
Unaggregierter Modus (jede Zeile einzeln)
- Vorteil: jede Zeile ist dekodierbar
- Nachteil: Kontext fehlt (ein PATH oder EXECVE ohne SYSCALL ist semantisch schwach)
Damit ergibt sich ein strukturelles Problem:
auditd ist für menschen- und spezialwerkzeugbasierte Analyse gebaut, nicht für klassische zeilenbasierte SIEM-Parser.
3) Warum Tetragon hier oft ins Spiel kommt
Projekte wie Tetragon verfolgen einen anderen Ansatz:
- eBPF-basiert
- strukturierte Events (JSON)
- semantisch angereicherte Informationen (Prozessbaum, Argumente, Kontexte)
Vorteile:
- saubere Struktur
- kein Multi-Line-Parsing
- gut geeignet für moderne Pipelines
Nachteile:
- weniger Events „out of the box“ als auditd
- CLI-Details oft fragmentierter (Pfad, Argumente getrennt)
- Zusatzkonfiguration für erweiterte Sichtbarkeit
- kein 1:1-Ersatz für klassische auditd-Semantik
Damit entsteht kein „besser oder schlechter“, sondern ein unterschiedlicher Fokus.
Lösung / Best Practices
1) Akzeptieren: Ein vollständiger auditd-Decoder ist kein realistisches Ziel
Der wichtigste Schritt ist konzeptionell:
- Ein „Decoder für alle 107 auditd-Event-Typen“ wäre:
- extrem fragil
- kaum wartbar
- regeltechnisch kaum nutzbar
Stattdessen sollte man auditd zielgerichtet nutzen.
2) Auditd selektiv einsetzen – nicht alles dekodieren wollen
Bewährt hat sich:
- auditd-Regeln bewusst einschränken (z. B. execve, privilege escalation, sensitive paths)
- nur sicherheitsrelevante Subsets aktiv überwachen
- Decoder und Regeln genau auf diese Subsets zuschneiden
So bleibt:
- Parsing überschaubar
- Regel-Logik verständlich
- Alert-Qualität hoch
3) Enrichment statt Decoder-Explosion
Für Felder wie proctitle (hex-encodiert) ist es oft sinnvoller:
- Ingest-Pipeline-Processing (z. B. Decode von Hex → ASCII)
- Normalisierung vor oder nach dem Manager
statt alles in XML-Decodern abzubilden.
Damit verschiebt man Komplexität aus der OSSEC-Engine heraus – was der Stabilität zugutekommt.
4) Hybrid-Ansatz: auditd + strukturierte Telemetrie
Ein in der Praxis tragfähiges Modell ist:
- auditd für maximale Low-Level-Transparenz (breite Sichtbarkeit)
- strukturierte Tools (z. B. eBPF-basiert) für saubere, korrelierbare High-Signal-Events
- Wazuh als zentrale Sammel-, Korrelation- und Alerting-Plattform
Wichtig dabei:
- Agent-Gruppen nutzen
- Zentrale Konfiguration erzwingen
- Klar trennen: „Visibility-Logs“ vs. „Detection-Signale“
Lessons Learned / Best Practices
- auditd ist kein SIEM-freundliches Logformat
Es ist extrem mächtig, aber strukturell schwer automatisiert auszuwerten. - Decoder lösen kein Architekturproblem
Mehr Decoder bedeuten nicht automatisch bessere Detection, oft nur mehr Rauschen. - Korrelation erfordert Struktur, nicht nur Details
Viele auditd-Daten sind hochdetailliert, aber ohne Aggregation semantisch schwach. - Hybrid-Ansätze sind realistischer als perfekte Parser
Breite Sichtbarkeit durch auditd, saubere Signale durch strukturierte Events. - Wazuh bleibt der Orchestrator, nicht der Log-Zauberer
Die Stärke liegt in Korrelation, Regeln und Kontext – nicht im Parsen beliebig komplexer Logformate.
Fazit
Die Suche nach einem „vollständigen auditd-Decoder“ für Wazuh ist verständlich, führt aber in eine Sackgasse. auditd liefert mehr Informationen, als ein zeilenbasierter SIEM-Parser sinnvoll verarbeiten kann. Statt alles dekodieren zu wollen, ist ein selektiver, use-case-getriebener Ansatz deutlich stabiler: relevante auditd-Events gezielt auswerten, komplexe Felder vorverarbeiten und strukturierte Telemetrie dort ergänzen, wo Kontext und Korrelation wichtiger sind als maximale Rohdatenmenge. Genau in dieser Rolle entfaltet Wazuh seinen größten Mehrwert.
Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program
https://wazuh.slack.com/archives/C0A933R8E/p1769458937663249