Yellow Cluster State und anwachsende .sst-Dateien bei Wazuh Vulnerability Detection

Einleitung

Seit Wazuh 4.8 basiert die Verarbeitung von Vulnerability Detection und IT-Hygiene-Daten zunehmend auf dem sogenannten Indexer Connector. Dabei werden Zustandsdaten in spezielle State-Indizes wie wazuh-states-vulnerabilities-* geschrieben. In produktiven Umgebungen fiel jedoch auf, dass ein gelber Indexer-Clusterzustand (yellow) teilweise zu anwachsenden .sst-Dateien und erheblichem Speicherverbrauch auf dem Wazuh Manager führen kann.

Ausgangslage / Problemstellung

Mehrere Installationen beobachteten, dass bei einem yellow-Status des Wazuh Indexers die Vulnerability-Detection-Daten zwar weiterhin verarbeitet werden, sich jedoch .sst-Dateien auf dem Wazuh Server ansammeln.

Die zentrale Fragestellung war:

Blockiert ein gelber Clusterzustand die Synchronisierung der Vulnerability- oder IT-Hygiene-Daten vollständig, oder werden die Daten weiterhin indiziert und lediglich lokale Queues nicht korrekt bereinigt?

Besonders kritisch war dies bei Single-Node-Installationen, die aufgrund fehlender Replikate häufig dauerhaft im yellow-Status laufen.

Technische Analyse

Zwischen Wazuh 4.8.0 und 4.9.0 war ein green-Clusterzustand zwingend erforderlich, damit der Indexer Connector korrekt arbeiten konnte. Laut offizieller Dokumentation wurde dieses Verhalten ab Wazuh 4.9.1 geändert: Seitdem unterstützt der Connector sowohl green als auch yellow als zulässigen Clusterzustand. (documentation.wazuh.com)

In der Praxis zeigte sich jedoch ein differenzierteres Verhalten:

Die Vulnerability- und IT-Hygiene-State-Indizes wurden auch bei yellow weiterhin aktualisiert, allerdings wurden lokal gepufferte .sst-Dateien teilweise nicht korrekt bereinigt. Dadurch entstand über längere Zeit erheblicher Speicherverbrauch auf dem Wazuh Manager.

Besonders auffällig war dieses Verhalten in Wazuh 4.13.0:

State-Indizes wurden weiterhin korrekt aktualisiert
Keine Fehler im ossec.log
.sst-Dateien wurden jedoch nicht sauber entfernt

Erst mit Wazuh 4.14.3 wurde die Bereinigung dieser Datenqueues im yellow-Status deutlich verbessert.

Die Problematik betrifft vor allem die interne Verarbeitung des neuen Indexer Connectors. Wazuh entwickelt diese Architektur aktiv weiter, da zukünftige Versionen langfristig Filebeat ersetzen sollen.

Lösung / Best Practices

Zunächst sollte geprüft werden, ob die State-Indizes tatsächlich aktualisiert werden. Relevant sind insbesondere:

wazuh-states-vulnerabilities-*
wazuh-states-inventory-*

Der wichtigste erste Schritt ist die Prüfung des Manager-Logs:

cat /var/ossec/logs/ossec.log | grep -i -E "vulnerability|indexer-connector"

Dabei sollte auf folgende Hinweise geachtet werden:

Fehler beim Aufbau der Verbindung zum Indexer
Fehler beim Erstellen der State-Indizes
Queue- oder Dispatch-Fehler
Timeout- oder Backpressure-Meldungen

Zusätzlich sollte der Clusterzustand geprüft werden:

curl -k -u admin:password https://<indexer>:9200/_cluster/health?pretty

Ein typischer yellow-Status bei Single-Node-Clustern ist häufig normal, wenn Replikate aktiviert bleiben. In solchen Umgebungen empfiehlt sich das Reduzieren der Replikate auf 0.

Beispiel:

PUT /_all/_settings
{
  "index.number_of_replicas": 0
}

Dadurch wird der Cluster bei Single-Node-Deployments in der Regel sofort green.

Für bestehende .sst-Ansammlungen kann unter Umständen eine manuelle Bereinigung notwendig sein. Diese sollte jedoch erst erfolgen, nachdem bestätigt wurde, dass keine aktiven Queue-Prozesse mehr laufen.

Vor manueller Bereinigung empfiehlt sich:

systemctl stop wazuh-manager

Danach sollte geprüft werden, welche .sst-Dateien tatsächlich verwaist sind.

Zusätzlich empfiehlt sich ein Upgrade auf mindestens Wazuh 4.14.3, da dort Verbesserungen am Queue-Handling und an der automatischen Bereinigung implementiert wurden.

Im Zusammenhang mit diesem Themenbereich wurden außerdem Verbesserungen am Reindexing und an der State-Index-Verarbeitung eingeführt. Dazu gehört eine überarbeitete Hash-basierte Mapping-Validierung und automatische Bereinigung alter Backups. (github.com)

Lessons Learned / Best Practices

Ein yellow-Clusterstatus blockiert seit Wazuh 4.9.1 grundsätzlich nicht mehr die Aktualisierung von Vulnerability- oder IT-Hygiene-State-Indizes. Dennoch können ältere Versionen Probleme bei der Bereinigung lokaler Queue-Dateien verursachen.

Wichtig ist daher die Unterscheidung zwischen:

erfolgreicher Index-Aktualisierung
erfolgreicher Queue-Bereinigung

Beides sind unterschiedliche Prozesse.

Gerade Single-Node-Installationen sollten gezielt auf einen stabilen green-Status optimiert werden, da viele Administratoren den dauerhaft gelben Zustand als harmlos betrachten, obwohl dadurch Folgeprobleme entstehen können.

Darüber hinaus zeigt sich, dass der neue Indexer Connector noch nicht denselben Diagnoseumfang bietet wie Filebeat. Fehlersuche ist aktuell oft nur über ossec.log möglich. Erweiterte Diagnosefunktionen analog zu filebeat test output wären insbesondere für State-Indizes und Vulnerability Detection hilfreich.

Administratoren sollten außerdem regelmäßig folgende Bereiche überwachen:

Wachstum von .sst-Dateien
Queue-Verzeichnisse des Managers
Zustand der State-Indizes
Indexer-Cluster-Health
Warnungen des Indexer Connectors im ossec.log

Fazit

Die ursprünglich beobachtete Problematik ist real: Bei Wazuh-Versionen zwischen 4.8 und frühen 4.14-Releases konnten sich .sst-Dateien trotz funktionierender State-Index-Synchronisierung ansammeln, insbesondere bei dauerhaft gelben Clusterzuständen.

Seit Wazuh 4.9.1 werden Vulnerability- und IT-Hygiene-Daten auch bei yellow weiterhin verarbeitet. Erst neuere Versionen wie 4.14.3 verbessern jedoch die automatische Bereinigung der lokalen Queues signifikant.

Für produktive Umgebungen empfiehlt sich daher: