Wazuh Alerts während Wartungsfenstern gezielt unterdrücken

Einleitung

Regelmäßige Betriebssystem- und Applikationsupdates gehören zum Alltag jeder IT-Umgebung. Für Security- und SIEM-Teams stellen diese Wartungsfenster jedoch eine besondere Herausforderung dar: Während Updates laufen, erzeugen Agenten oft eine Vielzahl erwartbarer, aber sicherheitlich irrelevanter Events. Ohne geeignete Maßnahmen kann dies zu Alert-Fluten, unnötiger Belastung des Wazuh-Managers und Alarmmüdigkeit bei Analysten führen. Dieser Artikel zeigt, wie sich Alerts für einzelne Wazuh-Agenten während Wartungsarbeiten gezielt und kontrolliert unterdrücken lassen.

Ausgangslage / Problemstellung

In typischen Wazuh-Installationen sind hunderte oder tausende Agenten angebunden. Werden mehrere Hosts gleichzeitig aktualisiert, entstehen häufig Warnungen zu gestoppten Services, Paketänderungen, Audit-Events oder kurzzeitigen Policy-Verletzungen.
Die Anforderungen sind dabei klar:

  • Alerts sollen temporär unterdrückt werden
  • Die Maßnahme soll nur ausgewählte Agenten betreffen
  • Die Event-Daten dürfen optional weiterhin angenommen werden
  • Die Lösung muss revisionssicher und kontrollierbar sein

Ein vollständiges Abschalten des Managers oder ungezieltes Deaktivieren von Regeln ist dafür keine Option.

Technische Analyse

Wazuh verarbeitet Events agentenseitig, klassifiziert sie serverseitig über den Ruleset-Mechanismus und erzeugt daraus Alerts. Entscheidend ist:
Nicht jedes empfangene Event muss zwangsläufig zu einem Alert führen.

Der Ruleset-Mechanismus erlaubt es, Events anhand verschiedener Felder zu filtern, darunter:

  • location: Enthält standardmäßig den Agent-Namen im Format
    (agent_name) IP->source
  • hostname: Direkte Zuordnung über den Hostnamen des Agents
  • level: Steuert die Alert-Relevanz (Level 0 = ignoriert)

Damit lassen sich sehr präzise Filter definieren, die Events weiterhin verarbeiten, aber bewusst nicht alarmieren.
Ein häufiger Stolperstein ist dabei die Verwechslung von Agent-ID, Agent-Name und Hostname – je nach Umgebung muss das passende Feld gewählt werden.

Lösung / Best Practices

Der empfohlene Ansatz ist die Definition einer lokalen Regel mit Alert-Level 0, die ausschließlich für die betroffenen Agenten greift.

Beispiel 1: Unterdrückung über location (Agent-Name)
In /var/ossec/etc/rules/local_rules.xml auf dem Wazuh-Manager:

<group name="maintenance,">
  <rule id="100200" level="0">
    <location>^(agent_name_1|agent_name_2)</location>
    <description>Suppress alerts during maintenance for specific agents</description>
  </rule>
</group>

Diese Regel greift für alle Events, deren location mit einem der angegebenen Agent-Namen beginnt.

Beispiel 2: Unterdrückung über hostname

<rule id="150000" level="0">
  <hostname>agent_name_1|agent_name_2</hostname>
  <description>Suppress alerts on selected hosts during maintenance</description>
  <group>suppression,</group>
</rule>

Dieser Ansatz ist besonders sinnvoll, wenn Hostnamen eindeutig und konsistent gepflegt sind.

Nach jeder Regeländerung ist ein Neustart des Wazuh-Managers erforderlich, damit die neue Konfiguration aktiv wird.

Alternative Ansätze
Je nach Wartungsszenario kann es auch sinnvoll sein:

  • den Wazuh-Agenten auf dem Host temporär zu stoppen
  • Event-Quellen (z. B. Auditd, Sysmon) gezielt auszusetzen

Diese Varianten verhindern die Event-Erzeugung vollständig, sind jedoch operativ aufwendiger und bergen das Risiko, relevante Events zu verlieren.

Lessons Learned / Best Practices

  • Wartungsfenster sollten im SIEM konzeptionell vorgesehen sein
  • Alert-Unterdrückung ist sauberer als globale Regel-Deaktivierung
  • Regeln mit level="0" sind ideal für temporäre Suppression
  • Agent-Namen und Hostnamen sollten eindeutig und dokumentiert sein
  • Wartungs-Regeln nach Abschluss konsequent entfernen oder deaktivieren

Für größere Umgebungen empfiehlt sich eine standardisierte Maintenance-Gruppe im Ruleset sowie ein klar definierter Prozess für deren Aktivierung.

Fazit

Wazuh bietet mit seinem flexiblen Ruleset-Mechanismus eine saubere Möglichkeit, Alerts während Wartungsarbeiten gezielt zu unterdrücken, ohne die Integrität der Event-Daten zu gefährden. Durch den Einsatz von Level-0-Regeln auf Basis von Agent-Name oder Hostname lassen sich False Positives effektiv vermeiden, während der SIEM-Betrieb stabil und kontrollierbar bleibt.

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/C07CCCCGHHP/p1770633589797509