Offline Vulnerability Detection in Wazuh – Ein Praxisfall aus der Community

Aus maxTechCorner

In einem aktuellen Slack-Thread schilderte ein Anwender ein Problem, das viele Administratoren kennen: Wazuh für Umgebungen ohne Internetzugang (Air-Gapped / Restricted Networks) korrekt zu konfigurieren, insbesondere die Offline-Vulnerability-Detection. Der Dialog entwickelte sich schnell zu einem hilfreichen Troubleshooting-Leitfaden – mit einigen wichtigen Learnings, die wir hier als Blogpost zusammenfassen.

1. Ausgangslage: Wazuh im Offline-Betrieb

Der Nutzer wollte die Wazuh-Vulnerability-Detection in einer Offline-Umgebung nutzen. Dazu muss ein aktueller CVEs-Snapshot von der Wazuh-CTI-API heruntergeladen und im Wazuh-Manager eingebunden werden.

Dafür nutzte er: 

curl -s -X GET https://cti.wazuh.com/api/v1/catalog/contexts/vd_1.0.0/consumers/vd_4.8.0 \
| jq -r '.data | "\(.last_snapshot_link)\n\(.last_snapshot_at)"'

Damit wird der richtige Snapshot-Link für die Version vd_4.8.0 ausgelesen – und laut Wazuh-Support ist das auch korrekt.

Nach dem Herunterladen wurde die Datei bereitgestellt: 

chmod 750 /opt/cve/cves.zip
chown root:wazuh /opt/cve/cves.zip

Und anschließend in der Wazuh-Konfiguration aktiviert: 

<vulnerability-detection>
   <enabled>yes</enabled>
   <index-status>yes</index-status>
   <feed-update-interval>60m</feed-update-interval>
   <offline-url>file:///opt/cve/cves.zip</offline-url>
</vulnerability-detection>

Trotz korrekter Schritte funktionierte das Vulnerability-Modul jedoch nicht.

2. Die Fehlermeldung – und warum sie verwirrend ist

Der Nutzer erhielt wiederkehrend folgende Log-Ausgabe: 

ERROR: Action for 'vulnerability_feed_manager' failed:
Error -1 from server: Invalid CTI metadata format - Response body:
Internal error in HTTPRequest module.

Hinzu kamen Warnungen über nicht ladbare IOC-Listen – jedoch nicht direkt relevant für die Offline-VD.

Der entscheidende Hinweis: Wazuh versuchte weiterhin, Metadaten online abzurufen, obwohl eine Offline-Quelle definiert war.

3. Die entscheidende Ursache: Pfadsyntax & Dateibesitz

Wazuh-Engineer Jakub Pacowski identifizierte schnell die häufigste Fehlerquelle:

Der Pfad zu offline-url muss exakt folgendermaßen aussehen:

file:///opt/cve/cves.zip

Die Datei muss für den Benutzer wazuh lesbar sein.

Auch wenn sie im Besitz von root:wazuh ist, kann ein zu restriktives Recht (z. B. 750) verhindern, dass Wazuh intern darauf zugreift.

Empfohlen wurde: 

chown wazuh:wazuh /opt/cve/cves.zip
chmod 755 /opt/cve/cves.zip

Erst nach erneuter Zuweisung der Rechte und einem Restart: 

systemctl restart wazuh-manager

begann das Modul korrekt zu arbeiten.

4. Warum keine Events erscheinen – ein wichtiges Detail

Nachdem die Offline-VD lief, bemerkte der Nutzer, dass keine Vulnerability-Events angezeigt werden.

Auch hierfür lieferte Jakub die Antwort:

Events werden nur erzeugt, wenn neue Schwachstellen erkannt werden. Beim allerersten Scan gibt es keine Events, da keine Veränderungen existieren.

Das bedeutet:

Dashboard und Inventories sollten Daten anzeigen

Events erscheinen erst bei:

  • neuen Softwares
  • neu entdeckten CVEs
  • Systemänderungen nach dem initialen Import

Außerdem: der Syscollector-Scan läuft nur 1× pro Stunde

→ erste Ergebnisse können verzögert erscheinen.

5. Empfehlungen der Wazuh-Engineers

Zusätzlich gab es hilfreiche Best-Practices:

1. Möglichst Online-Updates nutzen oder CTI-Zugriff whitelisten

Offline-Statistiken veralten schnell und erfordern manuelles Nachladen der CVE-Datenbank.

2. Permissions genau prüfen

Viele Wazuh-Probleme beruhen auf Dateirechten.

3. Bei Testsystemen mit echt verwundbarer Software testen

Nur so lassen sich Events sicher auslösen.

6. Fazit

Der Slack-Thread zeigt exemplarisch, wie komplex die Offline-Konfiguration der Wazuh-Vulnerability-Detection sein kann. Häufige Stolpersteine sind:

  • falsche offline-url-Syntax
  • fehlerhafte Dateirechte
  • Missverständnisse bezüglich der Event-Generierung

Durch systematisches Troubleshooting lässt sich das Modul jedoch zuverlässig zum Laufen bringen – und bietet dann auch in isolierten Umgebungen eine solide Schwachstellenanalyse.

https://wazuh.slack.com/archives/C0A933R8E/p1764105734238869

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 27. November 2025).

Unterstützung von m.a.x. it

Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Offline_Vulnerability_Detection_in_Wazuh_–_Ein_Praxisfall_aus_der_Community&oldid=3004“