Mehrere Bedingungen in Wazuh-Regeln korrekt umsetzen: if_sid, if_matched_sid und Korrelationsdesign richtig einsetzen

von

Einleitung

Komplexe Use Cases erfordern in Wazuh häufig mehr als eine einfache „Wenn Event X, dann Alert“-Logik. Typische Szenarien sind Multi-Stage-Angriffe, Brute-Force-Versuche mit Vorbedingungen oder Korrelation unterschiedlicher Logquellen innerhalb eines Zeitfensters. Eine häufige Frage lautet daher: Kann eine Wazuh-Regel mehrere Bedingungen enthalten – und wird der Alert nur ausgelöst, wenn alle erfüllt sind?

Die kurze Antwort: Ja, aber nicht beliebig kombiniert. Entscheidend ist das Verständnis der Unterschiede zwischen if_sid, if_matched_sid und if_matched_group sowie der internen Logik von Rule-Chaining und Frequency/Timeframe.

Ausgangslage / Problemstellung

Beispiel einer Regel mit zwei if_matched_sid-Einträgen:

<rule id="100005" level="12" frequency="2" timeframe="120">
    <if_matched_sid>100003</if_matched_sid>
    <if_matched_sid>100002</if_matched_sid>
    <description>Rule test.</description>
    <options>no_full_log</options>
</rule>

Ziel: Ein Alert soll nur erzeugt werden, wenn sowohl Regel 100003 als auch 100002 innerhalb von 120 Sekunden ausgelöst wurden – idealerweise mindestens zweimal.

Das Problem: Diese Konfiguration funktioniert so nicht wie erwartet.

Technische Analyse

1) Unterschied zwischen if_sid und if_matched_sid

Wazuh unterscheidet klar zwischen:

  • if_sid
    Wird genutzt, um eine Regel direkt auf eine andere Regel „aufzusetzen“, die im selben Event-Matching-Prozess bereits gegriffen hat.
    → Klassisches Rule-Chaining innerhalb desselben Logs.
  • if_matched_sid
    Wird für zeitbasierte Korrelation verwendet.
    → Prüft, ob eine bestimmte Regel innerhalb eines definierten timeframe bereits ausgelöst wurde.

Wichtig:
if_matched_sid ist auf eine einzelne SID pro Bedingung ausgelegt und wird im Kontext von Frequency/Timeframe ausgewertet. Mehrere if_matched_sid-Einträge führen nicht automatisch zu einer logischen UND-Verknüpfung im Sinne „beide müssen erfüllt sein“.

Die offizielle Syntax und das Verhalten sind in der Wazuh-Dokumentation beschrieben.
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html#if-matched-group

2) Mehrere SIDs mit if_sid (kommagetrennt)

Im Gegensatz dazu erlaubt if_sid mehrere, kommagetrennte Rule-IDs:

<if_sid>100002,100003</if_sid>

Das bedeutet:
Die aktuelle Regel wird nur geprüft, wenn eine der genannten Regeln im selben Evaluierungsprozess gegriffen hat. Es handelt sich dabei um eine logische ODER-Verknüpfung im Vererbungsmechanismus.

Das funktioniert jedoch nur für unmittelbare Chaining-Szenarien – nicht für zeitbasierte Mehrfachkorrelation über unterschiedliche Events hinweg.

3) Warum mehrere if_matched_sid nicht wie erwartet funktionieren

if_matched_sid prüft:

  • Wurde diese spezifische Regel innerhalb von timeframe Sekunden ausgelöst?
  • Wurde sie mindestens frequency mal ausgelöst?

Die Engine verwaltet diese Korrelation pro SID.
Mehrere if_matched_sid-Blöcke werden nicht automatisch als „alle müssen erfüllt sein“ aggregiert. Das führt häufig zu unerwartetem Verhalten.

Lösung / Best Practices

Option 1: Rule-Chaining (empfohlen für AND-Logik)

Wenn Sie eine echte UND-Verknüpfung zweier Regeln über Zeit möchten, ist die sauberste Methode eine gestufte Korrelation.

Beispiel:

Schritt 1: Regel A (100002)

<rule id="100002" level="5">
    ...
</rule>

Schritt 2: Regel B (100003)

<rule id="100003" level="5">
    ...
</rule>

Schritt 3: Zwischenregel (A-Korrelation)

<rule id="100010" level="8" frequency="2" timeframe="120">
    <if_matched_sid>100002</if_matched_sid>
    <description>Rule A triggered twice</description>
</rule>

Schritt 4: Finale UND-Korrelation

<rule id="100005" level="12" timeframe="120">
    <if_matched_sid>100003</if_matched_sid>
    <if_sid>100010</if_sid>
    <description>Rule A and Rule B correlation</description>
</rule>

Hier ist die Logik sauber getrennt:

  • Regel 100010 kümmert sich um Frequency/Timeframe für A
  • Regel 100005 kombiniert das Ergebnis mit Regel B

So entsteht eine stabile UND-Logik.

Option 2: if_matched_group für gruppenbasierte Korrelation

Wenn mehrere Regeln derselben Gruppe angehören, kann statt einzelner SIDs eine Gruppenprüfung genutzt werden:

<if_matched_group>authentication_failures</if_matched_group>

Das ist sinnvoll, wenn es nicht auf eine konkrete SID, sondern auf eine Kategorie ankommt.

Option 3: Gleicher Event – mehrere Bedingungen direkt matchen

Wenn beide Bedingungen im selben Logeintrag enthalten sind (z. B. IP + Port + Action), dann ist keine Korrelation notwendig.
Dann reicht eine einzelne Regel mit mehreren Match-Feldern:

<rule id="100020" level="10">
    <field name="srcip">1.2.3.4</field>
    <field name="dstport">22</field>
    <field name="action">block</field>
</rule>

In diesem Fall gilt automatisch eine logische UND-Verknüpfung.

Typische Fehlerquellen

  • Mehrere if_matched_sid verwenden und eine UND-Logik erwarten
  • frequency ohne korrektes Korrelationsdesign einsetzen
  • no_full_log verwenden und später forensische Details vermissen
  • Gruppen und SIDs vermischen, ohne die Trigger-Reihenfolge zu verstehen

Lessons Learned / Best Practices

  • if_sid = Vererbung im selben Event
  • if_matched_sid = zeitbasierte Korrelation pro Regel-ID
  • Mehrere if_matched_sid ergeben nicht automatisch eine UND-Logik
  • Komplexe Korrelationen sollten gestuft aufgebaut werden
  • Erst Einzelregeln stabil machen, dann korrelieren
  • Logik immer mit gezielten Testlogs validieren (wazuh-logtest reicht für reine Decoder/Single-Rule-Tests nicht für echte Timeframe-Korrelationen – hier sind reale Events notwendig)

Offizielle Referenz:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html

Fazit

Ja, Wazuh unterstützt mehrere Bedingungen in Regeln – aber die Art der Bedingung bestimmt das Verhalten. Während if_sid für Rule-Chaining geeignet ist, dient if_matched_sid der zeitbasierten Korrelation einzelner Regeln. Wer eine echte UND-Verknüpfung über mehrere Events hinweg benötigt, sollte eine gestufte Korrelationsstruktur aufbauen, anstatt mehrere if_matched_sid-Einträge direkt zu kombinieren.

Saubere Korrelationsarchitektur verhindert Fehlalarme, erhöht die Transparenz und sorgt für nachvollziehbare Detection-Logik – besonders bei komplexen Angriffsmustern.

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