Wazuh Default-Regeln sicher tunen: Warum frequency/timeframe/ignore in 0016-wazuh_rules.xml scheitern – und wie du Rule 203/204 korrekt überschreibst

Einleitung (Einordnung, Relevanz für Security/SIEM/Wazuh)

In produktiven Wazuh-Umgebungen ist „Alert Noise“ oft weniger ein Detection-Problem als ein Betriebsproblem: Zu viele legitime Ereignisse erzeugen Warnungen, SOC-Workflows werden überlastet und echte Incidents gehen unter. Gleichzeitig ist das Ruleset in Wazuh eng mit der Event-Pipeline (Agent → Manager → Queues → Analysis) verzahnt. Wer Default-Regeln direkt in den ausgelieferten Rule-Files ändert oder Korrelation-Attribute falsch einsetzt, riskiert Parse-Fehler beim Neustart oder – schlimmer – ungewollte Blind Spots.

Dieser Beitrag zeigt anhand der Regeln 203/204 („Agent event queue is full/flooded“), warum bestimmte Parameter in der Praxis „nicht akzeptiert“ werden, und wie man die Regeln update-sicher und syntaktisch korrekt überschreibt.

Ausgangslage / Problemstellung (Zusammenfassung, Symptome, Umgebung)

Die Default-Regeln sollen wegen legitimer Aktivität „leiser“ gemacht werden. Dazu wurden in 0016-wazuh_rules.xml frequency, timeframe und ignore ergänzt:

<rule id="203" level="9" frequency="100" timeframe="10" ignore="1800">
  <if_sid>201</if_sid>
  <field name="level">full</field>
  ...
</rule>

Nach der Änderung und einem Neustart meldet Wazuh einen Fehler und lädt das Ruleset nicht wie erwartet. Die zentrale Frage: Unterstützt das Ruleset diese Parameter nicht – oder ist die Implementierung falsch?

Technische Analyse (Ursachen, betroffene Komponenten, Architekturbezug, Stolpersteine)

1) Default-Rulefiles direkt zu ändern ist update- und betriebstechnisch riskant

Wazuh sieht ausdrücklich vor, Default-Regeln nicht in den ausgelieferten Dateien zu verändern, sondern per Custom Rules zu erweitern oder zu überschreiben. Üblicher Weg: Regel in /var/ossec/etc/rules/local_rules.xml kopieren und mit overwrite="yes" die Standarddefinition ersetzen. Das ist dokumentiert und verhindert, dass Updates deine Änderungen überschreiben.

Zusätzlich lädt Wazuh Rulefiles in definierter Reihenfolge; das Überschreiben funktioniert zuverlässig, wenn die Custom-Rule später geladen wird (typisch: local_rules.xml). Details zur Lade-/Overwrite-Logik finden sich auch in Community-Diskussionen.

2) `frequency/timeframe` ist Korrelation – und braucht `if_matched_sid` statt `if_sid`

Der Kernfehler in der gezeigten Änderung ist konzeptionell: frequency und timeframe sind Attribute für zeitbasierte Korrelation („Composite Rules“). Dafür muss die Regel an bereits gematchte Events/Regeln gekoppelt werden – in Wazuh typischerweise über if_matched_sid. Genau das ist in der offiziellen Ruleset-XML-Syntax dokumentiert: if_matched_sid ist der Mechanismus, um eine Regel abhängig von vorherigen Matches zu korrelieren.

if_sid hingegen ist eine klassische „Ableitung“/Verfeinerung (gleicher Event, weitere Bedingung) und nicht die semantische Basis für „zählende“ Korrelation über Zeitfenster. In der Praxis führt das oft zu Parse-/Validierungsproblemen oder zu Regeln, die nie so arbeiten wie intendiert.

3) Noise bei 203/204 ist häufig ein Symptom – nicht die Ursache

Die Meldungen „Agent event queue is full“ / „… flooded“ deuten meist darauf hin, dass am Agent (oder im Transport) Ereignisspitzen nicht schnell genug abfließen können. Wazuh beschreibt für Agents explizit Anti-Flooding-/Buffer-Mechanismen im <client_buffer>-Block (Queue-Größe, Throughput in EPS).

Auf Manager-Seite gibt es ebenfalls Queue-Mechanismen, die den Datenfluss stabilisieren sollen.

Nur „dämpfen“ per Rule-Tuning kann sinnvoll sein (z. B. um SOC-Lärm zu reduzieren), ersetzt aber nicht die technische Ursachenbehebung (Queue/Throughput/Noisy Sources).

Lösung / Best Practices (konkrete Schritte, Konfigurationen, Reihenfolge, Side-Effects)

Schritt 1: Default-Regeln unangetastet lassen, stattdessen korrekt überschreiben

