Wazuh Dashboard verliert Verbindung zum Indexer nach manueller Index-Löschung: Ursachen, Security-Reinit und saubere Recovery

von

Einleitung

Wazuh-Umgebungen stehen und fallen mit einem konsistenten Wazuh Indexer (OpenSearch). Sobald Indexdaten “auf Dateisystemebene” manuell entfernt werden, kann das zwar kurzfristig Speicherplatz schaffen, aber auch Cluster-Metadaten, Shard-Zuordnungen und sicherheitsrelevante Systemindizes beschädigen. Die Folge reicht von roten Clusterzuständen bis hin zu nicht initialisierter OpenSearch-Security – und damit zu einem nicht mehr erreichbaren Wazuh Dashboard.

Ausgangslage / Problemstellung

In der Umgebung wurden alte Index-Verzeichnisse direkt auf dem Indexer gelöscht, z. B. unter:

  • /var/lib/wazuh-indexer/nodes/0/indices/
  • betroffen waren u. a. wazuh-alerts-*, wazuh-monitoring-*, wazuh-statistics-*

Danach startete der Dienst zwar, aber:

  • Das Dashboard meldete TLS/SSL-Probleme (u. a. certificate unknown) und Connection Refused (lokal 127.0.0.1:9200).
  • Filebeat meldete 503 Service Unavailable: OpenSearch Security not initialized.
  • Indexer-Logs zeigten wiederholt java.lang.NullPointerException (u. a. im Kontext von Hintergrundjobs/Runner-Services).

Die zentrale Vermutung: Manuelles Löschen hat Shards/Metadaten oder sicherheitskritische Indizes (z. B. Security-Konfiguration) inkonsistent gemacht, sodass Security nicht hochkommt und damit jede nachgelagerte Komponente scheitert.

Technische Analyse

1) Warum “rm -rf” bei OpenSearch/Indexer so gefährlich ist
OpenSearch verwaltet Indexzustände nicht nur als Dateien, sondern über Cluster-State und Metadaten. Wenn Shard-Verzeichnisse “unter der Haube” verschwinden, bleibt der Cluster-State oft auf Referenzen sitzen, die nicht mehr erfüllbar sind:

  • Primärshards fehlen → Cluster wird rot (red).
  • Replikate können nicht promotet werden, weil die Primärdaten physisch weg sind.
  • System- und Security-Komponenten können hängen, weil sie auf funktionsfähige Indizes, Templates und interne Initialisierungen angewiesen sind.

2) OpenSearch Security nicht initialisiert → Dominoeffekt
Wenn OpenSearch Security not initialized erscheint, ist das ein harter Blocker:

  • Filebeat kann keine Daten indexieren (503).
  • Dashboard kann sich nicht authentifizieren/autorisiert verbinden.
  • Je nach Zertifikats- und TLS-Setup wirken die Symptome wie “SSL kaputt”, tatsächlich ist aber häufig die Security-Schicht nicht startfähig (oder der Cluster nicht stabil genug, um Security-Indices zu laden).

3) Red Cluster verhindert typische Recovery-Skripte
Viele Security-Initialisierungsschritte (z. B. indexer-security-init.sh bzw. securityadmin.sh) erwarten mindestens einen gelben Clusterzustand oder brauchen explizit eine Option, um auf einem roten Cluster zu arbeiten. Wenn die Primärshards fehlen, läuft man schnell in Timeouts und “keep trying”-Schleifen.

4) Speicher/RAM als zusätzlicher Verstärker
OpenSearch/Indexer ist Java-basiert. In Recovery-Situationen (Cluster-State-Rebuild, Securityadmin-Läufe, Diagnose) steigt der Speicherbedarf. Ein “mmap failed”/JVM Memory Error kann Recovery-Schritte abbrechen, selbst wenn die eigentliche Ursache (fehlende Primärshards) schon kritisch genug ist.

5) NPE in Indexer-Logs
NullPointerExceptions in Scheduler-/Runner-Komponenten sind in solchen Situationen häufig Folgefehler: Hintergrundjobs erwarten Indizes, Mappings oder Clusterinformationen, die im roten Zustand nicht zuverlässig verfügbar sind. Das macht die Logs “lauter”, ist aber selten der primäre Auslöser.

Lösung / Best Practices

Je nachdem, wie stark der Cluster beschädigt ist, gibt es zwei realistische Pfade: Security/Cluster Recovery (wenn noch ausreichend Daten/Metadaten konsistent sind) oder Neuaufsetzen des Indexers (wenn Primärshards/Indexstruktur irreparabel fehlen). In dem hier beschriebenen Verlauf war das Neuaufsetzen die saubere und schnellste Stabilisierung.

A) Minimaler Recovery-Versuch: Security-Reinit korrekt ausführen

  1. Indexer sauber neu starten:
systemctl restart wazuh-indexer
  1. Security-Init-Skript ausführen (lädt u. a. Zertifikatsinfos und initialisiert Security):
/usr/share/wazuh-indexer/bin/indexer-security-init.sh
  1. Wenn der Cluster rot ist (fehlende Primärshards) und das Skript blockiert: Security-Init mit Red-Cluster-Akzeptanz ausführen (je nach Skriptversion/Wrapper-Optionen):
