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