Wazuh Vulnerability Detection aktualisiert CVEs nicht: Syscollector-Inventar, DB-Sync und Module-Reset sauber beheben

von

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

Vulnerability Detection ist in Wazuh nur so gut wie die zugrunde liegenden Datenflüsse: Software-Inventar vom Agent (Syscollector), Korrelationslogik im Manager (Vulnerability Detection / vulnerability-scanner), Persistenz im Wazuh-DB-Subsystem sowie die Ablage/Abfrage im Indexer. Wenn ein Server gepatcht wurde, CVEs aber „eine Woche später immer noch“ im Dashboard stehen, ist das fast nie „nur ein UI-Cache“, sondern ein echtes Konsistenzproblem zwischen Inventar, Scan-Orchestrierung und Indexzustand – oder schlicht ein Hinweis darauf, dass das betroffene Paket (oder der aktive Kernel) weiterhin verwundbar ist.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Typische Symptome aus der Praxis:

  • Nach Paket-Updates bleiben zahlreiche CVEs im Vulnerability Dashboard bestehen, Inventar wirkt „statisch“.
  • Syscollector läuft augenscheinlich regelmäßig, dennoch verschwinden Findings nicht.
  • Manager-Logs zeigen Debug-Hinweise wie „DB query not synced“ während Rescan-/Agent-Listen-Abfragen.
  • Indexer ist erreichbar (Cluster Health ggf. yellow, aber grundsätzlich OK).
  • Beispiel-Finding: Linux-Kernel-Paket auf Ubuntu 18.04 (Bionic) wird als verwundbar geführt (z. B. linux-image-4.15.0-204-generic), obwohl „der Server letzte Woche aktualisiert“ wurde.

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) Wazuh korreliert CVEs gegen das Inventar, nicht gegen „Update-Status“

Wazuh Vulnerability Detection gleicht den von Syscollector gemeldeten Paketstand mit Vulnerability-Intel (CTI/Repository) ab und schreibt daraus ein Vulnerability-Inventar in den Indexer. Wenn das Inventar ein altes Paket zeigt, bleibt die CVE sichtbar – auch wenn auf dem Host bereits neuere Pakete installiert wurden, aber:

  • der Syscollector-Scan nicht sauber übertragen wurde,
  • der Manager die Agent-Daten nicht zuverlässig aus seiner DB lesen kann,
  • oder der Indexer-Status nicht konsistent aktualisiert wird.

2) Syscollector kann korrekt „laufen“ und trotzdem nicht das liefern, was erwartet wird

Der Standard-Scanintervall liegt typischerweise bei 1 Stunde.
Stolpersteine:

  • Syscollector sendet Inventar, aber Agent ↔ Manager Synchronisation stockt (Queue/Backpressure).
  • Das Inventar enthält weiterhin alte Kernel-/Paketversionen, weil alte Pakete noch installiert sind (Kernel-Images sind ein Klassiker).
  • Bei Kernel-Fixes gilt zusätzlich: Installiert ≠ aktiv. Solange nicht rebootet wurde, läuft evtl. weiterhin ein verwundbarer Kernel, und/oder alte Kernel-Images bleiben installiert und werden weiterhin inventarisiert.

3) „DB query not synced“: Wenn die Manager-DB zum Bottleneck wird

Die Meldungen wie „Error executing query… Reason: DB query not synced“ deuten darauf hin, dass die Abfragen an das DB-Subsystem (wazuh-db / interner State) nicht zuverlässig „hinterherkommen“. In großen Umgebungen (viele Agents, hohe Eventrate) kann das dazu führen, dass der Vulnerability-Scanner keine vollständige Agent-Liste/rescan-Planung durchführen kann und der Indexer-Connector anschließend Lösch-/Update-Operationen ohne Effekt ausführt (z. B. deleted: 0). Das Ergebnis: veraltete Einträge bleiben sichtbar.

4) „Gelb“ im Indexer ist nicht automatisch fatal – aber Signal für Hygiene-Probleme

Wazuh-Dokumentation weist explizit darauf hin, dass je nach Version green oder yellow zulässig sein kann. Entscheidend ist: keine Auth-/TLS-/Connectivity-Probleme zwischen Manager und Indexer, und keine dauerhaften Sync-Fehler.

5) Das unbequeme Detail: Das Paket kann wirklich noch verwundbar sein

Das Beispiel linux-image-4.15.0-204-generic auf Ubuntu 18.04 kann weiterhin CVE-treffend sein, wenn genau diese Version laut Distribution-Tracker nicht als gefixt markiert ist – oder wenn zwar ein Fix existiert, aber nicht installiert/aktiv ist. Gerade bei Ubuntu LTS und Kernel-Backports ist „OS aktualisiert“ keine Garantie, dass alle betroffenen Kernel-Images/Pakete auf einen nicht-verwundbaren Stand gebracht wurden.

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Die folgenden Schritte sind bewusst in einer Reihenfolge, die zuerst Datenqualität sicherstellt und erst dann „Reset“ als harte Maßnahme nutzt.

Schritt 1: Auf dem Endpoint verifizieren, was Wazuh wirklich inventarisiert

1) Syscollector-Lauf prüfen (Agent):

grep -iE "syscollector" /var/ossec/logs/ossec.log

2) Tatsächlich installierte Kernel-Images prüfen (Debian/Ubuntu):

dpkg -l | grep -E '^ii\s+linux-image'
uname -r

Best Practice:

  • Nach Kernel-Updates rebooten, damit der gefixte Kernel aktiv wird.
  • Alte Kernel-Images entfernen (mit Vorsicht und mindestens einen Fallback behalten):
sudo apt-get autoremove --purge

