Wer Wazuh länger im Einsatz hat, kennt das Problem:
Im Vulnerability Dashboard tauchen Schwachstellen von Agents auf, die längst offline oder sogar vollständig gelöscht sind. Die Folge sind überfüllte Dashboards, verfälschte Risikobewertungen und unnötige Verunsicherung.
In diesem Beitrag zeige ich, wie wir uns bewusst für eine aggressive Retention-Strategie entschieden haben – und warum das in der Praxis oft die beste Lösung ist.
Das Problem: Vulnerabilities von längst verschwundenen Systemen
Wazuh trennt klar zwischen:
- Agent-Verwaltung (Manager)
- Datenhaltung (OpenSearch / Indexer)
Wird ein Agent gelöscht, bleiben seine historischen Daten – insbesondere Vulnerability States – zunächst im Index bestehen. Ohne Lifecycle-Management sammeln sich so über Monate oder Jahre:
- CVEs von Offline-Agents
- Schwachstellen aus alten Testsystemen
- Einträge aus längst abgeschalteten Projekten
Das Dashboard zeigt dann Risiken, die faktisch nicht mehr existieren.
Warum wir uns gegen „alles behalten“ entschieden haben
Theoretisch könnte man argumentieren:
„Historische Vulnerability-Daten sind doch wichtig.“
In der Praxis haben wir festgestellt:
- Vulnerability Detection ist zustandsbasiert, nicht forensisch
- Alte CVEs ohne aktiven Agenten haben keinen operativen Mehrwert
- Compliance-Reports beziehen sich fast immer auf den aktuellen Zustand
- Die Datenmenge wächst unnötig → Performance leidet
Unsere Schlussfolgerung:
Was länger offline ist, ist für das Tagesgeschäft irrelevant.
Die Lösung: Aggressive Retention per Index State Management (ISM)
Statt einzelne Agents oder CVEs manuell zu löschen, setzen wir auf eine klare Regel:
Alle
wazuh-states-*Indizes werden nach 30 Tagen automatisch gelöscht.
Damit erreichen wir:
- keine „Zombie-Agents“ mehr
- saubere Dashboards
- klare Sicht auf reale Risiken
- dauerhaft geringe Indexgröße
Technische Umsetzung
Wazuh nutzt OpenSearch Index State Management (ISM).
Die folgende Policy löscht alle wazuh-states-* Indizes nach 30 Tagen automatisch.
ISM-Policy erstellen
PUT _plugins/_ism/policies/wazuh-states-retention-30d
{
"policy": {
"description": "Retention for wazuh-states-* (delete after 30 days)",
"default_state": "hot",
"states": [
{
"name": "hot",
"actions": [],
"transitions": [
{
"state_name": "delete",
"conditions": {
"min_index_age": "30d"
}
}
]
},
{
"name": "delete",
"actions": [
{
"delete": {}
}
],
"transitions": []
}
],
"ism_template": [
{
"index_patterns": ["wazuh-states-*"],
"priority": 50
}
]
}
}
Bestehende Indizes anhängen (einmalig)
POST _plugins/_ism/add/wazuh-states-*
{
"policy_id": "wazuh-states-retention-30d"
}
Ab diesem Moment:
- werden alte State-Indizes automatisch entfernt
- erscheinen offline Agents nach spätestens 30 Tagen nicht mehr
- bleiben nur noch relevante, aktive Daten
Was passiert danach?
Wichtig zu wissen:
- Der Index wird automatisch neu erstellt, sobald aktive Agents wieder Daten liefern
- Vulnerabilities werden neu berechnet, basierend auf:
- aktuellem Paketbestand
- aktuellen Feeds (NVD, OVAL etc.)
- Es gibt keinen Datenverlust für aktive Systeme
Kurz gesagt:
Wazuh zeigt nur noch die Realität.
Für wen ist diese Strategie geeignet?
✅ Sehr gut geeignet für:
- operative Security-Teams
- SOCs
- Umgebungen mit vielen kurzlebigen Hosts
- Cloud- und Testlandschaften
⚠️ Weniger geeignet für:
- forensische Langzeitarchivierung
- historische Compliance-Nachweise über Jahre
(In solchen Fällen empfiehlt sich ein separates Archiv oder Export.)
Fazit
Mit einer aggressiven ISM-Retention für wazuh-states-*:
- verschwinden Zombie-Vulnerabilities automatisch
- bleiben Dashboards übersichtlich
- sinkt der administrative Aufwand auf null
Für uns war Option 4 die klarste, sauberste und nachhaltigste Lösung.
Security sollte aktuell sein – nicht nostalgisch.