Einleitung
Wenn Wazuh in großen Umgebungen plötzlich nur einen Teil der Agents im Vulnerability-Index anzeigt, liegt die Ursache oft nicht im CVE-Feed selbst und auch nicht primär im Indexer-Cluster. Die Vulnerability Detection in Wazuh arbeitet auf Basis der Syscollector-Inventardaten der Agents. Fehlen Paketdaten oder kommen sie verspätet bzw. unvollständig am Manager an, erscheinen betroffene Endpunkte trotz funktionierender Grundplattform nicht in der Schwachstellenansicht. Genau dieses Muster ist in großen Installationen mit vielen Agents, langen Inventarintervallen und konservativen Synchronisationswerten besonders häufig.
Ausgangslage / Problemstellung
In der beschriebenen Umgebung berichten rund 20.000 Agents an einen Wazuh-Cluster mit etwa 30 Servern und 11 bis 12 Indexer-Nodes. Im Vulnerability-Index tauchen jedoch nur etwa 10.000 bis 12.000 Agents auf. Auffällig ist dabei, dass der OpenSearch- beziehungsweise Indexer-Zustand grün ist, die Threadpools laut Prüfung nicht ausgelastet wirken und im Dashboard keine offensichtlichen Fehler angezeigt werden. Das spricht gegen einen klassischen Cluster-Engpass im Sinne eines vollständig überlasteten Indexers.
Die gepostete Konfiguration enthält zugleich mehrere Hinweise, die das Verhalten erklären können: Syscollector läuft nur alle 24 Stunden, scan_on_start ist deaktiviert, die Synchronisation der Inventardaten ist auf max_eps=10 begrenzt und der feed-update-interval der Vulnerability Detection ist entgegen der späteren Aussage nicht auf 60m, sondern auf 24h gesetzt. Besonders wichtig ist dabei, dass in aktuellen Wazuh-Versionen der relevante Trigger für die Schwachstellenkorrelation nicht irgendein frei definierbarer „Vulnerability Scan alle 12 Stunden“ ist, sondern die Verfügbarkeit aktueller Syscollector-Daten plus ein aktiver Vulnerability-Detection-Prozess auf dem Manager.
Technische Analyse
Wazuh Vulnerability Detection arbeitet nicht losgelöst, sondern baut direkt auf Syscollector auf. Der Agent sammelt Software- und Paketinventar, speichert dieses lokal zwischen und überträgt es anschließend an den Wazuh-Server. Dort werden die Inventardaten pro Agent in Datenbanken verarbeitet und erst danach mit den Vulnerability-Feeds korreliert. Ohne aktuelle Paketinventardaten kann der Manager keine belastbare Schwachstellenzuordnung erstellen. Das ist die zentrale Abhängigkeit in diesem Szenario.
Genau hier fällt die gezeigte Konfiguration auf. Für Syscollector ist interval=86400 gesetzt, also 24 Stunden statt des dokumentierten Defaults von 1h. Zusätzlich ist scan_on_start=no konfiguriert, obwohl der dokumentierte Default yes ist. Das bedeutet praktisch: Ein Agent, der neu onboardet, neu startet oder dessen Inventardatenbank noch nicht aktuell ist, liefert unter Umständen bis zu 24 Stunden lang kein frisches Softwareinventar. In einer Umgebung mit rund 20.000 Agents führt das sehr schnell dazu, dass ein erheblicher Anteil der Systeme im Vulnerability-Index schlicht noch nicht oder nicht mehr aktuell repräsentiert wird.
Hinzu kommt die Konfiguration der Syscollector-Synchronisation mit max_eps=10. Dieser Wert begrenzt die Datenübertragung des Inventars bewusst. In kleinen Umgebungen ist das unkritisch. Bei zehntausenden Agents, die Pakete, Prozesse, Netzwerkdaten und weitere Inventarinformationen liefern, kann dieser Wert jedoch zum Flaschenhals werden. Das Problem zeigt sich dann nicht unbedingt als harter Fehler im Dashboard, sondern als verzögerte oder ausbleibende Sichtbarkeit einzelner Agents in nachgelagerten Funktionen wie der Vulnerability Detection. Die Ursache liegt dann nicht im CVE-Matching selbst, sondern davor: Die Paketlisten kommen zu langsam oder unvollständig an.
Ein weiterer wichtiger Punkt ist der feed-update-interval. In der Diskussion wurde dieser mit 60 Minuten beschrieben, die gepostete Konfiguration zeigt jedoch 24h. Dokumentiert ist 60m als Standardwert. Dieser Parameter steuert zwar nicht die Paketinventarisierung auf den Agents, aber er beeinflusst, wie oft der Manager die Vulnerability-Feed-Daten aktualisiert. In einer großen Umgebung ist ein 24-Stunden-Intervall nicht zwangsläufig falsch, aber es verlängert die Zeit bis neue Feed-Inhalte für die Korrelation bereitstehen. Das erklärt nicht allein, warum 8.000 Agents fehlen, verschlechtert aber die Aktualität zusätzlich.
Die Indexer-Topologie wirkt in diesem Fall eher nachrangig. Ein grüner Clusterstatus und unauffällige Threadpools sprechen dagegen, dass vier Primär-Shards mit zwei Replikaten bei etwa 10 GB pro Primär-Shard die eigentliche Hauptursache sind. Auch die Zahl der Indexer-Hosts in ossec.conf wurde im Verlauf korrigiert. Solange alle Manager die vollständige und korrekte Indexer-Konfiguration besitzen und der Indexer-Connector aktiv ist, ist die wahrscheinlichere Ursache nicht die Speicherung, sondern das vorgeschaltete Fehlen verwertbarer Syscollector-Daten. Wazuh dokumentiert ausdrücklich, dass die Vulnerability Detection ihre Daten für Abfragen und Visualisierung über den Indexer Connector weitergibt, nachdem die Erkennung auf Basis der Inventardaten erfolgt ist.
Lösung / Best Practices
Der erste Schritt ist, die Ursache datenbasiert zu trennen: Fehlen den betroffenen Agents tatsächlich Paketdaten, oder scheitert nur die Anzeige im Vulnerability-Index? Dafür ist die API-Prüfung auf Syscollector-Pakete der richtige Ansatz. Wenn bei nicht angezeigten Agents GET /syscollector/<agent_id>/packages leer bleibt oder veraltete Daten liefert, ist der Fehlerpfad klar: Die Schwachstellenlogik hat kein verwertbares Softwareinventar. In so einem Fall sollte nicht zuerst an Shards oder Replikationsfaktoren gedreht werden, sondern an der Inventarbereitstellung.
Für große Umgebungen ist es sinnvoll, Syscollector näher an die Wazuh-Defaults zu bringen oder die Konfiguration zumindest deutlich aggressiver als bisher auszulegen. Besonders wirksam sind diese Anpassungen:
<wodle name="syscollector">
<disabled>no</disabled>
<interval>1h</interval>
<scan_on_start>yes</scan_on_start>
<hardware>yes</hardware>
<os>yes</os>
<network>yes</network>
<packages>yes</packages>
<ports all="no">yes</ports>
<processes>yes</processes>
<synchronization>
<max_eps>50</max_eps>
</synchronization>
</wodle><vulnerability-detection>
<enabled>yes</enabled>
<index-status>yes</index-status>
<feed-update-interval>60m</feed-update-interval>
</vulnerability-detection>
Diese Richtung ist deshalb sinnvoll, weil Wazuh für Syscollector standardmäßig 1h und scan_on_start=yes dokumentiert. Damit erhalten neue oder neu gestartete Agents schneller ein erstes Inventar, und die Vulnerability Detection kann deutlich zügiger korrelieren. Der höhere max_eps-Wert ist kein universeller Pflichtwert, aber in einer 20k-Agent-Umgebung ist 10 oft unnötig restriktiv. Die konkrete Obergrenze sollte abgestuft getestet werden, um Übertragung und Manager-Last in Einklang zu bringen.
Zusätzlich sollte geprüft werden, ob die betroffenen Agents gemeinsame Merkmale haben. Besonders relevant sind Betriebssystemtypen, Paketmanager, Agent-Versionen, Netzwerksegmente und Onboarding-Zeitpunkte. Wenn vor allem neu aufgenommene Agents oder bestimmte Betriebssystemfamilien fehlen, deutet das stark auf verzögerte oder unvollständige Syscollector-Läufe hin. Wenn hingegen alle Syscollector-Daten vorhanden sind, aber keine Schwachstellen angezeigt werden, muss als Nächstes in Richtung Manager-Logs, Indexer-Connector und CTI-Feed-Zugriff geprüft werden.
Operativ empfiehlt sich außerdem, Änderungen gestaffelt einzuführen. Wer in einer Umgebung mit 20.000 Agents scan_on_start global aktiviert und gleichzeitig das Intervall massiv senkt, erzeugt schlagartig sehr viel zusätzliche Inventaraktivität. Besser ist ein kontrollierter Rollout über Agent-Gruppen oder ausgewählte Segmente. So lässt sich beobachten, ob die Zahl der im Vulnerability-Index sichtbaren Agents stabil ansteigt, ohne andere Teile der Plattform unnötig zu belasten.
Lessons Learned / Best Practices
In großen Wazuh-Installationen wird Vulnerability Detection oft als eigenständiger Scanner betrachtet. Technisch ist sie das aber nur bedingt. Tatsächlich ist sie eine Korrelationsebene, die auf aktueller und vollständiger Syscollector-Inventarisierung aufsetzt. Wer dieses Fundament drosselt, etwa durch lange Intervalle, deaktiviertes scan_on_start oder zu konservative Synchronisationswerte, reduziert indirekt auch die Sichtbarkeit im Vulnerability-Index.
Ein grüner Indexer-Cluster bedeutet deshalb nicht automatisch, dass die Schwachstellenpipeline gesund ist. Der Storage-Layer kann sauber laufen, während die vorgelagerten Agent-zu-Manager-Inventardaten unvollständig bleiben. Genau deshalb sollte die Diagnose immer in dieser Reihenfolge erfolgen: Sind Paketdaten vorhanden, kommen sie rechtzeitig an, funktioniert die Korrelation, und erst danach stellt sich die Frage nach der Indexierung.
Ebenso wichtig ist saubere Konfigurationsklarheit. In der geschilderten Situation wurde verbal von 60m gesprochen, die gezeigte Konfiguration enthielt jedoch 24h. Solche Abweichungen sind in der Fehlersuche hochrelevant, weil sie die Erwartungshaltung an Aktualität massiv verzerren. In produktiven Clustern mit mehreren Managern sollte daher regelmäßig geprüft werden, ob die Konfiguration wirklich konsistent ausgerollt ist und nicht nur dokumentiert konsistent erscheint.
Fazit
Wenn in einer großen Wazuh-Umgebung nur 60 bis 70 Prozent der Agents im Vulnerability-Index erscheinen, ist die wahrscheinlichste Ursache nicht die Anzahl der Shards, sondern fehlendes oder verspätetes Syscollector-Paketinventar. In der gezeigten Konfiguration sprechen insbesondere interval=86400, scan_on_start=no und synchronization max_eps=10 für genau dieses Muster. Der nachhaltige Lösungsweg besteht darin, zuerst die Inventardatenbasis zu stabilisieren und zu beschleunigen, danach Feed-Aktualität und Indexer-Connector zu validieren und erst zuletzt die Indexer-Topologie als eigentlichen Engpass zu behandeln. So wird aus einer scheinbar diffusen Vulnerability-Anzeige wieder eine technisch nachvollziehbare und skalierbare Wazuh-Funktion.
Quellenverweis
Wazuh Vulnerability Detection – Configuration
https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/configuring-scans.html
Wazuh Vulnerability Detection – How it works
https://documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/how-it-works.html
Wazuh System Inventory – How it works
https://documentation.wazuh.com/current/user-manual/capabilities/system-inventory/how-it-works.html
Wazuh Syscollector local configuration
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/wodle-syscollector.html
Wazuh Vulnerability Detection local configuration
https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/vuln-detector.html
Wazuh System Inventory – Configuration
https://documentation.wazuh.com/current/user-manual/capabilities/system-inventory/configuration.html
Wazuh Syscollector information and inventory fields
https://documentation.wazuh.com/current/user-manual/capabilities/system-inventory/available-inventory-fields.html
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/C07CCCCGHHP/p1774944049699249