Ausgangslage
Ein Nutzer wollte ModSecurity-Events im JSON-Format mit einer eigenen Wazuh-Regel erkennen.
Die Regel sah korrekt aus, erzeugte aber keine Alerts, obwohl die Events sauber dekodiert wurden.
Regel (ursprünglich):
<group name="modsecurity,web">
<rule id="100001" level="3">
<decoded_as>json</decoded_as>
<field name="transaction.producer.modsecurity">
ModSecurity v3.0.14 (Linux)
</field>
<description>ModSecurity request observed</description>
</rule>
</group>
Beispiel-Event (Auszug):
"producer": {
"modsecurity": "ModSecurity v3.0.14 (Linux)",
"connector": "ModSecurity-nginx v1.0.4"
}
Trotz passendem Feldinhalt wurde kein Alert generiert.
Ursache
Der entscheidende Punkt:
Das <field>-Element in Wazuh-Regeln nutzt OS_Regex (osregex) – nicht einen reinen String-Vergleich.
In osregex haben bestimmte Zeichen eine Sonderbedeutung, darunter:
(und)
Diese müssen escaped werden, sonst passt der Regex nicht auf den tatsächlichen Feldwert.
Lösung
Die Klammern im Feldwert müssen mit \( und \) escaped werden.
Korrigierte Regel:
<group name="modsecurity,web">
<rule id="100001" level="3">
<decoded_as>json</decoded_as>
<field name="transaction.producer.modsecurity">
ModSecurity v3.0.14 \(Linux\)
</field>
<description>ModSecurity request observed</description>
</rule>
</group>
Ergebnis
Nach der Anpassung:
wazuh-logtestzeigt korrekt:- Phase 2: JSON-Decoding erfolgreich
- Phase 3: Regel
100001matched
- Alert wird wie erwartet erzeugt
- Dashboard zeigt ModSecurity-Events zuverlässig an
Best Practices für Wazuh-Regeln mit <field>
<field>verwendet immer osregex- Sonderzeichen immer escapen, z. B.:
(→\()→\).→\.+→\+
- Alternativ: bewusst Regex-Patterns nutzen, z. B.:
<field name="transaction.producer.modsecurity">ModSecurity v3\.</field>
Takeaway
Wenn eine Regel bei JSON-Logs scheinbar „korrekt aussieht“, aber nicht feuert, ist die Ursache sehr häufig Regex-Syntax.
Ein schneller Check: Enthält der Match-String Sonderzeichen?
Wenn ja → escapen 👍
https://wazuh.slack.com/archives/C0A933R8E/p1765724985798659