/usr/share/wazuh-indexer/bin/indexer-security-init.sh --options -arc
  1. Clusterzustand prüfen:
curl -k -u admin https://<WAZUH_INDEXER_IP_ADDRESS>:9200/_cluster/health?pretty

Wichtig: Dieser Pfad ist nur sinnvoll, wenn OpenSearch überhaupt stabil erreichbar ist und der Cluster nicht “fundamental” zerstört wurde. Wenn der Indexer nicht mehr sauber hochkommt oder dauerhaft rot bleibt, ist Neuinstallation meist wirtschaftlicher.

B) Robuste Wiederherstellung: Indexer neu installieren und Daten gezielt zurückholen

Wenn (a) Primärshards weg sind, (b) Security-Init dauerhaft scheitert oder (c) der Dienst danach gar nicht mehr läuft: Indexer neu aufsetzen.

Empfohlene Reihenfolge:

  1. Konfiguration und Zertifikate sichern, bevor etwas entfernt wird:
cp /etc/wazuh-indexer/certs/* /tmp/
cp /etc/wazuh-indexer/opensearch.yml /tmp/
  1. Indexer deinstallieren (entsprechend Distribution/Installationsweg).
  2. Indexer in exakt passender Version wieder installieren (Version sollte zu Manager/Dashboard passen). Version des Managers prüfen:
yum list installed wazuh-manager
# oder
apt list --installed wazuh-manager
  1. Zertifikate zurückspielen:
  • nach /etc/wazuh-indexer/certs/
  1. Konfiguration (opensearch.yml) wiederherstellen und nur dann anpassen, wenn sich Hostnames/IPs/Zertifikats-SANs geändert haben.
  2. Security-Init erneut ausführen und Clusterzustand prüfen (wie oben).
  3. Datenwiederherstellung: Wenn Alerts-Backups (z. B. alerts.json.gz) vorhanden sind, lassen sich historische Alerts wieder importieren, statt auf Dateisystem-Reste zu hoffen.

C) SSL-Fehler richtig einordnen und beheben

SSL/TLS-Meldungen wie ssl3_read_bytes:sslv3 alert certificate unknown sind in diesem Kontext oft sekundär:

  • Wenn Security nicht initialisiert ist, kann der Handshake/Client-Auth scheitern oder Dashboard/Beats laufen in unerwartete TLS-Fehlerbilder.
  • Nach Stabilisierung von Indexer + Security sollten TLS-Probleme systematisch geprüft werden:
    • Stimmen CA/Chain und Truststore?
    • Greift Dashboard wirklich auf https:// und den richtigen Port zu?
    • Stimmen Hostname/IP mit Zertifikats-SAN überein?
    • Werden Node-Zertifikat und Admin-/Client-Zertifikat korrekt getrennt verwendet (Securityadmin braucht typischerweise ein Client-Zertifikat)?

Lessons Learned / Best Practices

1) Indizes niemals über das Dateisystem löschen
Für Wazuh/OpenSearch gilt: Indizes über Index Management oder API löschen, nicht durch Entfernen von Verzeichnissen. Das verhindert “Zombie-Metadaten”, rote Clusterzustände und beschädigte Shard-Zuordnungen.

2) Lifecycle-Strategie statt Ad-hoc-Löschung

  • Retention/Deletion über Index Management/ISM definieren.
  • Für Wazuh-Indizes ist eine klare Aufbewahrungsstrategie (z. B. 30/90/180 Tage) plus regelmäßige Überwachung von Disk Watermarks essenziell.

3) Backups/Exports für Recovery einplanen

  • Alerts-Backups (z. B. komprimierte JSON-Exports) sind Gold wert, wenn ein Indexer neu aufgesetzt werden muss.
  • Für größere Umgebungen zusätzlich Snapshot-Strategien (Repository) einführen.

4) Ressourcen im Blick behalten (RAM/Disk)

  • JVM-basierte Komponenten reagieren empfindlich auf Memory Pressure.
  • Disk knapp → Watermarks → Shard Allocation stoppt → Folgekaskaden. Monitoring von RAM/Disk/IO ist Pflicht.

5) “Red Cluster” als klarer Entscheidungsmarker
Wenn Primärshards physisch fehlen, ist “Reparieren” häufig ein Fass ohne Boden. Dann ist ein kontrolliertes Neuaufsetzen des Indexers oft schneller, stabiler und sicherer – mit anschließender Datenrückführung aus Backups.

Fazit

Manuelles Löschen von Index-Verzeichnissen kann einen Wazuh Indexer in einen roten, inkonsistenten Zustand versetzen, in dem OpenSearch Security nicht mehr initialisiert und Dashboard/Beats zwangsläufig scheitern. In leicht beschädigten Fällen hilft eine saubere Security-Reinitialisierung; wenn Primärshards fehlen oder der Dienst instabil wird, ist Neuinstallation des Indexers mit Wiederverwendung von Zertifikaten/Konfiguration und anschließender Alert-Recovery der robusteste Weg. Entscheidend ist, Löschvorgänge künftig ausschließlich über Index Management/ISM und mit geplanter Retention durchzuführen.

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/C07CNG3M11N/p1762405187012089