Datei-Integritätsmonitoring (FIM): Was, Warum, Wie

Key Takeaways

• FIM überwacht Dateien und Verzeichnisse auf unautorisierte Änderungen und macht Angriffe wie Webshell-Einschleusung oder Konfigurationsmanipulation frühzeitig sichtbar.
• NIS-2 und DSGVO verlangen nachweisbare Kontrollmechanismen für kritische Systeme — FIM liefert den nötigen Audit-Trail.
• Wazuh bietet ein leistungsfähiges, quelloffenes FIM-Modul, das mit wenigen Konfigurationszeilen produktionsreif ist.
• Ohne saubere Baseline und Alert-Tuning erzeugt FIM mehr Rauschen als Erkennung — das ist der häufigste Grund, warum Deployments scheitern.

Was ist Datei-Integritätsmonitoring?

Datei-Integritätsmonitoring (FIM) ist ein Sicherheitsverfahren, das Dateisysteme kontinuierlich auf Änderungen überwacht. Konkret erstellt FIM einen Referenzzustand (Baseline) für definierte Dateien und Verzeichnisse — Prüfsummen, Berechtigungen, Zeitstempel, Eigentümer — und meldet jede Abweichung davon.

Das klingt technisch simpel, ist in der Praxis aber eines der zuverlässigsten Erkennungswerkzeuge im Sicherheitsbetrieb. Ein Angreifer, der in ein System eingedrungen ist, hinterlässt fast immer Spuren im Dateisystem: eine neue ausführbare Datei, eine modifizierte Konfiguration, ein Webshell-Fragment in einem Upload-Verzeichnis. FIM macht genau diese Spuren sichtbar — oft bevor andere Erkennungsmechanismen wie EDR oder IDS anschlagen.

FIM ist kein neues Konzept. Tools wie Tripwire existieren seit den frühen 1990er Jahren. Was sich geändert hat: Moderne SIEM-Systeme wie Wazuh integrieren FIM nativ, korrelieren Dateiänderungen mit anderen Ereignissen und ermöglichen so kontextreiche Alerts statt isolierter Einzelmeldungen. Das macht FIM auch für KMU ohne dediziertes Security-Team handhabbar.

Warum FIM für KMU unverzichtbar ist

Angriffsvektoren, die FIM sichtbar macht

Webshell-Einschleusung: Ein Angreifer nutzt eine Upload-Funktion oder eine Schwachstelle in einem CMS (WordPress, Joomla, Typo3) um eine PHP- oder ASPX-Datei in ein Web-Verzeichnis zu schreiben. FIM erkennt die neue Datei in /var/www/html und löst einen Alert aus — idealerweise bevor der Angreifer die Shell für weitere Aktionen nutzt.

Persistence-Mechanismen: Nach einem erfolgreichen Einbruch schreiben Angreifer typischerweise in Startup-Verzeichnisse, Cron-Jobs oder Systemd-Units. Unter Linux sind das Pfade wie /etc/cron.d/, /etc/systemd/system/ oder ~/.bashrc. FIM auf diesen Pfaden erkennt neue oder veränderte Persistence-Mechanismen unmittelbar.

Konfigurationsmanipulation: Ein kompromittiertes System zeigt sich oft durch veränderte Konfigurationsdateien — ein zusätzlicher SSH-Schlüssel in /root/.ssh/authorized_keys, eine veränderte /etc/sudoers, ein modifiziertes sshd_config mit PermitRootLogin yes. Das sind klassische FIM-Treffer mit hoher Signalqualität.

Ransomware-Früherkennung: Ransomware verschlüsselt Dateien — dabei ändern sich Prüfsummen massenhaft in kurzer Zeit. FIM kann dieses Muster (viele Änderungen in kurzer Zeit auf denselben Verzeichnissen) als Anomalie erkennen und einen Alarm auslösen, bevor die Verschlüsselung abgeschlossen ist. Nicht jede FIM-Implementierung leistet das, Wazuh kann entsprechende Korrelationsregeln abbilden.

