In komplexen Cloud-Umgebungen ist es essenziell, ungewöhnliche Aktivitäten frühzeitig zu erkennen. Eine häufige Herausforderung: Ein überwachter Benutzerin führt eine Operation plötzlich von einer neuen, bisher unbekannten IP-Adresse aus.
Im Slack-Thread aus dem Wazuh-Community-Channel schilderte Marcin Strzyzewski genau dieses Problem – und erhielt hilfreiche Antworten, die wir hier zusammenfassen.
Ausgangssituation
Marcin wollte eine korrelierende Wazuh-Regel schreiben, die eine Warnung erzeugt, wenn:
- Ein Account aus einer Überwachungsliste (
CDB list) enthalten ist - Eine Operation ausgeführt wird
- Diese Operation im Vergleich zur vorigen Meldung von einer neuen IP-Adresse stammt
Die Basisregeln sahen so aus:
<rule id="915311" level="0">
<if_sid>91531</if_sid>
<decoded_as>json</decoded_as>
<list field="office365.UserId" lookup="match_key">etc/lists/o365/monitored-accounts</list>
<group>office365,monitored-accounts,</group>
<options>no_full_log</options>
<description>Monitored account $(office365.UserId) event: $(office365.Operation) operation</description>
</rule>
<rule id="915312" level="7" timeframe="3600" frequency="2">
<if_matched_sid>915311</if_matched_sid>
<decoded_as>json</decoded_as>
<same_field>office365.UserId</same_field>
<different_field>office365.ClientIP</different_field>
<group>office365,monitored-accounts,</group>
<options>no_full_log</options>
<description>Monitored account $(office365.UserId) performs $(office365.Operation) from a new IP $(office365.ClientIP)</description>
</rule>
Trotz korrekter Logformate wurde die zweite Regel nie ausgelöst.
Die Ursache: Regel-Level, Priorisierung und SIDs
Wazuh-Experte Jakub Pacowski identifizierte das Problem schnell:
1. Die erste Regel hatte Level 0
Regeln mit Level 0 werden verworfen, bevor sie für korrelierende Regeln wie <if_matched_sid> berücksichtigt werden.
→ Die zweite Regel konnte also nie triggern.
2. Wenn man Level > 0 setzt, entsteht ein neues Problem
Setzt man die Regel z. B. auf Level 1 oder 2, gewinnt möglicherweise eine andere Office-365-Regel (z. B. 91532) die Priorität beim Matching.
→ Die „Monitored Account“-Regel läuft dann gar nicht an.
Die funktionierende Lösung: Supress-Regel und Level-Anpassung Jakub schlug eine elegante Kaskade vor:
- 915311 bekommt Level 4
→ So wird sie zuverlässig ausgewertet - 915313 unterdrückt diese Regel
→ verhindert unerwünschte Alerts - 915312 korreliert dann sicher auf Basis von 915313
→ das eigentliche IP-Wechsel-Event wird ausgelöst
Hier die funktionierende Version:
<rule id="915311" level="4">
<if_sid>91531</if_sid>
<list field="office365.UserId" lookup="match_key">etc/lists/o365/monitored-accounts</list>
<group>office365,monitored-accounts,</group>
<options>no_full_log</options>
<description>Monitored account $(office365.UserId) event: $(office365.Operation) operation</description>
</rule>
<rule id="915313" level="2">
<if_sid>915311</if_sid>
<description>Supress 915311</description>
</rule>
<rule id="915312" level="7" timeframe="3600" frequency="2">
<if_matched_sid>915313</if_matched_sid>
<same_field>office365.UserId</same_field>
<different_field>office365.ClientIP</different_field>
<group>office365,monitored-accounts,</group>
<options>no_full_log</options>
<description>Monitored account $(office365.UserId) performs $(office365.Operation) from a new IP $(office365.ClientIP)</description>
</rule>
Ergebnis
Die Regelkette funktioniert zuverlässig
Keine unnötigen Alerts im Dashboard
IP-Wechsel werden korrekt erkannt
Marcin bestätigte: „Works good, thank you very much!“
Weitere Tipps aus der Community
Jakub gab zusätzlich wertvolle Hinweise:
<decoded_as>json</decoded_as> ist in Kindregeln nicht mehr nötig
Wazuh verarbeitet das Format automatisch.
Regel-IDs sollten im Bereich 100000–120000 liegen
Dies entspricht den Best Practices und vermeidet Konflikte mit Standardregeln.
Vorsicht bei der Regelnummerologie
Wenn man viele Custom-Files pflegt, ist es leicht, Nummern zu doppeln.
Marcins Ansatz, regelähnliche IDs durch Anhängen von Ziffern zu erzeugen, ist praktisch – muss aber sauber dokumentiert werden.
Fazit
Der Slack-Thread zeigt eindrucksvoll, wie subtil Wazuh-Regellogik sein kann:
- Level-Einstellungen spielen eine entscheidende Rolle
- Parent-/Child-Regelbeziehungen müssen exakt stimmen
- Supress-Regeln ermöglichen flexible, saubere Korrelationslogik
- Community-Wissen beschleunigt die Fehlersuche enorm
Dank eines einfachen, aber cleveren dreistufigen Setups wird nun zuverlässig gemeldet, wenn ein sensibler Office-365-Account von einer neuen IP-Adresse agiert – ein wichtiger Baustein für moderne Cloud-Sicherheitsüberwachung.
https://wazuh.slack.com/archives/C0A933R8E/p1764089579561909