Regel 203/204 aus dem Default-File kopieren
In /var/ossec/etc/rules/local_rules.xml einfügen
overwrite="yes" setzen
Korrelation korrekt formulieren (falls du wirklich frequency/timeframe willst)

Beispiel (syntaktisch korrekt, inklusive if_matched_sid):

<group name="local,">

  <rule id="203" level="9" overwrite="yes" frequency="100" timeframe="10" ignore="1800">
    <if_matched_sid>201</if_matched_sid>
    <field name="level">full</field>
    <description>Agent event queue is full. Events may be lost.</description>
    <group>agent_flooding,pci_dss_10.6.1,gdpr_IV_35.7.d,</group>
  </rule>

  <rule id="204" level="12" overwrite="yes" frequency="100" timeframe="10" ignore="1800">
    <if_matched_sid>201</if_matched_sid>
    <field name="level">flooded</field>
    <description>Agent event queue is flooded. Check the agent configuration.</description>
    <group>agent_flooding,pci_dss_10.6.1,gdpr_IV_35.7.d,</group>
  </rule>

</group>

Danach:

systemctl restart wazuh-manager

Diese Vorgehensweise („Changing existing rules“ via overwrite) ist der dokumentierte Standard.

Wichtig: Achte auf saubere XML-Syntax. Schon kleine Tippfehler in Closing-Tags führen zu genau den „nach Neustart Fehler“-Symptomen.

Schritt 2: Korrelation bewusst einsetzen – sonst lieber Level/Groups anpassen

Überlege, ob du wirklich eine „100 Events in 10s“-Korrelation brauchst. Für reines Noise-Management sind oft stabiler:

Level reduzieren (z. B. auf 3–5) statt Korrelationslogik einzubauen
Rule-Gruppe nutzen, um Benachrichtigungen/Integrationen selektiv zu filtern
Gezielt Quellen reduzieren, die Flooding verursachen (z. B. Debug-Logs, Audit-Spam)

Die XML-Rulesyntax (inkl. Rule-Attribute) ist in der Doku beschrieben.

Schritt 3: Root Cause beheben – Agent Buffer / EPS und Manager Queue prüfen

Wenn 203/204 häufig aus legitimer Aktivität feuern, ist das ein Hinweis auf Lastspitzen oder ungünstige Throughput/Buffer-Werte. Zwei Maßnahmen, die in der Praxis oft zielführend sind:

A) Agent-seitig Anti-Flooding/Buffer tunen
Passe <client_buffer> an (Queue-Größe und events_per_second), um Peaks besser abzufangen und schneller abfließen zu lassen. Wazuh dokumentiert diese Optionen explizit.

B) Manager-seitige Queue-Mechanismen verstehen und Engpässe lokalisieren
Die Wazuh-Server-Queue-Architektur ist dokumentiert und hilft bei der Fehlersuche (wo staut es: Input, Analysis, Output/Indexer).

Side-Effect: Höhere EPS/Queue-Werte können CPU/IO/Netzlast erhöhen. Änderungen daher begleitet messen (Agent-CPU, Manager-Load, Event-Ingest im Indexer).

Lessons Learned / Best Practices (präventive Maßnahmen, Betrieb, Skalierung)

Nie Default-Rules in ausgelieferten Dateien „hart“ ändern: Nutze local_rules.xml + overwrite="yes" für update-sichere Anpassungen.
frequency/timeframe nur mit if_matched_sid einsetzen: Das ist Korrelation über vorherige Matches – nicht nur „mehr Attribute an eine Regel hängen“.
Noise ist oft ein Performance-/Pipeline-Symptom: Wenn Agent-Queues voll laufen, sind Buffer/EPS und noisy Quellen meist der Hebel – nicht nur das Ruleset.
Änderungen testbar machen: Regel-Overrides versionieren (Git), in Staging prüfen, und nach Rollout Alarmrate + Agent/Manager-Health überwachen.

Fazit (knappe Zusammenfassung mit Mehrwert)

Die Parameter frequency, timeframe und ignore sind in Wazuh grundsätzlich nutzbar – aber nicht „beliebig“: Sobald du zeitbasierte Korrelation willst, musst du Regeln sauber als Composite Rules modellieren (typisch mit if_matched_sid). Gleichzeitig sollten Default-Regeln nicht im Standard-Ruleset editiert werden, sondern über local_rules.xml mit overwrite="yes" update-sicher überschrieben werden.

Für 203/204 gilt außerdem: Wer nur dämpft, ohne Agent-Buffer/Throughput und die Queue-Pipeline zu betrachten, bekämpft oft nur Symptome. Die robuste Lösung kombiniert korrektes Rule-Override mit Ursachenbehebung in der Event-Pipeline.

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