Supply-Chain-Angriffe: Wenn ein Softwarepaket oder eine Bibliothek heimlich modifiziert wurde — ein zunehmendes Problem, wie SolarWinds oder XZ Utils gezeigt haben — kann FIM erkennen, dass sich Binaries oder Shared Libraries verändert haben, ohne dass ein reguläres, dokumentiertes Update stattgefunden hat.

NIS-2 und DSGVO: Compliance-Anforderungen

NIS-2 (Artikel 21) verlangt von betroffenen Unternehmen technische Maßnahmen zur Erkennung von Sicherheitsvorfällen und zur Gewährleistung der Systemintegrität. FIM ist ein direkter, nachweisbarer Beitrag dazu — und liefert gleichzeitig den Audit-Trail, den Prüfer und Behörden im Ernstfall einfordern.

Die DSGVO (Artikel 32) fordert geeignete technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten, einschließlich der Fähigkeit, Sicherheitsverletzungen zu erkennen und darauf zu reagieren. Ein System, das unautorisierte Zugriffe auf Datenbank-Konfigurationen oder Backup-Verzeichnisse nicht erkennt, hat hier eine nachweisbare Lücke.

Konkret: Wenn ein Angreifer die Konfigurationsdatei einer Datenbank mit DSGVO-relevanten Daten ändert, ist das potenziell ein meldepflichtiger Vorfall (Art. 33 DSGVO, 72-Stunden-Frist). FIM gibt Ihnen den Zeitstempel, den betroffenen Pfad und — im Who-data-Modus — den verantwortlichen Benutzer oder Prozess. Ohne diese Informationen sind Ihrer Meldung gegenüber der Aufsichtsbehörde die Hände gebunden.

Der BSI-Grundschutz (Baustein SYS.1.1, OPS.1.1.5) empfiehlt explizit die Überwachung sicherheitsrelevanter Dateien und Verzeichnisse. FIM ist hier keine Kür, sondern Pflichtumsetzung.

Wie FIM in Wazuh funktioniert

Architektur und Betriebsmodi

Wazuh FIM ist als Teil des Wazuh-Agenten implementiert, der auf jedem überwachten System läuft. Das FIM-Modul — intern als syscheck bezeichnet — arbeitet in drei Modi:

Scheduled Mode: Der Agent scannt die konfigurierten Pfade in definierten Intervallen (Standard: alle 12 Stunden). Änderungen werden beim nächsten Scan erkannt. Für weniger zeitkritische Systeme ausreichend und ressourcenschonend.

Real-time Mode: Nutzt Betriebssystem-APIs (inotify unter Linux, ReadDirectoryChangesW unter Windows), um Dateiänderungen sofort zu erkennen. Die Latenz liegt typischerweise unter einer Sekunde. Empfohlen für kritische Pfade wie Web-Verzeichnisse und Systemkonfigurationen.

Who-data Mode: Erweitert Real-time um Audit-Informationen — welcher Prozess und welcher Benutzer die Änderung vorgenommen haben. Nutzt unter Linux das Linux Audit Framework (auditd) und liefert damit die forensisch verwertbaren Informationen für Incident-Response und Compliance-Reporting.

Konfiguration: Ein praxisnahes Beispiel

Die FIM-Konfiguration erfolgt in der ossec.conf auf dem Agenten oder zentral über den Wazuh-Manager (empfohlen für größere Umgebungen). Hier ein produktionsnahes Konfigurationsbeispiel:

