Einleitung
Die File Integrity Monitoring (FIM)-Komponente von Wazuh, implementiert über syscheck, ist ein zentraler Bestandteil zur Erkennung von Dateiänderungen, Manipulationen und potenziellen Sicherheitsvorfällen. In größeren Umgebungen oder bei ungünstiger Konfiguration stößt diese Komponente jedoch schnell an systemseitige Grenzen. Eine häufige Meldung lautet:
The maximum limit of files monitored has been reached. At this moment there are 100000 files and the limit is 100000. From this moment some events can be lost.
Diese Warnung ist mehr als ein kosmetisches Problem – sie weist auf eine potenzielle Blindstelle im Monitoring hin, bei der Änderungen an nicht überwachten Dateien unentdeckt bleiben können.
Ausgangslage / Problemstellung
In der betrachteten Umgebung trat das Problem wiederholt auf mehreren Servern auf, wobei jeweils die maximale Anzahl von 100.000 überwachten Dateien erreicht wurde. Dies ist der Standardwert für Wazuh-Agenten.
Die unmittelbare Reaktion liegt nahe: Erhöhung des Limits. Technisch ist dies auch problemlos möglich. Allerdings stellt sich die entscheidende Frage, ob dies eine nachhaltige Lösung ist oder lediglich ein Symptom kaschiert.
Parallel dazu wurde deutlich, dass insbesondere bestimmte Server immer wieder betroffen waren – ein Hinweis darauf, dass nicht nur die Anzahl der Dateien, sondern auch die Struktur und Dynamik der überwachten Verzeichnisse eine Rolle spielen.
Technische Analyse
Die FIM-Funktion von Wazuh arbeitet in zwei Modi:
- Periodische Scans (scheduled scans)
- Echtzeitüberwachung (real-time monitoring via inotify auf Linux)
Beide Modi skalieren direkt mit der Anzahl der überwachten Dateien.
Das Limit von 100.000 Einträgen bezieht sich auf die interne Tracking-Struktur des Agents. Wird dieses Limit erreicht:
- Neue Dateien werden nicht mehr in die Überwachung aufgenommen
- Änderungen an diesen Dateien werden nicht erkannt
- Die Integrität des Monitorings ist nicht mehr vollständig gewährleistet
Die Ursache liegt meist nicht in „zu vielen Dateien insgesamt“, sondern in einer ineffizienten Konfiguration von <directories> innerhalb von <syscheck>.
Typische Problemquellen:
- Überwachung von kompletten Root-Pfaden wie
/oder/var - Rekursive Überwachung mit zu hoher Tiefe
- Temporäre Verzeichnisse (
/tmp,/var/tmp) - Log-Verzeichnisse mit hoher Rotationsrate
- Applikationsverzeichnisse mit vielen kurzlebigen Dateien
Zusätzlich verstärkt Realtime Monitoring die Last erheblich, da jede Änderung sofort verarbeitet wird.
Lösung / Best Practices
1. Kurzfristige Maßnahme: Limit erhöhen
Eine Erhöhung des Limits ist technisch möglich und in vielen Fällen kurzfristig sinnvoll:
<syscheck>
<file_limit>
<enabled>yes</enabled>
<entries>150000</entries>
</file_limit>
</syscheck>
Nach Anpassung ist ein Neustart des Agents erforderlich.
Wichtig: Diese Maßnahme behebt nicht die Ursache, sondern verschiebt lediglich die Grenze.
2. Priorisierung statt Vollüberwachung
Statt möglichst viele Dateien zu überwachen, sollte der Fokus auf sicherheitsrelevanten Bereichen liegen:
Typische sinnvolle Targets:
/etc
/bin
/usr/bin
/usr/sbin
/var/www
Nicht empfehlenswert:
/tmp
/var/tmp
/var/log (vollständig)
3. Rekursion gezielt begrenzen
Mit recursion_level lässt sich die Tiefe der Verzeichnisüberwachung einschränken:
<directories recursion_level="2">/var/www</directories>
Dies reduziert die Anzahl der erfassten Dateien drastisch, ohne sicherheitsrelevante Pfade komplett auszuschließen.
4. Filterung über Dateinamen
Mit restrict können nur bestimmte Dateitypen berücksichtigt werden:
<directories restrict="\.conf$|\.sh$">/etc</directories>
Das verhindert, dass irrelevante Dateien (z. B. Cache oder temporäre Artefakte) in die Überwachung einfließen.
5. Realtime Monitoring gezielt einsetzen
Realtime Monitoring sollte nur dort aktiviert werden, wo schnelle Reaktion erforderlich ist:
<directories realtime="yes">/etc</directories>
Für große Verzeichnisbäume mit vielen Änderungen ist ein periodischer Scan oft effizienter.
6. Problematische Hosts gezielt analysieren
Da nur bestimmte Server betroffen waren, empfiehlt sich eine gezielte Analyse:
- Anzahl der Dateien pro überwachten Pfad (
find | wc -l) - Identifikation von „File Explosion“-Verzeichnissen
- Analyse von Applikationen mit hoher Dateidynamik
Lessons Learned / Best Practices
Das Erhöhen des File-Limits ist kein grundsätzliches Problem, solange die Systemressourcen ausreichend dimensioniert sind. Werte von 150.000 oder 200.000 sind auf moderner Hardware meist unkritisch – jedoch nur unter kontrollierten Bedingungen.
Die eigentlichen Risiken liegen in:
- CPU-Spikes während Scans
- Erhöhtem RAM-Verbrauch
- Verlängerten Scan-Zeiten
- Verzögerter Event-Verarbeitung
Besonders kritisch wird es, wenn viele Dateien gleichzeitig überwacht und häufig geändert werden – hier kann FIM zum Performance-Bottleneck werden.
Ein weiterer wichtiger Punkt: Eine ineffiziente FIM-Konfiguration skaliert schlecht. Was auf einem einzelnen Server funktioniert, kann in einer größeren Umgebung schnell zu systemweiten Performanceproblemen führen.
Best Practice ist daher immer:
- Minimale, zielgerichtete Überwachung
- Klare Trennung zwischen sicherheitsrelevanten und operativen Dateien
- Regelmäßige Überprüfung der FIM-Konfiguration im Betrieb
Fazit
Die File-Limit-Warnung in Wazuh ist ein klares Signal für eine überladene oder ineffiziente FIM-Konfiguration. Eine Erhöhung des Limits kann kurzfristig Abhilfe schaffen, löst jedoch nicht das zugrunde liegende Problem.
Nachhaltig ist nur ein Ansatz, der auf selektiver Überwachung, gezielter Filterung und kontrollierter Skalierung basiert. Wer FIM als Sicherheitswerkzeug ernst nimmt, sollte nicht möglichst viele Dateien überwachen, sondern die richtigen.
Quellenverweis
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/syscheck.html#file-limit
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/syscheck.html#directories
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/C07CCCCGHHP/p1776073341546869