imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

2026-09-15T00:00:00Z

Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

Neue Seite

=== 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:

* <code>location</code>: Enthält standardmäßig den Agent-Namen im Format<code>(agent_name) IP->source</code>
* <code>hostname</code>: Direkte Zuordnung über den Hostnamen des Agents
* <code>level</code>: 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 <code>location</code> (Agent-Name)'''
In <code>/var/ossec/etc/rules/local_rules.xml</code> auf dem Wazuh-Manager:

<syntaxhighlight lang="text">
<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>
</syntaxhighlight>

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

'''Beispiel 2: Unterdrückung über <code>hostname</code>'''

<syntaxhighlight lang="text">
<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>
</syntaxhighlight>

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 <code>level="0"</code> 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 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.com/ambassadors-program/?utm_source=ambassadors&utm_medium=referral&utm_campaign=ambassadors+program]

[https://wazuh.slack.com/archives/C07CCCCGHHP/p1770633589797509 https://wazuh.slack.com/archives/C07CCCCGHHP/p1770633589797509]

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/wazuh-alerts-waehrend-wartungsfenstern-gezielt-unterdruecken/ Wazuh-Blog von m.a.x. it] (veröffentlicht am 10. Februar 2026).

== Unterstützung von m.a.x. it ==
Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]

Wazuh Alerts während Wartungsfenstern gezielt unterdrücken - Versionsgeschichte

imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)