Aufbewahrung von „Alerts by Triggers“ in Wazuh: Retention, Statuswechsel und Cloud-Einschränkungen

Einleitung

Die Ansicht Alerting → Alerts → Alerts by triggers im Wazuh Dashboard wird häufig mit den eigentlichen Wazuh-Sicherheitsalerts verwechselt. Technisch handelt es sich jedoch um zwei unterschiedliche Datenarten mit jeweils eigener Speicherung und Aufbewahrungslogik.

Die Indizes wazuh-alerts-* enthalten Ereignisse, die der Wazuh Manager anhand seiner Decoder und Regeln erzeugt. Die Einträge unter „Alerts by triggers“ stammen dagegen aus dem im Wazuh Indexer integrierten OpenSearch Alerting Plugin. Sie entstehen, wenn ein Monitor ausgeführt wird und eine definierte Trigger-Bedingung erfüllt ist. Entsprechend wird ihre Lebensdauer nicht durch die Retention- oder ISM-Richtlinien der wazuh-alerts-*-Indizes gesteuert.

Diese Trennung ist besonders wichtig, wenn Alerts scheinbar ohne Benutzeraktion aus der Ansicht verschwinden oder wenn die Aufbewahrungsdauer in einer Wazuh-Cloud-Umgebung geändert werden soll.

Ausgangslage / Problemstellung

In einer Wazuh-Umgebung wurde beobachtet, dass ein durch einen Monitor erzeugter Alert zunächst unter „Alerts by triggers“ sichtbar war, später jedoch nicht mehr in der Liste erschien. Der Alert war zuvor weder manuell bestätigt noch anderweitig bearbeitet worden.

Zusätzlich traten zwei weitere Symptome auf:

Abfragen des Cluster-Endpunkts /_cluster/settings lieferten den HTTP-Status 404 Not Found.
Die Schaltfläche zum Bestätigen eines Alerts war trotz administrativer Anmeldung deaktiviert.

Die betroffene Umgebung wurde als Wazuh Cloud betrieben. Damit gelten andere administrative Zugriffsmöglichkeiten als bei einer selbstverwalteten Wazuh-Installation.

Für die Analyse müssen deshalb drei voneinander unabhängige Mechanismen betrachtet werden:

der Statuswechsel eines Trigger-Alerts,
die Aufbewahrung der Alert-History-Indizes,
die Zugriffsbeschränkungen in Wazuh Cloud.

Technische Analyse

Wazuh-Sicherheitsalerts und Trigger-Alerts sind nicht dasselbe

Klassische Wazuh-Alerts werden vom Wazuh Manager erzeugt und typischerweise über Filebeat beziehungsweise die Indexer-Integration in Indizes wie wazuh-alerts-4.x-* geschrieben. Ihre Aufbewahrung kann in selbstverwalteten Umgebungen beispielsweise über Index State Management gesteuert werden.

Die Ansicht „Alerts by triggers“ gehört dagegen zur OpenSearch-Alerting-Funktion. Ihr Datenmodell besteht aus:

Monitor: regelmäßig ausgeführte Abfrage gegen einen oder mehrere Indizes,
Trigger: Bedingung, die anhand des Monitor-Ergebnisses ausgewertet wird,
Alert: Statusobjekt, das bei erfüllter Trigger-Bedingung entsteht,
Action: optionale Folgeaktion, beispielsweise eine Benachrichtigung.

Eine Action ist für die Entstehung eines Alerts nicht zwingend erforderlich. Ein Monitor kann daher einen Alert erzeugen, auch wenn keine E-Mail, kein Webhook und keine andere Benachrichtigung konfiguriert wurde.

Lebenszyklus eines Trigger-Alerts

Ein Alert durchläuft abhängig vom Ergebnis des Triggers verschiedene Zustände:

Status	Bedeutung
`ACTIVE`	Die Trigger-Bedingung ist weiterhin erfüllt und der Alert wurde noch nicht bestätigt.
`ACKNOWLEDGED`	Der Alert wurde bestätigt, die auslösende Bedingung kann jedoch weiterhin bestehen.
`COMPLETED`	Die Trigger-Bedingung wird nicht mehr erfüllt.
`ERROR`	Bei der Ausführung des Monitors, Triggers oder einer zugehörigen Verarbeitung ist ein Fehler aufgetreten.
`DELETED`	Der zugehörige Monitor oder Trigger wurde entfernt, während der Alert noch aktiv war.

Ein Alert kann somit ohne jede Benutzeraktion von ACTIVE nach COMPLETED wechseln. Entscheidend ist nicht, ob eine konfigurierte Action abgeschlossen wurde, sondern ob der Trigger bei einer späteren Monitor-Ausführung weiterhin true ergibt. Sobald die Bedingung nicht mehr erfüllt ist, gilt der Alert als abgeschlossen.

Das erklärt auch, weshalb ein Alert scheinbar kurzfristig aus einer Ansicht verschwinden kann: Ist der Filter auf „Active“ gesetzt, wird ein automatisch auf COMPLETED gewechselter Alert sofort ausgeblendet, obwohl sein historischer Datensatz noch vorhanden ist.

Interne Alert-Indizes

Das OpenSearch Alerting Plugin verwendet eigene, versteckte Indizes:

.opendistro-alerting-alerts

Dieser Index enthält laufende Alerts, die für die weitere Monitor-Ausführung und Statusermittlung benötigt werden.

Historische Alert-Datensätze werden in Indizes nach folgendem Muster gespeichert:

.opendistro-alerting-alert-history-<date>

Für Schreibzugriffe auf den jeweils aktuellen History-Index verwendet das Plugin den Alias:

.opendistro-alerting-alert-history-write

Die Alerting-Konfiguration selbst, darunter Monitore und Trigger, liegt in:

.opendistro-alerting-config

Diese Indizes gehören intern zum Alerting Plugin. Sie sollten weder manuell gelöscht noch mit einer allgemeinen ISM-Richtlinie für wazuh-alerts-* verwaltet werden. Direkte Veränderungen können den Alert-Lebenszyklus und nachfolgende Monitor-Ausführungen beschädigen.

Standardmäßige Aufbewahrung

In aktuellen OpenSearch-Versionen wird die Alert-History standardmäßig über folgende dynamische Cluster-Einstellung gesteuert:

plugins.alerting.alert_history_retention_period

Der Standardwert beträgt:

60d

Zusätzlich verwendet das Plugin standardmäßig unter anderem folgende Werte:

plugins.alerting.alert_history_rollover_period = 12h
plugins.alerting.alert_history_max_age = 30d
plugins.alerting.alert_history_max_docs = 1000
plugins.alerting.alert_history_retention_period = 60d

Der Rollover-Mechanismus prüft regelmäßig, ob ein neuer History-Index angelegt oder ein alter Index gelöscht werden muss. Ein Rollover kann durch das maximale Indexalter oder die maximale Dokumentanzahl ausgelöst werden.

Wichtig ist dabei: Die 60 Tage sind eine Aufbewahrungsdauer für History-Indizes, keine garantierte Aufbewahrungsfrist von exakt 60 Tagen für jedes einzelne Alert-Dokument. Die Löschung orientiert sich am Alter des jeweiligen Index. Ein Alert, der erst kurz vor einem Rollover in einen bereits älteren History-Index geschrieben wurde, kann daher weniger als 60 Tage nach seinem eigenen Abschluss gelöscht werden. Umgekehrt können Rollover- und Prüfintervalle dazu führen, dass ein Index etwas länger vorhanden bleibt. Die Aufbewahrungszeit sollte deshalb nicht als sekundengenaue Frist für einzelne Alerts interpretiert werden.

Aktueller und veralteter Einstellungsname

Ältere OpenSearch- beziehungsweise Open Distro-basierte Versionen verwendeten den Namen:

opendistro.alerting.alert_history_retention_period

Der aktuelle Name lautet:

plugins.alerting.alert_history_retention_period

Der alte opendistro.alerting.*-Namensraum ist im OpenSearch-Quellcode noch als veraltete Legacy-Einstellung vorhanden. Bei aktuellen Installationen sollte bevorzugt der Schlüssel plugins.alerting.* verwendet werden. Vor Änderungen empfiehlt es sich, die tatsächlich vom Cluster ausgegebenen Standardwerte zu prüfen.

Ursache des HTTP-Fehlers 404

Der Endpunkt:

GET /_cluster/settings

gehört zur OpenSearch- beziehungsweise Wazuh-Indexer-API. Wird diese Anfrage in den Dev Tools der Wazuh-Server-Verwaltung ausgeführt, wird sie an die falsche API gesendet. Die Wazuh-Server-API kennt den OpenSearch-Endpunkt /_cluster/settings nicht und antwortet deshalb mit 404 Not Found.

In einer selbstverwalteten Wazuh-Installation muss die Abfrage über die Indexer-Konsole ausgeführt werden, typischerweise unter:

Indexer management → Dev Tools

Die Dev Tools unter der Server-Verwaltung und die Dev Tools des Indexers sind technisch unterschiedliche API-Konsolen. Das Wazuh Dashboard kann grundsätzlich Schnittstellen für beide Komponenten bereitstellen.