Wichtig: Wazuh meldet CVEs oft gegen installierte Pakete. Wenn alte Kernel-Images installiert bleiben, können CVEs im Inventar bestehen bleiben, obwohl das System „aktualisiert“ wirkt.

Schritt 2: Manager-seitig prüfen, ob Sync/Indexer-Anbindung sauber ist

1) Manager-Logs nach Sync-/Indexer-Problemen filtern:

grep -iE "sync|indexer-connector|error|warn" /var/ossec/logs/ossec.log

2) Indexer-Health prüfen:

  • GET _cluster/health (oder via curl). Bei neueren Versionen ist yellow in vielen Setups akzeptabel, aber dauerhafte Auth-/TLS-Fehler sind es nicht.

3) Wenn „DB query not synced“ wiederkehrt:
Das ist ein Last-/Backpressure-Indikator. Kurzfristig hilft ein Reset (siehe Schritt 4), mittelfristig müssen Kapazität und Queues betrachtet werden (siehe „Lessons Learned“).

Schritt 3: „Soft Refresh“ erzwingen, bevor man resetet

  • Agent/Manager-Service-Neustart kann einen scan_on_start-Inventarscan auslösen (wenn aktiv). Syscollector unterstützt „Scan beim Start“.
  • Ziel: ein frisches, konsistentes Inventar im Manager/Indexer, bevor Daten gelöscht werden.

Schritt 4: Harte Maßnahme – Vulnerability Detection Modul zurücksetzen (sauber und reproduzierbar)

Wenn die Datenpipeline „hängt“ oder veraltete Einträge nicht verschwinden, ist der dokumentierte Reset-Weg die zuverlässigste Methode, wieder in einen konsistenten Zustand zu kommen.

Ablauf pro Manager-Node (Wazuh-Dokumentation):

  1. Manager stoppen:
systemctl stop wazuh-manager
  1. Vulnerability Detection deaktivieren (ossec.conf):
<vulnerability-detection>
  <enabled>no</enabled>
  <!-- weitere Optionen -->
</vulnerability-detection>
  1. State-/Queue-Daten löschen (Vulnerability + Indexer-Queue):
rm -rf /var/ossec/queue/vd/inventory/
rm -rf /var/ossec/queue/vd/delayed/
rm -rf /var/ossec/queue/vd/event/
rm -rf /var/ossec/queue/indexer/
  1. Vulnerability State Indizes im Indexer löschen (Dev Tools):
DELETE wazuh-states-vulnerabilities-*
  1. Prüfen, dass der Index leer ist:
GET wazuh-states-vulnerabilities-*/_count
  1. Manager starten (damit „disabled“ Zustand sauber übernommen wird):
systemctl start wazuh-manager
  1. Modul wieder aktivieren (ossec.conf):
<vulnerability-detection>
  <enabled>yes</enabled>
  <!-- weitere Optionen -->
</vulnerability-detection>
  1. Manager neu starten, um Rescan anzustoßen:
systemctl restart wazuh-manager

Side-Effects / Erwartungsmanagement:

  • Das Vulnerability-Inventar wird neu aufgebaut; je nach Agent-Anzahl dauert das.
  • Während des Neuaufbaus können Ergebnisse zunächst „unvollständig“ wirken.
  • Wenn die Root-Cause (DB-Overload) nicht behoben wird, kann der Zustand wieder auftreten.

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

  1. Inventar-Hygiene ist Pflicht
  • Bei Kernel-CVEs: Reboot + Entfernen alter Kernel-Images.
  • Regelmäßig prüfen, ob Syscollector erwartungsgemäß scannt (Intervall/scan_on_start).
  1. DB-/Queue-Backpressure ernst nehmen
  • „DB query not synced“ ist ein Betriebs-Signal: Manager/DB ist am Limit oder hat temporäre Blockaden.
  • In großen Umgebungen: Ressourcen für Manager (CPU/RAM/IO), wazuh-db Stabilität und Indexer-Performance gemeinsam betrachten.
  1. Indexer-Health und Auth sauber halten
  • yellow kann in Single-Node/Shard-Situationen normal sein, aber Indexer-Connector muss zuverlässig schreiben/löschen können.
  1. Reset als Runbook dokumentieren
  • Der Reset-Prozess ist legitim und dokumentiert – sollte aber als kontrolliertes Runbook inkl. Wartungsfenster, Rollback (Snapshots) und Verantwortlichkeiten geführt werden.
  1. Ubuntu 18.04 strategisch ablösen
  • Unabhängig vom konkreten CVE-Fall: Alte LTS-Versionen erhöhen Patch- und Backport-Komplexität. Für belastbare Vulnerability KPIs ist ein planbares OS-Lifecycle-Management entscheidend.

Fazit (knappe Zusammenfassung mit Mehrwert)

Wenn CVEs in Wazuh trotz Updates nicht verschwinden, liegt es meist an einem von drei Punkten: (1) Syscollector-Inventar repräsentiert weiterhin verwundbare/alte Pakete (Kernel-Images, fehlender Reboot, Altlasten), (2) der Vulnerability-Scanner kann wegen DB-Sync-/Overload-Problemen nicht konsistent gegen Agent-Daten arbeiten („DB query not synced“), oder (3) der Indexer-Zustand wird nicht korrekt aktualisiert. Der praxisbewährte Weg ist: erst Inventar und reale Paketstände verifizieren, dann Pipeline (Manager↔Indexer) prüfen – und bei persistenter Inkonsistenz den dokumentierten Modul-Reset durchführen, um mit einem sauberen Rescan neu zu starten.

Mehr zu Wazuh …
https://wazuh.com/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

Mehr zum Wazuh Ambassador Program …
https://wazuh.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program

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