imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

2026-09-15T00:00:00Z

Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

Neue Seite

== Wie wir <code>/var/log</code> ü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
* <code>auditd</code> 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''' (<code>audit-wazuh-w/x/c/...</code>)
* Audit-Regeln sind '''reihenfolgeabhängig'''
* Noise muss '''vor''' den eigentlichen Regeln rausgefiltert werden

Also gingen wir den nächsten logischen Schritt.

== Der Plan: <code>/var/log</code> ü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:

<syntaxhighlight lang="text">
-w /var/log -p wa -F auid>=1000 -F auid!=4294967295 -k audit-wazuh-w
</syntaxhighlight>

Klingt perfekt:

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

Und ja: '''User-Aktionen wurden sauber geloggt.'''

== Das Problem: Auditd loggt plötzlich Wazuh selbst ==

Kurz darauf tauchte im <code>audit.log</code> regelmäßig folgendes auf:

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

Alle paar Sekunden.

=== Was passiert hier? ===

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

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

„Überwache Zugriffe auf <code>/var/log</code>“

Das Problem:

'''Jetzt überwacht Wazuh sich selbst.'''

== Warum der <code>auid</code>-Filter nicht geholfen hat ==

Wir hatten extra:

<syntaxhighlight lang="text">
-F auid>=1000
-F auid!=4294967295
</syntaxhighlight>

Aber trotzdem kam der Event.

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

'''Watch-Regeln (<code>-w</code>) erzeugen Events, bevor User-Filter greifen.'''

Der Kernel:

# sieht Zugriff auf <code>/var/log</code>
# erzeugt Event
# danach werden Filter angewendet

👉 Für Daemons reicht <code>auid</code> '''nicht''' als Ausschluss.

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

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

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

=== Korrekte Exclude-Regel ===

Datei:

<syntaxhighlight lang="text">
/etc/audit/rules.d/05-noise.rules
</syntaxhighlight>

<syntaxhighlight lang="text">
# 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
</syntaxhighlight>

Warum das funktioniert:

* gleiche Regelklasse (<code>exit</code>)
* gleicher Syscall (<code>openat</code>)
* identischer Prozess (<code>exe=</code>)
* '''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
* <code>auid</code> 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) ==

<syntaxhighlight lang="text">
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
</syntaxhighlight>

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 [https://wazuh-blog.max-it.de/anleitungen/agents/auditd-auf-debian-installieren-und-fuer-wazuh-optimieren/ hier!]

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/wenn-auditd-ploetzlich-dich-selbst-ueberwacht/ 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 [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]

Wenn Auditd plötzlich dich selbst überwacht - Versionsgeschichte

imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)