Wazuh Vulnerability Detection automatisch aktualisieren: CTI-Zugriff, Offline-Feeds und Update-Kontrolle

Einleitung

Die Qualität einer Schwachstellenerkennung hängt unmittelbar von der Aktualität ihrer Vulnerability-Informationen ab. Selbst wenn Wazuh die installierten Betriebssysteme, Pakete und Anwendungen korrekt inventarisiert, können neue CVEs erst erkannt werden, wenn dem Wazuh Manager ein aktueller Vulnerability-Feed zur Verfügung steht.

In abgeschotteten oder stark reglementierten Umgebungen entstehen dabei häufig Missverständnisse zwischen eingeschränktem Internetzugriff und einem vollständig offline betriebenen System. Darf der Wazuh Manager cti.wazuh.com über HTTPS erreichen, kann er den offiziellen Wazuh-CTI-Feed selbstständig aktualisieren. Ein manuell heruntergeladener Offline-Snapshot ist in diesem Fall normalerweise nicht erforderlich.

Bei vollständig isolierten Systemen ist dagegen weiterhin ein interner Transfer- oder Mirror-Prozess notwendig. Wazuh kann den bereitgestellten Snapshot anschließend automatisch einlesen, aber nicht selbstständig eine physisch oder logisch getrennte Netzwerkgrenze überwinden.

Ausgangslage / Problemstellung

Ein Wazuh Server hatte zunächst keinen Zugriff auf das Internet. Für die Vulnerability Detection wurden deshalb CTI-Snapshots manuell heruntergeladen und als Offline-Repository bereitgestellt.

Später wurde ausgehend vom Wazuh Server der Zugriff auf cti.wazuh.com erlaubt. Damit stellte sich die Frage, ob die bisherigen manuellen Updates weiterhin notwendig sind und wie sich zuverlässig überprüfen lässt, ob Wazuh den Vulnerability-Feed nun automatisch aktualisiert.

Die Umgebung weist damit folgende Merkmale auf:

Der Wazuh Manager betreibt das Vulnerability-Detection-Modul.
Der Server verfügt über keinen allgemeinen Internetzugriff.
Ausgehende HTTPS-Verbindungen zu cti.wazuh.com wurden gezielt freigeschaltet.
Zuvor wurde möglicherweise <offline-url> in der ossec.conf verwendet.
Die automatische Aktualisierung soll ohne manuelles Kopieren von CTI-Snapshots erfolgen.
Der erfolgreiche Download und die Verarbeitung des Feeds müssen nachvollziehbar sein.

Entscheidend ist, ob der Wazuh Manager das CTI-System direkt erreichen kann. Ist dies der Fall, sollte der reguläre Online-Modus verwendet werden. Ist keine direkte Verbindung möglich, bleibt der Offline-Modus erforderlich.

Technische Analyse

Die Wazuh Vulnerability Detection basiert auf mehreren voneinander abhängigen Komponenten.

Der Syscollector auf den überwachten Endpoints erfasst unter anderem Betriebssysteminformationen, installierte Pakete, Anwendungen und – abhängig vom Betriebssystem – Hotfixes. Diese Inventardaten werden an den Wazuh Manager übertragen. Dort korreliert das Vulnerability-Detection-Modul die Softwarebestände mit den Schwachstelleninformationen aus der Wazuh Cyber Threat Intelligence Platform. Die Ergebnisse werden anschließend über den Indexer Connector in den Wazuh Indexer geschrieben und im Dashboard dargestellt.

Dabei müssen zwei unterschiedliche Aktualisierungszyklen berücksichtigt werden:

Feed-Aktualisierung: Der Wazuh Manager lädt neue Vulnerability-Informationen aus der CTI-Quelle.
Inventar-Aktualisierung: Der Syscollector übermittelt neue oder geänderte Softwareinformationen der Agents.

Ein aktueller Feed allein reicht daher nicht aus, wenn die Paketinformationen eines Agents veraltet sind. Umgekehrt können aktuelle Inventardaten keine neu veröffentlichten CVEs erkennen, solange der CTI-Feed nicht aktualisiert wurde.

Direkter CTI-Zugriff

