Wazuh Threat Hunting zeigt keine neuen Events trotz funktionierender Webhooks: Shard-Exhaustion im Indexer als „Silent Stop“ bei Single-Node-Setups

von

Einleitung

Ein klassisches Fehlerbild in Wazuh-Umgebungen mit Webhook-Integrationen: Alerts werden ausgelöst, Webhook-Ziele erhalten Events, auf dem Manager landen Einträge in alerts.json – aber im Threat Hunting (Dashboard/Discover) erscheint nichts Neues. In der Praxis ist das oft kein Problem der Analyse-Engine, sondern ein Indexer-Thema: Shard-Limits und daraus resultierende Indexing-Stopps bei Single-Node-Clusters. Dieser Beitrag zeigt, wie du das Muster erkennst, warum es auftritt und wie du es nachhaltig behebst.

Ausgangslage / Problemstellung

Symptome:

  • Webhook läuft „fine“ (Events kommen im Zielsystem an)
  • Wazuh-Dienste laufen (Manager, Dashboard, Indexer, Filebeat)
  • Events erscheinen nicht in Threat Hunting / Discover
  • Freier Speicher ist vorhanden (z. B. 50% frei) → wirkt zunächst unverdächtig

Entscheidender Befund aus _cluster/health:

  • Single Node (number_of_nodes: 1)
  • Status yellow
  • active_primary_shards: 995 (nahe an 1000)
  • unassigned_shards: 5

Damit ist das Problem sehr wahrscheinlich: Shard-Exhaustion am Limit.

Technische Analyse

1) Warum „Alerts sind da“, aber „Threat Hunting sieht nichts“

Wenn Alerts über Webhooks ausgelöst werden, ist das ein guter Indikator dafür, dass:

  • Wazuh-Manager Events analysiert
  • Regeln matchen
  • Alerts in alerts.json geschrieben werden

Dass Threat Hunting leer bleibt, bedeutet dagegen:
Die Indexierung in den Wazuh Indexer läuft nicht (mehr) zuverlässig, oder die Dokumente werden nicht geschrieben/zugeordnet.

Ein häufiges Muster ist, dass der Indexer unter bestimmten Bedingungen keine neuen Shards mehr anlegen kann oder Indizes in einen blockierten Zustand geraten – der Manager läuft weiter, aber das Dashboard sieht nichts, weil die Daten nicht im Indexer landen.

2) Das Shard-Limit ist unabhängig von „50% freiem Speicher“

Viele Administratoren prüfen zuerst Disk Space. Das ist sinnvoll, aber Shard-Exhaustion ist ein anderes Limit:

  • Ein Indexer kann genug Speicherplatz haben und trotzdem keine neuen Shards mehr verwalten.
  • In Single-Node-Umgebungen sind 1000 Shards ein praktisches Warn-/Grenzgebiet, weil jede Rotation (täglich/mehrere Patterns) Shards weiter erhöht.
  • yellow + unassigned_shards deutet zusätzlich auf Replica-/Allocation-Themen hin, die bei Single Node häufig „normal“ sind, aber in Kombination mit Shard-Druck kritisch werden.

3) Wodurch entstehen so viele Shards in Wazuh?

Typische Ursachen:

  • zu häufige Index-Rotation (z. B. daily indices für viele Patterns)
  • zu viele Shards pro Index (Default-Templates, falsches Sizing)
  • lange Retention ohne Lifecycle-Management
  • zusätzliche Indexpfade (Archives, States, Statistics, Custom Indices)

Das Ergebnis: Shard-Zahl wächst über Monate, bis der Indexer „an die Wand“ fährt – oft ohne sofort offensichtlichen Crash.

Lösung / Best Practices

Ziel: Shard-Anzahl senken und Shard-Wachstum kontrollieren, damit Indexierung wieder zuverlässig läuft.

Schritt 1: Sofortmaßnahmen (wieder indexierbar werden)

  1. Retention verkürzen / alte Indizes löschen
    • Ja: „nur letzte 3 Monate behalten“ ist eine valide Sofortmaßnahme.
    • Wichtig: erst prüfen, welche Indizes am meisten Shards verursachen (z. B. wazuh-alerts-*, wazuh-archives-*, wazuh-states-*).
  2. Index-Blockaden prüfen (read-only / flood-stage)
    • Wenn Disk-Watermarks getriggert wurden, können Indizes auf read-only springen, selbst wenn später wieder Platz frei ist.
    • Dann müssen Blocks entfernt werden, sonst bleibt Indexing kaputt, obwohl Storage ok ist.
  3. Filebeat-Output testen
    • filebeat test output muss sauber sein.
    • Wenn Output ok ist, bleibt als Ursache meist Indexer/Mappings/Blocks/Shard-Limit.

Schritt 2: Nachhaltig: Shard-Strategie & Lifecycle etablieren

Best Practice für Wazuh Indexer (Single Node):

  • Index-Lifecycle (ILM/ISM) oder definierte Retention: automatische Löschung nach X Tagen/Monaten
  • Shard-Anzahl pro Index minimieren
    • 1 Primary Shard pro Tagesindex ist für viele Umgebungen mehr als genug, besonders single-node
  • Rotation nicht zu fein
    • „Daily“ ist ok, aber „Hourly“ oder viele getrennte Patterns ohne Not treiben Shards extrem hoch
  • Wenn HA/Skalierung gefordert ist: auf mehrere Indexer-Nodes gehen, statt Single Node bis ans Limit zu pressen

Schritt 3: Kontrollmetriken fest definieren

  • regelmäßiger Check: _cluster/health + _cat/shards + _cat/indices
  • Alarmierung, wenn Shards > z. B. 800 (früher Warnpunkt)
  • Monitoring auf Indexing-Errors in Filebeat und Indexer-Logs

Lessons Learned / Best Practices

  • Webhook-Erfolg beweist nur: Analyse im Manager funktioniert – nicht, dass Indexierung ok ist.
  • Shard-Limit ist ein „Silent Killer“: Die Plattform wirkt gesund (Dienste laufen), aber neue Daten erscheinen nicht mehr.
  • Retention/Rotation ist nicht „nice to have“, sondern zwingend – besonders bei Single-Node-Indexern.
  • „Mehr Disk“ löst Shard-Exhaustion nicht automatisch. Entscheidend ist Shard-Hygiene.

Fazit

Wenn Threat Hunting keine neuen Events zeigt, obwohl Webhooks Alerts liefern, ist die wahrscheinlichste Ursache bei Single-Node-Setups ein Indexer-Engpass. Der _cluster/health-Befund mit 995 aktiven Primärshards ist ein klarer Hinweis auf Shard-Exhaustion am Limit. Kurzfristig hilft Retention verkürzen und alte Indizes löschen, ggf. Blocks entfernen. Langfristig brauchst du eine saubere Lifecycle-/Shard-Strategie (oder ein skalierbares Indexer-Cluster), damit Indexierung stabil bleibt und Threat Hunting zuverlässig Daten anzeigt.

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/p1765958350021269