Wazuh Rootcheck Ignore funktioniert nicht? Warum Verzeichnisse weiter gemeldet werden und wie sregex das Problem löst

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Rootcheck ist ein zentraler Bestandteil der Host Integrity Monitoring-Strategie in Wazuh. Es prüft das System auf verdächtige Dateien, Rootkits, versteckte Objekte und Policy-Verstöße. Gerade in containerisierten Umgebungen oder bei stark genutzten Web-Roots entstehen jedoch viele „Noise“-Events – etwa unter /var/lib/docker/, /var/lib/containerd/, /tmp/ oder Applikationsverzeichnissen. Die naheliegende Lösung ist das <ignore>-Tag in der Rootcheck-Konfiguration. In der Praxis zeigt sich jedoch häufig: Trotz gesetzter <ignore>-Einträge werden weiterhin Ergebnisse aus genau diesen Verzeichnissen gemeldet.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Typisches Szenario:

<rootcheck>
    <ignore>/var/lib/containerd/</ignore>
    <ignore>/var/lib/docker/overlay2/</ignore> 
    <ignore>/tmp/</ignore>
    <ignore>/var/www/folder/</ignore>
</rootcheck>

Beobachtetes Verhalten:

  • Die Konfiguration ist im ossec.conf oder in der gruppenbasierten agent.conf korrekt gesetzt.
  • Auf dem Agent ist die aktualisierte Konfiguration sichtbar.
  • Trotzdem generiert Rootcheck weiterhin Events aus genau diesen Verzeichnissen.

Das führt zu Verunsicherung: Ist die Konfiguration falsch? Wird sie nicht angewendet? Oder ignoriert Rootcheck die Ignore-Regel?

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) <ignore> ohne Typ ist eine Literal-Prüfung

Standardmäßig interpretiert Wazuh <ignore> als exakten (literal) Match. Das bedeutet:

  • Nur wenn der zu prüfende Pfad exakt dem angegebenen String entspricht, greift die Ignore-Regel.
  • Unterverzeichnisse oder rekursive Inhalte werden nicht automatisch abgedeckt.

Beispiel:

<ignore>/var/www/folder/</ignore>

Das ignoriert nicht automatisch:

  • /var/www/folder/index.php
  • /var/www/folder/subdir/file.php
  • /var/www/folder/.hidden/file

Gerade bei Rootcheck, das rekursiv arbeitet, führt das dazu, dass Unterpfade weiterhin ausgewertet und gemeldet werden.

2) Rootcheck scannt rekursiv – Docker- und Container-Verzeichnisse sind Sonderfälle

Verzeichnisse wie:

  • /var/lib/docker/overlay2/
  • /var/lib/containerd/

enthalten tausende Layer- und Mount-Pfade. Rootcheck verarbeitet diese rekursiv. Ein einfacher Literal-Ignore greift hier nicht, weil die tatsächlichen Pfade tiefer verschachtelt sind.

3) Lösung über type="sregex"

Wazuh unterstützt beim <ignore>-Tag verschiedene Match-Typen, darunter sregex (Simple Regex). Damit kann ein „beginnt mit“-Pattern definiert werden.

Beispiel:

<ignore type="sregex">^/var/www/folder/</ignore>

Das ^ sorgt dafür, dass alle Pfade ignoriert werden, die mit diesem Verzeichnis beginnen. Damit werden auch sämtliche Unterverzeichnisse und Dateien korrekt ausgeschlossen.

Ohne sregex wird der String als exakte Übereinstimmung behandelt – was bei Verzeichnissen fast nie das gewünschte Verhalten ist.

4) Zentralisierte Konfiguration nicht vergessen

Wenn Agents über Gruppen konfiguriert werden (agent.conf im Manager), muss die Rootcheck-Konfiguration dort korrekt hinterlegt sein. Wichtig:

  • Änderungen im Manager verteilen sich erst nach Konfigurations-Synchronisation.
  • Ein Agent-Neustart kann helfen, sicherzustellen, dass Rootcheck mit der neuen Konfiguration startet.
  • Rootcheck muss aktiv sein (<rootcheck><disabled>no</disabled></rootcheck>).

Fehlt die zentrale Konfiguration oder ist sie nicht korrekt zugewiesen, läuft der Agent mit der alten lokalen Definition weiter.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Schritt 1: sregex für Verzeichnisse verwenden

Empfohlene Konfiguration:

<rootcheck>
    <ignore type="sregex">^/var/lib/containerd/</ignore>
    <ignore type="sregex">^/var/lib/docker/overlay2/</ignore>
    <ignore type="sregex">^/tmp/</ignore>
    <ignore type="sregex">^/var/www/folder/</ignore>
</rootcheck>

Damit werden alle Pfade ignoriert, die mit diesen Verzeichnissen beginnen.

Schritt 2: Konfiguration zentral sauber ausrollen

Falls Gruppen verwendet werden:

  1. agent.conf im entsprechenden Gruppenverzeichnis anpassen.
  2. Prüfen, ob der Agent dieser Gruppe zugewiesen ist.
  3. Agent neu starten oder Rootcheck neu initialisieren.

Schritt 3: Scan-Zyklus beachten

Rootcheck arbeitet zyklisch. Nach einer Konfigurationsänderung kann es dauern, bis:

  • ein neuer Scan startet,
  • alte Events aus dem Dashboard verschwinden (je nach Alert-Lifecycle).

Gegebenenfalls Rootcheck manuell neu starten:

systemctl restart wazuh-agent

Schritt 4: Container-Umgebungen strategisch ausnehmen

In produktiven Docker-/Kubernetes-Umgebungen ist es Best Practice:

  • Container-Storage-Pfade grundsätzlich per sregex auszunehmen.
  • Stattdessen auf FIM (File Integrity Monitoring) mit gezielten Policies für Applikationspfade zu setzen.
  • Rootcheck auf Host-relevante Verzeichnisse zu fokussieren.

Das reduziert Last und vermeidet unnötige Alerts.

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  • Verzeichnisse immer mit type="sregex" ignorieren, wenn Unterpfade ausgeschlossen werden sollen.
  • Literal-Ignore ist nur sinnvoll für einzelne, exakt bekannte Dateien.
  • In Container-Hosts Rootcheck-Scopes bewusst einschränken – Overlay-Filesysteme erzeugen sonst massiven Noise.
  • Änderungen an Rootcheck-Konfigurationen sollten als Teil eines Change-Prozesses mit Test-Agent validiert werden.
  • Konfigurationsquelle prüfen: Lokal (ossec.conf) vs. zentral (agent.conf) – doppelte oder widersprüchliche Definitionen vermeiden.

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn Rootcheck trotz gesetzter <ignore>-Einträge weiterhin Verzeichnisse scannt, liegt das fast immer an der Standard-Literal-Interpretation des Tags. Ohne type="sregex" wird kein rekursives „beginnt mit“-Matching durchgeführt. Die korrekte Lösung ist die Verwendung von sregex mit einem Anker (^), um komplette Verzeichnisbäume zuverlässig auszuschließen. In containerisierten Umgebungen ist das nicht nur eine Komfortfrage, sondern essenziell, um Performance-Probleme und Alert-Flooding zu vermeiden.

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/p1770153061115959