Wie Wazuh File Integrity Monitoring (FIM) funktioniert – Architektur, Best Practices & tiefergehende Analyse

von

File Integrity Monitoring (FIM) ist eine zentrale Sicherheitskomponente moderner Endpoint-Überwachung. Es ermöglicht Administratoren, Dateiänderungen in Echtzeit zu erkennen, Integritätsverstöße aufzudecken und sicherheitsrelevante Manipulationen zu protokollieren.
Ein Slack-Thread aus der Wazuh-Community bot einen detaillierten Einblick in die Funktionsweise und Praxis, den wir in diesem Blogpost strukturiert zusammenführen und erweitern.

1. Wie arbeiten Kernel und Wazuh-Agent zusammen?

Wazuh nutzt je nach Betriebssystem verschiedene Mechanismen, um Datei-Events effizient und zuverlässig zu erfassen.

Linux: inotify

Auf Linux-Systemen basiert die Echtzeitüberwachung auf inotify, einem Kernel-Subsystem zur Dateisystemüberwachung.
Wazuh:

  • registriert „Watches“ auf den definierten Pfaden
  • erhält Events bei Änderungen (Create, Modify, Delete, Attribute Change etc.)
  • verarbeitet diese Events über den Thread fim_realtime_event_loop()

Windows: ReadDirectoryChangesW

Auf Windows nutzt Wazuh die API ReadDirectoryChangesW, die ein ähnliches Event-Modell bereitstellt.

Fallback: Scheduled Scans

Wenn ein System kein Echtzeitmonitoring unterstützt, führt der Agent periodische, rekursive Scans durch.

Ergebnis: Wazuh verwendet die jeweils effizienteste OS-native Schnittstelle, um Änderungen performant zu überwachen.

2. Wie informiert der Kernel Wazuh über Dateiänderungen?

Der Kernel sendet Ereignisse direkt an die Wazuh-FIM-Komponenten:

  • Ein inotify-Watch überwacht einen Pfad
  • Bei einer Änderung generiert der Kernel ein Event
  • Wazuh liest dieses Event und leitet es zur weiteren Verarbeitung an fim_checker weiter

Der Vorteil:
Keine Polling-Last, keine ineffizienten Schleifen, keine systemweiten Hooks.

3. Wie prüft Wazuh Dateiänderungen? – Hashing und Validierung

Wenn Wazuh ein Änderungsereignis empfängt, führt es folgende Schritte aus:

  1. Datei lesen
  2. Hash berechnen – typischerweise MD5, SHA1 und SHA256
  3. Hash mit vorherigem Wert vergleichen
  4. Integritätsereignis generieren, wenn Differenzen bestehen

Dies erfolgt über den fim_checker, der die Hash-Datenbank des Agents verwaltet.

Wichtig: Wazuh sperrt Dateien nicht.
Der Agent liest Dateien nicht exklusiv, sondern nutzt normale Read-Operationen.

4. Beeinflusst Wazuh die Systemleistung?

Ein spezieller Wazuh-Bug ist nicht bekannt, aber es gibt einen wichtigen techn. Aspekt:

Inotify verwendet File Descriptors – viele davon.

Für jede überwachte Datei/Ordner wird ein File Descriptor genutzt. Systeme mit vielen FIM-Pfaden benötigen erhöhte Kernel-Limits:

Wichtige Parameter:

  • fs.inotify.max_user_watches
  • fs.inotify.max_user_instances
  • fs.inotify.max_queued_events

Wenn diese Limits zu niedrig sind:

  • können nicht alle Pfade überwacht werden
  • Events gehen verloren
  • Ressourcenengpässe entstehen
  • der Agent zeigt Fehler oder Warnungen

Wazuh selbst öffnet nur so viele Deskriptoren, wie es benötigt – eine Fehlkonfiguration des OS führt jedoch zu Problemen.

5. Sperrt Wazuh Dateien beim Hashen?

Diese Frage wurde im Thread ausdrücklichgestellt – die Antwort ist eindeutig:

Nein, Wazuh sperrt Dateien nicht.

  • Wazuh verwendet keinen „exclusive lock“
  • Der Hash wird aus einem normalen Read angefertigt
  • Anwendungen können gleichzeitig schreiben
  • Der Hash repräsentiert den Zustand zum Zeitpunkt der Leseoperation

Dies ist besonders wichtig für:

  • Datenbanken
  • Log-Dateien
  • kritische Produktionsanwendungen
  • Systeme mit hohen I/O-Anforderungen

6. Tiefergehende technische Analyse des FIM-Moduls

Um das Verhalten besser zu verstehen, ist ein Blick auf die Architektur sinnvoll.