Kann der Wazuh Manager https://cti.wazuh.com erreichen, verwendet das Vulnerability-Detection-Modul den regulären Online-Aktualisierungsmechanismus. Das Intervall wird mit <feed-update-interval> gesteuert.

Die Wazuh-Standardkonfiguration lautet:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

60m ist sowohl der Standardwert als auch das dokumentierte minimale Aktualisierungsintervall. Unterstützt werden positive Zeitangaben mit Suffixen wie m, h oder d.

In dieser Betriebsart darf kein nicht mehr benötigter <offline-url>-Eintrag aktiv bleiben. Solange dieser Parameter gesetzt ist, ist das Modul auf die dort angegebene Datei oder URL als Content-Quelle konfiguriert.

Offline-Betrieb

Der Offline-Modus ist für Systeme vorgesehen, die den Wazuh-CTI-Dienst nicht direkt erreichen können. Dazu wird ein vollständiger Snapshot des Vulnerability-Repositories heruntergeladen und lokal oder über einen internen Webserver bereitgestellt.

Wazuh unterstützt für <offline-url> sowohl lokale Dateien als auch HTTP- beziehungsweise HTTPS-Adressen:

<offline-url>file:///opt/wazuh-cti/cves.zip</offline-url>

oder:

<offline-url>https://cti-mirror.intern.example/wazuh/cves.zip</offline-url>

Unterstützt werden unter anderem ZIP-, XZ- und GZIP-Dateien sowie unkomprimierte JSON-Inhalte.

Wichtig ist die Abgrenzung: Wazuh kann eine bereits intern bereitgestellte Offline-Datei regelmäßig einlesen. Das Herunterladen des Snapshots aus dem Internet und der Transport in ein vollständig isoliertes Netz müssen jedoch durch einen separaten Prozess erfolgen.

Warum ein HTTP-Status 200 nicht als alleiniger Nachweis genügt

Ein Test wie:

curl -I https://cti.wazuh.com/api/v1/catalog/contexts/vd_1.0.0/consumers/vd_4.8.0

prüft, ob DNS-Auflösung, TCP-Verbindung, TLS-Aufbau und HTTP-Kommunikation grundsätzlich funktionieren. Eine Antwort mit Status 200 bestätigt damit die Erreichbarkeit des API-Endpunkts.

Sie beweist jedoch noch nicht, dass:

der Wazuh-Prozess dieselbe Netzwerkverbindung verwenden kann,
der Feed vollständig heruntergeladen wurde,
der heruntergeladene Content verarbeitet werden konnte,
die lokale Feed-Datenbank aktualisiert wurde,
anschließend ein erneuter Vulnerability-Abgleich erfolgte.

Für eine belastbare Prüfung müssen deshalb Netzwerk, Konfiguration, Logs und lokale Content-Daten gemeinsam betrachtet werden.

Versionsabhängige Feed-Verzeichnisse

Die internen Speicherstrukturen der Vulnerability Detection haben sich innerhalb der Wazuh-4.x-Versionen verändert. Neuere Versionen verwenden unter anderem RocksDB-basierte Datenbanken anstelle älterer SQLite-Dateien.

Je nach Wazuh-Version können relevante Daten beispielsweise unter folgenden Verzeichnissen liegen:

/var/ossec/queue/vd/
/var/ossec/queue/vd/feed/
/var/ossec/queue/vd_updater/

Dateizeitstempel sind daher ein hilfreicher sekundärer Indikator, sollten aber nicht als versionsübergreifend stabile Monitoring-Schnittstelle behandelt werden. Die aussagekräftigste Kontrolle liefern die Meldungen des Vulnerability Scanners und Content Updaters im Wazuh-Log.

Lösung / Best Practices

1. Bestehende Konfiguration sichern

Vor Änderungen sollte die Manager-Konfiguration gesichert werden:

cp -a /var/ossec/etc/ossec.conf \
  /var/ossec/etc/ossec.conf.$(date +%F-%H%M%S).bak

Anschließend wird geprüft, ob bereits eine Offline-Quelle konfiguriert ist:

grep -n -A10 -B2 "<vulnerability-detection>" \
  /var/ossec/etc/ossec.conf

Alternativ kann gezielt nach dem Parameter gesucht werden:

grep -n "<offline-url>" /var/ossec/etc/ossec.conf

2. CTI-Konnektivität vollständig testen

Ein einfacher Header-Test liefert einen ersten Hinweis:

curl -I \
  https://cti.wazuh.com/api/v1/catalog/contexts/vd_1.0.0/consumers/vd_4.8.0

Aussagekräftiger ist eine tatsächliche API-Abfrage:

curl -fsS \
  https://cti.wazuh.com/api/v1/catalog/contexts/vd_1.0.0/consumers/vd_4.8.0 \
  | jq .

Nur Download-Link und Veröffentlichungszeitpunkt des aktuellen Snapshots lassen sich folgendermaßen ausgeben:

curl -fsS \
  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)"'

Diese Abfrage entspricht dem von Wazuh dokumentierten Verfahren zum Ermitteln des aktuellen CTI-Snapshots.

Der Consumer-Pfad sollte nicht ohne Prüfung auf andere Wazuh-Versionen übertragen werden. Maßgeblich ist die Dokumentation der tatsächlich installierten Wazuh-Version.

3. Online-Aktualisierung konfigurieren

Wenn die CTI-Abfrage erfolgreich ist, wird ein vorhandener <offline-url>-Eintrag entfernt. Der Konfigurationsblock sollte anschließend beispielsweise so aussehen:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>

Die Bedeutung der Parameter:

<enabled>yes</enabled> aktiviert die Vulnerability Detection.
<index-status>yes</index-status> aktiviert die Übertragung des Vulnerability-Inventars an den Wazuh Indexer.
<feed-update-interval>60m</feed-update-interval> veranlasst die regelmäßige Prüfung auf neue CTI-Inhalte.

Ein kürzeres Intervall als 60m sollte nicht konfiguriert werden, da 60m das dokumentierte Minimum ist.

4. Konfiguration vor dem Neustart validieren

Da die Vulnerability Detection durch wazuh-modulesd verwaltet wird, kann der zugehörige Konfigurationsbereich vor dem Neustart geprüft werden:

/var/ossec/bin/wazuh-modulesd -t

Der Befehl ist die von Wazuh vorgesehene Syntaxprüfung für Module beziehungsweise Wodles.

Erst nach erfolgreicher Validierung sollte der Manager neu gestartet werden:

systemctl restart wazuh-manager

Der Dienststatus lässt sich anschließend kontrollieren:

systemctl --no-pager --full status wazuh-manager

5. Feed-Aktualisierung im Log überwachen

Für Wazuh 4.x befindet sich das zentrale Manager-Log üblicherweise unter:

/var/ossec/logs/ossec.log

Eine allgemeine Suche nach relevanten Meldungen:

grep -Ei \
  "vulnerability-scanner|content-updater|feed update|content update" \
  /var/ossec/logs/ossec.log

Für eine laufende Beobachtung:

tail -F /var/ossec/logs/ossec.log \
  | grep --line-buffered -Ei \
    "vulnerability-scanner|content-updater|feed update|content update"

Bei einer erfolgreichen Aktualisierung sind abhängig von der installierten Version Meldungen zu erwarten, die sinngemäß folgende Phasen anzeigen:

Initiating update feed process
Feed update process completed
Triggered a re-scan after content update

Diese Abfolge ist besonders aussagekräftig:

Der Update-Prozess wurde gestartet.
Der neue Content wurde verarbeitet.
Nach dem Content-Update wurde ein erneuter Vulnerability-Abgleich ausgelöst.

Die reine Startmeldung reicht nicht aus. Entscheidend ist eine Abschlussmeldung ohne nachfolgende Fehler. Entsprechende Meldungen werden auch im offiziellen Wazuh-Repository zur Diagnose von Feed-Updates beschrieben.

Fehlermeldungen lassen sich zusätzlich isolieren:

grep -Ei \
  "vulnerability-scanner|content-updater" \
  /var/ossec/logs/ossec.log \
  | grep -Ei "error|warning|failed|unable|timeout"

6. Lokale Content-Daten kontrollieren

Abhängig von der Wazuh-Version können folgende Verzeichnisse geprüft werden:

ls -lah --time-style=long-iso \
  /var/ossec/queue/vd/ \
  /var/ossec/queue/vd/feed/ \
  /var/ossec/queue/vd_updater/ \
  2>/dev/null

Eine flexiblere Suche nach versionsabhängigen Verzeichnissen:

find /var/ossec/queue \
  -maxdepth 2 \
  -type d \
  \( -name "vd" -o -name "vd_updater" -o -name "feed" \) \
  -print

Aktuelle Änderungszeiten zeigen, dass Dateien oder Datenbanken aktualisiert wurden. Sie sollten jedoch immer gemeinsam mit den Logmeldungen bewertet werden.

Das manuelle Löschen dieser Verzeichnisse ist keine reguläre Update-Maßnahme. Dabei können lokale Datenbanken beschädigt oder vollständige Neuimporte und umfangreiche Rescans ausgelöst werden.

7. Debug-Logging nur zur Fehleranalyse aktivieren

Falls im normalen Log keine ausreichenden Informationen erscheinen, kann das Debug-Level der Wazuh-Module vorübergehend erhöht werden.

In /var/ossec/etc/local_internal_options.conf:

wazuh_modules.debug=2

Danach:

systemctl restart wazuh-manager

Das erweiterte Logging kann unter anderem Download-, Offset-, Extraktions- und Verarbeitungsschritte sichtbar machen. Aufgrund des deutlich höheren Logvolumens sollte die Einstellung nach Abschluss der Analyse wieder entfernt oder auf den vorherigen Wert zurückgesetzt werden. Die Verwendung von local_internal_options.conf verhindert außerdem, dass lokale Anpassungen bei einem Upgrade durch die Standarddatei überschrieben werden.

8. Firewall und Proxy korrekt konfigurieren

Eine Domain-Freigabe muss mindestens folgende Voraussetzungen erfüllen:

ausgehendes TCP auf Port 443,
funktionierende DNS-Auflösung,
TLS-Verbindungen zu cti.wazuh.com,
Zugriff auf die unter cti.wazuh.com/store/ bereitgestellten Snapshot-Dateien,
korrekte Systemzeit für die Zertifikatsvalidierung.

IP-basierte Freigaben sind problematisch, da vorgelagerte Cloud- und CDN-Adressen wechseln können. Eine DNS- beziehungsweise SNI-basierte Freigabe ist in der Regel robuster.

Bei TLS-Inspection muss sichergestellt sein, dass der Wazuh-Server der internen Zertifizierungsstelle vertraut. Die Option curl -k sollte ausschließlich zu Diagnosezwecken eingesetzt werden, nicht als dauerhafte Lösung.

9. Vollständig isolierte Umgebung automatisieren

Kann der Wazuh Manager cti.wazuh.com nicht erreichen, lässt sich der Offline-Prozess mit einem internen Mirror automatisieren.

Ein System mit Internetzugriff ruft regelmäßig die aktuelle Snapshot-URL ab:

#!/usr/bin/env bash
set -euo pipefail

API_URL="https://cti.wazuh.com/api/v1/catalog/contexts/vd_1.0.0/consumers/vd_4.8.0"
TARGET_DIR="/srv/www/wazuh-cti"
TARGET_FILE="${TARGET_DIR}/cves.zip"

mkdir -p "${TARGET_DIR}"

SNAPSHOT_URL="$(
  curl -fsS "${API_URL}" \
    | jq -er '.data.last_snapshot_link'
)"

TMP_FILE="$(mktemp "${TARGET_DIR}/cves.zip.XXXXXX")"
trap 'rm -f "${TMP_FILE}"' EXIT

curl -fsS "${SNAPSHOT_URL}" -o "${TMP_FILE}"
unzip -t "${TMP_FILE}" >/dev/null

chmod 0644 "${TMP_FILE}"
mv -f "${TMP_FILE}" "${TARGET_FILE}"

trap - EXIT

Der Mirror kann anschließend über einen internen HTTPS-Webserver bereitgestellt werden. Auf dem Wazuh Manager wird folgende Quelle konfiguriert:

<vulnerability-detection>
  <enabled>yes</enabled>
  <index-status>yes</index-status>
  <feed-update-interval>60m</feed-update-interval>
  <offline-url>https://cti-mirror.intern.example/wazuh-cti/cves.zip</offline-url>