<syscheck>
  <!-- Intervall für geplante Scans (6 Stunden) -->
  <frequency>21600</frequency>

  <!-- Kritische Systempfade: Real-time mit Who-data -->
  <directories check_all="yes" realtime="yes" whodata="yes">/etc</directories>
  <directories check_all="yes" realtime="yes" whodata="yes">/bin,/sbin,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes" realtime="yes" whodata="yes">/var/www/html</directories>

  <!-- Applikationsverzeichnis anpassen -->
  <directories check_all="yes" realtime="yes">/opt/app/config</directories>

  <!-- Windows: Autostart-Registrierungsschlüssel -->
  <windows_registry>HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run</windows_registry>
  <windows_registry>HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services</windows_registry>

  <!-- Ausschlüsse: volatile Dateien ohne Sicherheitsrelevanz -->
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore type="sregex">.log$|.tmp$|.swp$|.pid$</ignore>

  <!-- SHA-256 als Prüfsummen-Algorithmus -->
  <hash_algorithm>sha256</hash_algorithm>

  <!-- Alert bei neu angelegten Dateien -->
  <alert_new_files>yes</alert_new_files>

  <!-- Scan direkt beim Agenten-Start -->
  <scan_on_start>yes</scan_on_start>
</syscheck>

Der whodata-Modus setzt voraus, dass auditd auf dem System läuft und Wazuh die notwendigen Audit-Regeln setzen darf. In vielen minimalen Linux-Installs fehlt auditd:

# Debian/Ubuntu
apt install auditd audispd-plugins

# RHEL/CentOS/Rocky Linux
yum install audit

# Dienst aktivieren — Wazuh setzt Audit-Regeln dann automatisch
systemctl enable --now auditd

Tuning: Baseline und Alert-Qualität

Das größte praktische Problem bei FIM-Deployments ist nicht die Erstkonfiguration, sondern das Rauschen im laufenden Betrieb. Auf einem aktiven Linux-System mit regelmäßigen Paketaktualisierungen und laufenden Applikationen erzeugt ein ungetuntes FIM innerhalb weniger Stunden hunderte von Alerts — die meisten davon legitim, aber für die Angriffserkennung irrelevant.

Ein strukturierter Tuning-Prozess verhindert das:

Schritt 1 — Baseline-Phase: Neues FIM-Deployment zunächst im Scheduled-Mode betreiben, ohne Alert-Output nach außen zu leiten. Eine bis zwei Wochen normalen Betrieb dokumentieren und das Änderungsverhalten verstehen.