6.1 FIM Realtime Pipeline

  1. inotify-Event → z. B. IN_MODIFY
  2. Wazuh empfängt Event über File-Descriptor der Watch
  3. Event wird in eine interne Queue geschrieben
  4. fim_realtime_event_loop() verarbeitet die Queue sequentiell
  5. FIM Checker führt eine tiefergehende Analyse durch (Hash, Attribute etc.)
  6. Wazuh-Agent sendet Ereignis an den Manager
  7. Manager weist das Event einer FIM-Regel zu

Dieses Modell ist robust und ressourceneffizient.

6.2 CPU- und IO-Verhalten

Das Hashen großer Dateien kann CPU-intensiv sein.
In folgenden Szenarien kann es zu Lastspitzen kommen:

  • massive Modifikationen in kurzer Zeit
  • hohe Anzahl sehr großer Dateien
  • unzureichende Hardware
  • zu breit konfigurierter FIM-Pfad (z. B. /var/log/** ohne Filter)

Wazuh nutzt Multithreading und asynchrone Queues, um diese Last zu dämpfen.

6.3 FIM Datenbankstruktur

Wazuh speichert:

  • Pfad
  • inode
  • Dateiattribute
  • MD5/SHA1/SHA256 Hashes
  • letzte Änderung
  • Größe

Diese Daten werden genutzt, um FIM-Ereignisse klassifiziert zu erzeugen:

  • added
  • modified
  • deleted
  • attributes_changed
  • permission_changed

7. FIM Best Practices – so holst du maximale Sicherheit & Stabilität heraus

Hier eine kompakte, praxiserprobte Liste:

7.1 Monitor nur das, was notwendig ist

Überwachung großer oder irrelevanter Pfade führt zu:

  • erhöhter Last
  • massiven inotify-Watch-Verbrauch
  • unübersichtlichen Logs

Besser: gezielt kritische Pfade konfigurieren (SSH-Keys, Systembinaries, Config-Files).

7.2 Nutze White- und Blacklists

Filter in ossec.conf vermeiden Lärm:

  • ignore
  • restrict
  • regex-basierte Ausschlüsse

Damit bleibt FIM aussagekräftig und performant.

7.3 inotify-Limits anpassen

Empfohlene Werte:

fs.inotify.max_user_watches=524288
fs.inotify.max_user_instances=1024
fs.inotify.max_queued_events=32768

Persistieren via /etc/sysctl.d/90-wazuh-fim.conf.

7.4 Große und dynamische Dateien ausschließen

Dazu gehören:

  • Logs
  • Datenbanken
  • VMs
  • Docker-Layer
  • Swapfiles

Hashing solcher Dateien bringt wenig Mehrwert, aber enorme Last.

7.5 Scheduled Scans vorsichtig einsetzen

Nur wenn Echtzeitüberwachung nicht möglich ist.
Intervall nicht zu niedrig setzen – CPU-Last!

7.6 Hash-Algorithmen bewusst wählen

SHA1 + SHA256 als Kombination ist guter Standard.
MD5 optional, aber aus Sicht der Sicherheit entbehrlich.

7.7 Monitoring nicht zu breit

Schlechtes Beispiel:

/etc/**

Besser:

/etc/passwd  
/etc/shadow  
/etc/ssh/sshd_config  
/etc/sudoers

7.8 Alerts ins SIEM sinnvoll mappen

FIM erzeugt viele Events.
Gute Korrelation & Normalisierung spart Zeit bei der Analyse.

7.9 Prüfe Interaktion mit anderen Tools

Insbesondere:

  • Antivirus
  • Backup-Prozesse
  • EDR
  • Datenbank-Engines

Einige Tools triggern unnötig viele FIM-Events.

7.10 Testen, testen, testen

  • Performance
  • Realtime-Detection
  • Hash-Logik
  • Exclusion-Regeln

FIM ist ein sensibles System – sauberes Tuning ist entscheidend.

Fazit

Der Slack-Thread zeigte klar:

  • Wazuh FIM ist technisch ausgereift, effizient und zuverlässig.
  • Kernelmechanismen wie inotify oder ReadDirectoryChangesW bilden die Basis.
  • Wazuh sperrt Dateien nicht, sondern liest sie rein passiv.
  • Performanceprobleme entstehen meist durch falsche OS-Limits oder zu breite Monitorings.
  • Mit den richtigen Best Practices wird Wazuh FIM extrem leistungsfähig – und bleibt stabil.

Wazuh liefert damit ein robustes, nicht-invasives und betriebssicheres FIM-Modul, das sich perfekt für produktive Systeme eignet.

Mehr zu Wazuh …

Mehr zum Wazuh Ambassador Program …