</vulnerability-detection>

Wazuh prüft die konfigurierte Quelle gemäß dem Feed-Intervall. Der vorgeschaltete Mirror-Prozess ist dafür verantwortlich, die Datei regelmäßig und atomar zu ersetzen.

Bei Verwendung einer lokalen Datei kann die Konfiguration beispielsweise so aussehen:

<offline-url>file:///opt/wazuh-cti/cves.zip</offline-url>

Die dokumentierten Berechtigungen für eine lokale Snapshot-Datei lauten:

chmod 750 /opt/wazuh-cti/cves.zip
chown root:wazuh /opt/wazuh-cti/cves.zip

Nach Änderungen an <offline-url> muss der Wazuh Manager neu gestartet werden.

Lessons Learned / Best Practices

Online- und Offline-Modus klar trennen: Sobald der Wazuh Manager den CTI-Dienst direkt erreichen kann, sollte der nicht mehr benötigte <offline-url>-Eintrag entfernt werden. Eine Mischkonfiguration erschwert die Fehlersuche und kann dazu führen, dass weiterhin ein veralteter Snapshot verwendet wird.

Erfolg mehrstufig prüfen: Ein HTTP-Status 200 bestätigt nur die Erreichbarkeit. Für einen vollständigen Nachweis müssen auch die Feed-Verarbeitung, die Abschlussmeldung im Log und der anschließende Rescan überprüft werden.

Feed- und Inventarintervall nicht verwechseln: <feed-update-interval> aktualisiert die Schwachstelleninformationen. Das Syscollector-Intervall bestimmt, wann neue Software- und Paketinformationen der Agents verfügbar werden. Die tatsächliche Erkennungsverzögerung ergibt sich aus beiden Zyklen.

Interne Verzeichnisse nicht als stabile API behandeln: Pfade und Datenbankformate können sich zwischen Wazuh-Versionen ändern. Monitoring sollte primär auf dokumentierten Konfigurationen, Logs und den Ergebnissen im Wazuh Indexer basieren.

Keine IP-Adressen des CTI-Dienstes fest verdrahten: Bei Cloud- und CDN-basierten Diensten können sich Zieladressen ändern. Domain- und SNI-basierte Firewall-Regeln sind wartungsärmer.

Offline-Dateien atomar austauschen: Ein Downloader sollte neue Snapshots zunächst in eine temporäre Datei schreiben, validieren und danach per mv ersetzen. Dadurch verhindert man, dass Wazuh eine nur teilweise heruntergeladene Datei einliest.

Debug-Logging zeitlich begrenzen: Ein erhöhtes Debug-Level ist wertvoll für die Ursachenanalyse, kann aber erhebliches Logvolumen erzeugen und sollte nicht dauerhaft aktiv bleiben.

Update-Überwachung operationalisieren: In produktiven Umgebungen sollte ein Monitoring erkennen, wenn über mehrere Feed-Intervalle keine erfolgreiche Abschlussmeldung erscheint. Ein erreichbarer CTI-Endpunkt garantiert nicht, dass spätere Downloads und Verarbeitungen dauerhaft funktionieren.

Fazit

Ein Wazuh Server mit gezieltem Zugriff auf cti.wazuh.com benötigt normalerweise keinen manuell gepflegten Offline-Snapshot. Nach dem Entfernen von <offline-url> übernimmt das Vulnerability-Detection-Modul die regelmäßige Aktualisierung anhand von <feed-update-interval>.

Die verlässlichste Erfolgskontrolle kombiniert eine reale CTI-API-Abfrage, eine validierte Manager-Konfiguration, erfolgreiche Update- und Abschlussmeldungen im Wazuh-Log sowie eine anschließende Aktualisierung der lokalen Feed-Daten.

Für vollständig isolierte Umgebungen bleibt ein externer Transferprozess notwendig. Dieser lässt sich jedoch durch einen automatisierten Download-Host und einen internen HTTP- oder HTTPS-Mirror so gestalten, dass der Wazuh Manager den Offline-Feed anschließend ohne manuelle Eingriffe regelmäßig übernimmt.