Wenn Auditd plötzlich dich selbst überwacht

von

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!