Einschränkungen in Wazuh Cloud

Wazuh Cloud ist ein verwalteter Dienst. Direkter Zugriff auf die Wazuh-Server-API und die Wazuh-Indexer-API ist standardmäßig eingeschränkt. Der Indexer-API-Zugriff kann auf Anfrage teilweise freigeschaltet werden, direkte Schreiboperationen auf die Indexer-API bleiben jedoch gesperrt.

Damit kann ein Cloud-Benutzer die Cluster-Einstellung für die Alert-History-Retention nicht selbst über eine PUT /_cluster/settings-Anfrage verändern. Diese Einschränkung schützt die Stabilität, Mandantentrennung und Integrität der verwalteten Umgebung. Änderungen, die Schreibzugriff auf Cluster-Einstellungen erfordern, müssen über den Wazuh Support abgestimmt werden.

Warum „Acknowledge“ deaktiviert sein kann

Die Bestätigungsfunktion steht nur für Alerts zur Verfügung, die noch den Status ACTIVE besitzen.

Die Schaltfläche ist normalerweise deaktiviert, wenn der Alert bereits:

bestätigt wurde,
in den Status COMPLETED gewechselt ist,
gelöscht beziehungsweise dem Status DELETED zugeordnet wurde,
nicht mehr als aktiver Alert geladen wurde.

Ein COMPLETED-Status bedeutet dabei nicht, dass die Benachrichtigungs-Action erfolgreich abgeschlossen wurde. Er bedeutet, dass die Trigger-Bedingung bei einer späteren Auswertung nicht mehr erfüllt war.

Lösung / Best Practices

1. Filter und Alert-Status kontrollieren

Zunächst sollte ausgeschlossen werden, dass der Alert lediglich durch einen Filter ausgeblendet wird:

„Alerts by triggers“ öffnen.
Den Statusfilter auf „All alerts“ setzen.
Den Zeitraum der Ansicht prüfen.
Nach Monitor- oder Trigger-Name filtern.
Den Status des betroffenen Alerts kontrollieren.

Für einen Funktionstest der Bestätigungsfunktion sollte anschließend gezielt nach ACTIVE gefiltert werden. Nur ein aktiver Alert kann bestätigt werden.

2. Retention in selbstverwalteten Umgebungen auslesen

In der Indexer-Konsole kann die aktuelle und die standardmäßige Cluster-Konfiguration mit folgender Anfrage angezeigt werden:

GET /_cluster/settings?include_defaults=true&flat_settings=true

In der Antwort sollte nach folgendem Schlüssel gesucht werden:

plugins.alerting.alert_history_retention_period

Bei älteren Installationen kann stattdessen beziehungsweise zusätzlich der Legacy-Schlüssel erscheinen:

opendistro.alerting.alert_history_retention_period

Durch include_defaults=true wird auch dann der Standardwert angezeigt, wenn keine explizite persistente Einstellung gesetzt wurde.

3. Retention in einer selbstverwalteten Umgebung ändern

Um die Aufbewahrungsdauer beispielsweise auf 90 Tage zu erhöhen, kann in einer aktuellen OpenSearch-basierten Installation folgende Anfrage verwendet werden:

PUT /_cluster/settings
{
  "persistent": {
    "plugins.alerting.alert_history_retention_period": "90d"
  }
}

Anschließend sollte die Konfiguration erneut geprüft werden:

GET /_cluster/settings?include_defaults=true&flat_settings=true

In einer älteren Umgebung, die ausschließlich den Legacy-Schlüssel unterstützt, kann die entsprechende Einstellung folgendermaßen aussehen:

PUT /_cluster/settings
{
  "persistent": {
    "opendistro.alerting.alert_history_retention_period": "90d"
  }
}

Der vom Cluster ausgegebene Schlüssel sollte dabei Vorrang vor ungeprüft übernommenen Konfigurationsbeispielen haben.

Eine Erhöhung der Retention wirkt sich auf zukünftige automatische Löschungen der History-Indizes aus. Bereits gelöschte Alert-Datensätze werden dadurch nicht wiederhergestellt.

4. Vorgehen in Wazuh Cloud

In Wazuh Cloud ist die Änderung nicht als Self-Service-Konfiguration verfügbar. Das empfohlene Vorgehen lautet:

Im Wazuh-Cloud-Portal den Hilfebereich öffnen.
Eine Support-Anfrage für die betroffene Umgebung erstellen.
Die gewünschte Alert-History-Retention angeben.
Begründen, weshalb die längere Aufbewahrung benötigt wird, beispielsweise für Incident-Nachverfolgung oder interne Audit-Anforderungen.
Prüfen lassen, ob die gewünschte Einstellung im verwendeten Cloud-Tarif und der konkreten Umgebung unterstützt wird.

