Quelltext der Seite Wazuh FIM: File-Limit erhöhen bei Millionen von Dateien

== Saubere Konfiguration, Grenzen und Performance-Auswirkungen ==

== Einleitung ==

In großen Umgebungen – etwa auf File-Servern, Storage-Systemen oder Windows Storage Spaces – stößt das '''File Integrity Monitoring (FIM / Syscheck)''' von Wazuh schnell an seine Standardgrenzen.
Ein typisches Szenario sind '''1.000.000+ Dateien''', die überwacht werden sollen.

Dieser Artikel erklärt:

* warum das einfache Setzen von <code><file_limit></code> oft nicht ausreicht
* wie die '''korrekte Syntax''' aussieht
* welche '''harten Grenzen''' gelten
* und welche '''Performance- und Architektur-Folgen''' ein so großes FIM-Setup hat

== 1. Ausgangssituation aus dem Community-Thread ==

=== Ziel ===

Überwachung von '''> 1.000.000 Dateien''' mit Wazuh FIM auf einem Windows-Agenten.

=== Ursprüngliche Konfiguration (Agent) ===

<syntaxhighlight lang="text">
<syscheck>
  <frequency>600</frequency>
  <file_limit>1000000000</file_limit>
  <alert_new_files>yes</alert_new_files>
  <directories report_changes="yes" whodata="yes" realtime="yes">
    D:\StorageSpace\*
  </directories>
</syscheck>
</syntaxhighlight>

➡️ Problem:
Die Konfiguration ist '''syntaktisch nicht korrekt''' für aktuelle Wazuh-Versionen und wird '''nicht wie erwartet interpretiert'''.

== 2. Die korrekte Syntax für <code><file_limit></code> ==

Seit mehreren Versionen erwartet Wazuh eine '''strukturierte Konfiguration''' für das File-Limit.

=== ✅ Empfohlene und unterstützte Syntax ===

<syntaxhighlight lang="text">
<syscheck>
  <frequency>600</frequency>

  <file_limit>
    <enabled>yes</enabled>
    <entries>1000000</entries>
  </file_limit>

  <alert_new_files>yes</alert_new_files>

  <directories report_changes="yes" whodata="yes" realtime="yes">
    D:\StorageSpace\
  </directories>
</syscheck>
</syntaxhighlight>

=== Wichtige Punkte ===

* <code><entries></code> ist der '''entscheidende Parameter'''
* Gültiger Wertebereich: <code>1 – 2147483647</code>
* Werte darüber hinaus werden '''intern nicht unterstützt'''

📘 Offizielle Referenz:
[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#file-limit]

== 3. Was bedeutet das File-Limit technisch? ==

Das File-Limit definiert:

* die '''maximale Anzahl an Dateien''', die Syscheck '''in den internen Datenstrukturen''' halten darf
* '''nicht''' die Anzahl der Dateien auf dem Dateisystem selbst

Wird das Limit erreicht:

* neue Dateien werden '''nicht mehr überwacht'''
* im Agent-Log erscheinen Warnungen
* Änderungen an nicht erfassten Dateien bleiben '''unsichtbar'''

== 4. Performance- und Ressourcenfolgen bei >1 Mio Dateien ==

=== CPU ===

* Initialscan sehr CPU-intensiv
* Realtime + whodata verstärken Last massiv

=== RAM ===

* Jeder überwachte Eintrag benötigt Speicher
* Millionen Dateien ⇒ mehrere 100 MB RAM '''nur für Syscheck'''

=== I/O ===

* Realtime + whodata ⇒ hohe NTFS-Event-Last
* Besonders kritisch auf Windows-Servern

📚 Hintergrund:

* [https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals]
* [https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html]

== 5. Wichtige Best Practices bei großen FIM-Setups ==

=== ✅ 1. Realtime & Whodata gezielt einsetzen ===

Nicht alles braucht Realtime-Monitoring:

<syntaxhighlight lang="text">
<directories report_changes="yes">D:\Archive\</directories>
<directories report_changes="yes" realtime="yes">D:\HotData\</directories>
</syntaxhighlight>

📘 Whodata-Doku:
https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/whodata.html

=== ✅ 2. Ausschlüsse nutzen ===

Temporäre oder irrelevante Dateien explodieren die Anzahl:

<syntaxhighlight lang="text">
<ignore>*.tmp</ignore>
<ignore>*.log</ignore>
<ignore>D:\StorageSpace\cache\</ignore>
</syntaxhighlight>

=== ✅ 3. Initialscan bewusst planen ===

Große FIM-Scans sollten:

* '''außerhalb der Peak-Zeit'''
* mit angepasster <code>frequency</code>
* ggf. mit deaktiviertem Realtime beim Erstscan erfolgen

=== ✅ 4. Agent-Logs beobachten ===

Wichtige Dateien:

<syntaxhighlight lang="text">
C:\Program Files (x86)\ossec-agent\ossec.log
</syntaxhighlight>

Typische Warnungen:

* <code>Maximum number of files reached</code>
* <code>Syscheck database full</code>

== 6. Wann FIM architektonisch falsch ist ==

FIM ist '''nicht''' ideal für:

* reine Archivsysteme
* Data Lakes
* Backup-Repositories
* Content Stores mit Millionen statischer Objekte

Alternativen:

* Storage-eigene Auditing-Mechanismen
* Hash-basierte Offline-Scans
* SIEM-Korrelation auf Applikationsebene

== 7. Häufige Missverständnisse ==

AnnahmeRealitätfile_limit = große Zahl → alles gut❌Realtime ist immer sinnvoll❌Whodata ist „kostenlos“❌FIM skaliert beliebig❌

== 8. Quellen & weiterführende Links ==

=== Offizielle Wazuh Dokumentation ===

* Syscheck / File limit[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#file-limit]
* File Integrity Monitoring[https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/index.html]
* Whodatahttps://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/whodata.html

=== Windows & Filesystem ===

* NTFS Change Journal[https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals https://learn.microsoft.com/en-us/windows/win32/fileio/change-journals]

=== Performance & Scaling ===

* Wazuh Agent Tuninghttps://documentation.wazuh.com/current/user-manual/agents/agent-management/agent-tuning.html

== Fazit ==

❝ FIM mit Millionen Dateien ist möglich –
aber nur mit sauberer Konfiguration, klarer Scope-Definition
und realistischen Performance-Erwartungen. ❞

'''Richtig gesetzt''' ist <code><file_limit></code> kein Problem.
'''Unkontrolliert genutzt''' wird FIM schnell zum Ressourcenfresser.

[https://wazuh.slack.com/archives/C0A933R8E/p1766383149953699 https://wazuh.slack.com/archives/C0A933R8E/p1766383149953699]

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/wazuh-fim-file-limit-erhoehen-bei-millionen-von-dateien/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 18. März 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]]