Schritt 2 — Ausschlüsse ableiten: Aus der Baseline werden Muster für sinnvolle Ausschlüsse abgeleitet. Log-Dateien, Cache-Verzeichnisse, temporäre Dateien, automatisch aktualisierte Konfigurations-Snippets (z.B. Let's Encrypt Zertifikate) — diese gehören in die Ignore-Liste.

Schritt 3 — Regel-Tuning im Manager: Wazuh erlaubt, FIM-Regeln in local_rules.xml zu überschreiben oder zu supprimieren:

<!-- Supprimiere FIM-Alerts für automatische Let's Encrypt Renewals -->
<rule id="100001" level="0">
  <if_sid>550</if_sid>
  <field name="syscheck.path">/etc/letsencrypt/</field>
  <description>Ignore LE cert renewals</description>
</rule>

<!-- Erhöhe Severity für neue Dateien im Web-Verzeichnis -->
<rule id="100002" level="12">
  <if_sid>554</if_sid>
  <field name="syscheck.path">/var/www/html/</field>
  <description>New file in web root — possible webshell</description>
</rule>

Schritt 4 — Korrelation aktivieren: Ein einzelner FIM-Alert hat begrenzten Wert. Interessant wird es, wenn FIM-Events mit anderen Ereignissen korreliert werden — etwa ein FIM-Alert auf /var/www/html kombiniert mit einem vorherigen WAF-Alert oder einem ungewöhnlichen POST-Request auf dieselbe Anwendung. Wazuh ermöglicht diese Korrelation über seine Regelengine.

FIM in hybriden Microsoft-365- und Azure-Umgebungen

Für KMU, die lokale Server mit Microsoft 365 oder Azure-Workloads kombinieren, gibt es ergänzende Ansätze:

Microsoft Defender for Cloud (ehemals Azure Security Center) bietet für Azure-VMs ein integriertes FIM unter dem Namen "File Integrity Monitoring". Es überwacht Dateien, Verzeichnisse und Registrierungsschlüssel und liefert Alerts über das Security Center-Dashboard.

Wazuh als einheitliche Schicht: Azure Defender for Cloud deckt nur Azure-VMs ab. On-Premises-Server, AWS-Instanzen oder andere Umgebungen bleiben außen vor. Wazuh fungiert hier als übergreifende FIM-Plattform, die alle Systeme in einem zentralen Dashboard aggregiert — ohne Vendor-Lock-in und ohne pro-Asset-Lizenzkosten.

Microsoft 365 und SharePoint: Klassisches FIM ist für Cloud-Speicher nicht direkt anwendbar. Die funktionale Entsprechung sind die Microsoft 365 Unified Audit Logs und Microsoft Purview — sie protokollieren Dateioperationen auf Benutzerebene (Zugriff, Download, Sharing-Änderungen). Diese Logs lassen sich per Wazuh-Integration in dasselbe SIEM-Backend fließen, sodass On-Premises-FIM-Alerts und Cloud-Audit-Events in einem einzigen Kontext korreliert werden können.

Typische Fehlkonfigurationen

Zu breite Überwachung ohne Tuning: Alle Pfade auf Real-time mit Who-data — und dann nie Ausschlüsse definiert. Ergebnis: Alert-Fatigue nach 48 Stunden, Team schaltet Benachrichtigungen stumm. Lösung: Staged Rollout und Baseline-Phase einhalten.

Erkennung ohne Response-Workflow: FIM erzeugt Alerts, aber es gibt kein definiertes Routing zu einem Ticketing-System oder einen On-Call-Kanal. Alerts verschwinden ungesehen im SIEM-Dashboard. Lösung: FIM-Alerts der Severity 10+ (Wazuh-Standard für kritische FIM-Events) direkt in einen definierten Eskalationsweg leiten.

Lücken in der Angriffsfläche: Nur /etc überwacht, aber die Webanwendung liegt unter /opt/app/. Webshells im App-Verzeichnis bleiben unsichtbar. Lösung: Attack-Surface-Mapping vor der Konfiguration — wo laufen Webserver, wo liegen ausführbare Dateien, wo liegen Konfigurationen mit Credentials?

FIM überwacht sich nicht selbst: Ein Angreifer mit Root-Zugriff kann die ossec.conf modifizieren und bestimmte Pfade aus der Überwachung entfernen — Anti-Forensik 101. Lösung: /var/ossec/etc/ossec.conf und /var/ossec/etc/rules/ in die FIM-Konfiguration aufnehmen.

Fazit

Datei-Integritätsmonitoring ist eine der wenigen Sicherheitsmaßnahmen, die gleichzeitig regulatorische Anforderungen (NIS-2, DSGVO, BSI-Grundschutz) erfüllt und unmittelbaren operativen Mehrwert für die Angriffserkennung liefert. Wazuh macht FIM zugänglich — auch ohne großes Security-Budget oder internes Spezialisten-Team.

Der entscheidende Faktor ist nicht die Einrichtung, sondern der laufende Betrieb: eine saubere Baseline, konsequentes Alert-Tuning und ein definierter Response-Workflow machen den Unterschied zwischen einem FIM-System, das Angriffe sichtbar macht, und einem, das im Rauschen untergeht.

Wenn Sie FIM als Teil eines umfassenderen SIEM-Setups betreiben möchten — inklusive Korrelation mit EDR-Daten, Cloud-Logs und Threat Intelligence — bietet Vyrex Security einen Managed SIEM/SOC-Service auf Basis von Wazuh an, der speziell für KMU ohne dediziertes Security-Team konzipiert ist. FIM-Konfiguration, laufendes Tuning und Alert-Triage übernimmt unser Analysten-Team: Sie erhalten ausschließlich die Alerts, die tatsächlich handlungsrelevant sind.