Wenn Auditd plötzlich dich selbst überwacht

Wie wir /var/log überwachen wollten – und Wazuh zum Noise-Generator wurde

Wer Auditd produktiv einsetzen will, lernt relativ schnell eine harte Wahrheit:

Auditd ist gnadenlos ehrlich. Es loggt nicht nur Angriffe – sondern auch dich selbst.

In diesem Beitrag zeige ich, wie wir auf Debian ein sauberes Auditd-Setup für Wazuh aufgebaut haben, warum plötzlich der Wazuh-Logcollector selbst im Audit-Log landete, und wie man das kernel-seitig korrekt löst – ohne die eigentliche Sicherheitsidee zu zerstören.

Ausgangspunkt: Auditd + Neo23x0 + Wazuh

Unser Setup:

• Debian
• auditd mit Neo23x0 Ruleset
• Wazuh Agent + zentraler Manager
• Ziel:

Root-Kommandos nachvollziehbar machen

• Log-Manipulation erkennen
• kein Log-Spam

Wir hatten bereits gelernt:

• Wazuh nutzt Keys als Kategorien (audit-wazuh-w/x/c/...)
• Audit-Regeln sind reihenfolgeabhängig
• Noise muss vor den eigentlichen Regeln rausgefiltert werden

Also gingen wir den nächsten logischen Schritt.

Der Plan: /var/log überwachen – aber nur echte Benutzer

Was wir wollten:

Alarm, wenn jemand Logfiles löscht oder verändert – aber nicht, wenn systemd, cron oder Logrotate arbeiten.

Die klassische Audit-Regel dafür:

-w /var/log -p wa -F auid>=1000 -F auid!=4294967295 -k audit-wazuh-w

Klingt perfekt:

• -p wa → write + attribute (löschen, umbenennen, chmod)
• auid>=1000 → echte Benutzer
• audit-wazuh-w → Wazuh-Standard-Key

Und ja: User-Aktionen wurden sauber geloggt.

Das Problem: Auditd loggt plötzlich Wazuh selbst

Kurz darauf tauchte im audit.log regelmäßig folgendes auf:

comm="wazuh-logcollec"
exe="/var/ossec/bin/wazuh-logcollector"
syscall=openat
exit=13
auid=unset
key="audit-wazuh-w"

Alle paar Sekunden.

Was passiert hier?

• wazuh-logcollector liest Logfiles
• dafür nutzt er openat()
• einige Dateien darf er nicht lesen → EACCES (13)
• Auditd loggt jeden Versuch, nicht nur Erfolge

Auditd tut also genau das, was wir ihm gesagt haben:

„Überwache Zugriffe auf /var/log“

Das Problem:

Jetzt überwacht Wazuh sich selbst.

Warum der auid-Filter nicht geholfen hat

Wir hatten extra:

-F auid>=1000
-F auid!=4294967295

Aber trotzdem kam der Event.

Der Grund ist ein Detail, das in vielen Anleitungen fehlt:

Watch-Regeln (-w) erzeugen Events, bevor User-Filter greifen.

Der Kernel:

1. sieht Zugriff auf /var/log
2. erzeugt Event
3. danach werden Filter angewendet

👉 Für Daemons reicht auid nicht als Ausschluss.

Die richtige Lösung: syscall-Exclude VOR der Watch-Rule

Die Lösung ist nicht, /var/log weniger streng zu überwachen. Die Lösung ist:

Den verursachenden Prozess auf Syscall-Ebene ausschließen – früh.

Korrekte Exclude-Regel

Datei:

/etc/audit/rules.d/05-noise.rules

# Ignore wazuh logcollector access to /var/log
-a never,exit -F arch=b64 -S openat -F exe=/var/ossec/bin/wazuh-logcollector
-a never,exit -F arch=b32 -S openat -F exe=/var/ossec/bin/wazuh-logcollector

Warum das funktioniert:

• gleiche Regelklasse (exit)
• gleicher Syscall (openat)
• identischer Prozess (exe=)
• wird vor der Watch-Rule geladen

Ergebnis:

• der Kernel erzeugt das Event gar nicht erst
• kein Audit-Log
• kein Wazuh-Noise
• User-Manipulationen bleiben sichtbar

Die entscheidende Lektion aus dem Debugging

Diese Situation hat ein wichtiges Auditd-Prinzip bestätigt:

Auditd ist kein „Filter nachträglich“-System. Es ist ein „Entscheide früh oder lebe mit dem Event“-System.

Merksätze aus der Praxis:

• Watch-Regeln sind mächtig – aber gnadenlos
• auid hilft gegen Systemdienste, nicht gegen Watch-Noise
• Excludes müssen:

gleiche Regelklasse

• gleichen Syscall
• früher geladen

Wazuh sollte niemals sich selbst auditieren

Unser finales, sauberes Setup (Kurzfassung)

05-noise.rules
  - zabbix_agentd (socket)
  - wazuh-logcollector (openat)

40-var-log.rules
  -w /var/log -p wa -F auid>=1000 -k audit-wazuh-w

60-neo.rules
  Neo23x0 Baseline

70-rootcmd.rules
  execve als root

Ergebnis:

• 🔍 echte Log-Manipulation sichtbar
• 🧠 kein Self-Noise
• 📉 kontrolliertes Log-Volumen
• 🔐 forensisch brauchbar

Fazit

Auditd ist kein Plug-and-Play-Tool. Aber wenn man einmal verstanden hat:

• Regelreihenfolge
• Regelklassen
• Watch vs. Syscall
• Kernel-seitiges Filtern

…dann bekommt man genau das, was man will:

Signale statt Rauschen.

Und genau darum geht es bei Security-Logging.

Weitere Informationen zu auditd findet man hier!

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 2. Januar 2026).

Unterstützung von m.a.x. it

Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.

Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen