· Sascha Enke
Dateiintegrität, Härtungsprüfung, Schwachstellen: Was die drei Wazuh-Prüfungen leisten
Wer sich Wazuh ansieht, stößt auf drei Abkürzungen: FIM, SCA und Vulnerability Detection. Alle drei laufen auf demselben Agent und landen im selben Dashboard, beantworten aber unterschiedliche Fragen. Hier erklären wir, was jede Prüfung tut, wie wir sie eingestellt haben und wie man mit den Befunden umgeht. Wie wir Wazuh aufgebaut und die Agents verteilt haben, steht im Beitrag Wazuh mit Ansible ausrollen.
Schwachstellenerkennung: Welche bekannten Lücken hat dieses System?
Wie es funktioniert: Der Agent liest stündlich das Systeminventar aus: Betriebssystem, installierte Pakete, offene Ports. Der Manager vergleicht die Paketversionen mit Datenbanken bekannter Sicherheitslücken (CVEs) und aktualisiert diese Daten stündlich. Das Ergebnis ist eine Liste je System: welches Paket, welche Lücke, wie schwer, ob es schon ein Update gibt.
Was man mit der Liste macht: Der erste Lauf über eine Umgebung, die vorher niemand systematisch geprüft hat, liefert fast immer eine lange Liste. Davon sollte man sich nicht lähmen lassen. Drei Regeln helfen:
- Viele Funde, wenige Ursachen. Ein veralteter Kernel bringt Dutzende CVEs auf einmal mit. Wer nach Paket statt nach CVE sortiert, sieht schnell, dass ein Update einen großen Teil der Liste erledigt.
- Zuerst die Funde, für die es ein Update gibt. Damit fängt die Arbeit an. Funde ohne verfügbares Update brauchen eine Bewertung, keine Hektik.
- Installiert ist nicht aktiv. Ein neuer Kernel schützt erst nach dem Neustart. Ohne automatische Updates fehlt oft auch der Hinweis, dass ein Neustart nötig ist. Ein Patch-Ablauf sollte deshalb ausdrücklich prüfen, ob der laufende Kernel der neueste installierte ist.
Danach gehört das Aktualisieren in ein festes Wartungsfenster, am besten über eine Pipeline, die nach dem Update prüft, ob alle Dienste wieder laufen. Dringende Lücken werden außer der Reihe geschlossen, mit ausdrücklicher Freigabe.
Grenzen: Wazuh sieht nur, was der Paketmanager kennt. Selbst kompilierte Software, Programme in Containern oder Geräte ohne Agent, etwa Switches und Drucker, fehlen in dieser Liste. Die Schwachstellenerkennung ersetzt auch keinen Penetrationstest: Sie sagt, welche Lücken in den installierten Versionen bekannt sind, nicht, ob jemand sie bei Ihnen ausnutzen kann.
Härtungsprüfung (SCA): Ist das System so eingestellt, wie es sein sollte?
Wie es funktioniert: Security Configuration Assessment prüft die Konfiguration gegen Richtlinien, die sich an den CIS-Benchmarks orientieren. Beispiele: Ist die Anmeldung als root per SSH erlaubt? Sind unnötige Dienste aktiv? Haben wichtige Dateien die richtigen Berechtigungen? Wazuh wählt die Richtlinie passend zum Betriebssystem und zeigt je System, wie viele Prüfungen bestanden sind und welche nicht, jeweils mit Begründung und Hinweis zur Behebung. Bei uns läuft die Prüfung alle zwölf Stunden.
Was man daraus macht: Nicht jede fehlgeschlagene Prüfung ist ein Fehler. Manche Empfehlungen passen nicht zur Rolle eines Servers, etwa wenn ein Hypervisor bestimmte Netzwerkeinstellungen braucht. Wichtig ist, dass jede Abweichung entweder behoben oder begründet wird. Die Begründung gehört dokumentiert, sonst steht dieselbe Frage beim nächsten Audit wieder im Raum.
Der eigentliche Nutzen liegt im Verlauf. Ein System, das bei der Einrichtung sauber gehärtet war, driftet mit der Zeit: Jemand öffnet einen Port zum Testen und vergisst ihn, ein Paket bringt einen zusätzlichen Dienst mit. Die Härtungsprüfung zeigt das, statt dass es beim nächsten Audit auffällt.
Grenzen: Ein bestandener Check ist kein Compliance-Nachweis für sich. Er zeigt, dass eine Einstellung zum Zeitpunkt der Prüfung stimmte, nicht, dass dahinter ein Prozess steht. Für die TISAX-Vorbereitung ist er ein guter Beleg, aber eben einer von mehreren.
Dateiintegrität (FIM): Hat sich an kritischen Dateien etwas geändert?
Wie es funktioniert: File Integrity Monitoring merkt sich Prüfsummen, Berechtigungen und Besitzer ausgewählter Dateien und meldet jede Änderung, auch neu hinzugekommene Dateien. Bei Textdateien zeigt Wazuh auf Wunsch, welche Zeilen sich geändert haben. Wir haben mit der Standardauswahl begonnen: Systemkonfiguration unter /etc, die Programmverzeichnisse und /boot. Logdateien sind ausgenommen, und bei privaten Schlüsseln wird nur die Änderung gemeldet, nie der Inhalt. Die Prüfung läuft alle zwölf Stunden.
Was man daraus macht: Eine geänderte Datei unter /etc ist meistens harmlos: ein Update, eine geplante Konfigurationsänderung. Hier hilft es, wenn Änderungen ohnehin über Infrastructure as Code laufen. Dann lässt sich jede Meldung einem Merge Request oder einem Update-Lauf zuordnen, und was sich keinem zuordnen lässt, ist genau der Fall, den man sehen will.
Grenzen: FIM ist nur so gut wie die Auswahl der Pfade. Wer zu viel überwacht, bekommt vor allem Meldungen über Dateien, die sich ständig ändern, und hört irgendwann auf hinzusehen. Wer zu wenig überwacht, übersieht die eine Änderung, die zählt. Die Auswahl gehört deshalb zur Einrichtung je Serverrolle und wird nachgeschärft, wenn die ersten Wochen zeigen, was nur Rauschen ist. Außerdem merkt eine Prüfung alle zwölf Stunden eine Änderung erst beim nächsten Lauf. Für Verzeichnisse, bei denen es auf Minuten ankommt, gibt es eine Echtzeitüberwachung, die aber mehr Last erzeugt.
Zusammengefasst
| Prüfung | Frage | Intervall bei uns | Größte Grenze |
|---|---|---|---|
| Schwachstellenerkennung | Welche bekannten Lücken haben die installierten Pakete? | Inventar stündlich, Lückendaten stündlich | sieht nur, was der Paketmanager kennt |
| Härtungsprüfung (SCA) | Weicht die Konfiguration von der Richtlinie ab? | alle 12 Stunden | Momentaufnahme, kein Prozessnachweis |
| Dateiintegrität (FIM) | Hat sich an kritischen Dateien etwas geändert? | alle 12 Stunden | nur so gut wie die Auswahl der Pfade |
Keine der drei Prüfungen macht ein System sicher. Sie zeigen, wo man hinsehen muss. Was danach passiert, wer den Befund bekommt, bis wann er behoben wird und wer eine Ausnahme freigibt, ist die eigentliche Arbeit.
Wenn Sie wissen wollen, was diese drei Prüfungen auf Ihren Servern finden würden: Unter Wazuh Security Monitoring beschreiben wir, wie wir Wazuh aufbauen und betreiben.

Geschrieben von Sascha Enke, Gründer & Geschäftsführer von Enke-iTS – über 20 Jahre Erfahrung in Infrastruktur-Architektur und Virtualisierung. Mehr über uns