Eine Freischaltung von lesendem Indexer-API-Zugriff ersetzt dabei keinen Schreibzugriff. Die PUT /_cluster/settings-Anfrage bleibt in der verwalteten Umgebung dem Betreiber vorbehalten.

5. History-Indizes nicht manuell verwalten

Die folgenden Maßnahmen sollten vermieden werden:

DELETE /.opendistro-alerting-alerts
DELETE /.opendistro-alerting-alert-history-*

Ebenso sollte keine allgemeine ISM-Richtlinie für wazuh-alerts-* auf die internen Alerting-Indizes erweitert werden.

Insbesondere .opendistro-alerting-alerts enthält Laufzeitinformationen, die das Plugin für die Statusermittlung aktiver Alerts benötigt. Eine manuelle Löschung kann doppelte Alerts, inkonsistente Zustände oder fehlerhafte Monitor-Ausführungen verursachen.

Lessons Learned / Best Practices

Die Aufbewahrung von Trigger-Alerts sollte unabhängig von der Retention der eigentlichen Wazuh-Sicherheitsdaten geplant werden. Eine 90-tägige Retention für wazuh-alerts-* bedeutet nicht automatisch, dass auch die Alerting-History 90 Tage verfügbar bleibt.

Für einen stabilen Betrieb haben sich folgende Grundsätze bewährt:

Status und Aufbewahrung getrennt betrachten:
Ein Alert kann aufgrund eines Statuswechsels aus einem aktiven Filter verschwinden, obwohl der historische Datensatz noch gespeichert ist. Erst nach Ablauf der History-Retention wird der zugrunde liegende History-Index automatisch gelöscht.

Alerting nicht als Incident-Management-System behandeln:
Die Alert-History ist in erster Linie für den technischen Lebenszyklus von Monitoren und Triggern vorgesehen. Für revisionssichere Nachverfolgung, Bearbeitungsnotizen, Zuständigkeiten und langfristige Audit-Trails sollten Alerts zusätzlich an ein Ticket-, SOAR- oder Incident-Management-System übergeben werden.

Retention anhand des tatsächlichen Bedarfs dimensionieren:
Eine längere Aufbewahrungsdauer erhöht den Speicherbedarf und die Anzahl historischer Daten. Vor einer Erhöhung sollten Alert-Volumen, Rollover-Häufigkeit und Compliance-Anforderungen bewertet werden.

Aktive Alerts gezielt überwachen:
Dashboards oder betriebliche Kontrollen sollten explizit nach ACTIVE und ERROR filtern. Abgeschlossene Alerts sind für historische Analysen relevant, erfordern jedoch normalerweise keine unmittelbare Reaktion.

Konfigurationsschlüssel versionsabhängig prüfen:
Aktuelle OpenSearch-Versionen verwenden plugins.alerting.*. Ältere Anleitungen können noch opendistro.alerting.* enthalten. Die Cluster-Ausgabe mit include_defaults=true ist die verlässlichste Grundlage für die konkrete Installation.

Cloud- und On-Premises-Betrieb unterscheiden:
Anweisungen für selbstverwaltete Wazuh-Indexer lassen sich nicht unverändert auf Wazuh Cloud übertragen. Fehlende Indexer-Dev-Tools und verweigerte Schreibzugriffe sind dort erwartete Sicherheitsmerkmale und kein Hinweis auf unzureichende Dashboard-Berechtigungen.

Fazit

Die Einträge unter „Alerts by triggers“ werden nicht durch die Retention der wazuh-alerts-*-Indizes verwaltet. Sie gehören zum OpenSearch Alerting Plugin und durchlaufen einen eigenen Status- und Speicherlebenszyklus.

Aktive Alerts liegen im internen Alerting-Index. Sobald die Trigger-Bedingung nicht mehr erfüllt ist, kann ein Alert ohne Benutzeraktion den Status COMPLETED erhalten und aus einer auf aktive Alerts begrenzten Ansicht verschwinden. Historische Alert-Indizes werden standardmäßig anhand einer Retention von 60 Tagen automatisch bereinigt, wobei diese Frist auf Indexebene und nicht als exakte Mindestaufbewahrung pro Alert gilt.

In selbstverwalteten Umgebungen lässt sich die Retention über die Indexer-Cluster-Einstellungen prüfen und anpassen. In Wazuh Cloud sind die erforderlichen Schreibzugriffe bewusst eingeschränkt; eine Änderung muss deshalb über den Wazuh Support erfolgen.