Custom Decoder & Rules für „Storage alarm“-Syslog: PCRE2 korrekt einsetzen, Syntaxfehler vermeiden, schneller testen

von

Einleitung

Geräte- und Storage-Logs landen in Wazuh häufig als „Raw Syslog“: ein Syslog-Präfix (Timestamp/Tag) plus ein herstellerspezifischer Payload. Damit daraus verwertbare Alerts entstehen, braucht es zwei Dinge: Decoder, die relevante Felder extrahieren (User, Quell-IP, Ergebnis, Error-Code), und Rules, die diese Felder bewerten. Wazuh liefert dafür eine klare XML-Syntax und unterstützt neben OSRegex auch PCRE2 – was bei komplexeren Mustern und „freiem Text“ oft die stabilere Wahl ist. documentation.wazuh.com+2documentation.wazuh.com+2

Der Thread zeigt ein klassisches Problem: Regex funktioniert auf regex101, aber der Decoder „matcht“ in Wazuh nicht oder wirft Syntaxfehler. Ursache sind fast immer Kleinigkeiten in der Wazuh-Decoder-Syntax (z. B. fehlender prematch, falsche Feldliste in <order>, zu striktes \w+, falsches Programm-Tag).

Ausgangslage / Problemstellung

Beispiel-Logs:

  • Success:
    Dec 11 18:30:57 Storage alarm: <189>2025-12-11 ... Informational(0): The login of the user (user name mm_user) from the source (127.0.0.1) succeeded.
  • Failure:
    Dec 11 18:26:42 Storage alarm: <189>2025-12-11 ... Informational(0): The user (user name admin) failed to login from the source (10.1.70.1).The error code is 0x40403285.

Der Nutzer hat Decoder gebaut, aber:

  • kein prematch zur eindeutigen Auswahl der Child-Decoder,
  • <order> ohne Komma-Trennung,
  • Regex mit (\w+) (bricht bei Usernames mit Bindestrich/Punkt/Domain-Format),
  • und teils unklar, ob program_name wirklich alarm ist (Syslog-Tag ist „Storage alarm:“).

Technische Analyse

1) PCRE2 in Wazuh: Muss explizit aktiviert werden

Wazuh unterscheidet Regex-Typen (OSRegex/OSMatch/PCRE2). PCRE2 aktivierst du in Decodern explizit über type="pcre2" – und du kannst PCRE2 in program_name, prematch und regex verwenden. documentation.wazuh.com+2documentation.wazuh.com+2

2) prematch ist nicht optional – er stabilisiert Child-Decoder

Mehrere Child-Decoder unter einem Parent brauchen eine eindeutige Vorselektion, sonst kann es sein, dass der falsche Decoder greift oder keiner sauber passt. Genau deshalb ist prematch als „leichter Filter“ üblich und wird auch in Wazuh-Beispielen empfohlen. documentation.wazuh.com+1

3) <order>-Syntax: Kommagetrennte Felder

In Wazuh-Decodern ist <order> eine Liste – und die wird kommagetrennt geschrieben. Ein häufiger Fehler ist, die Felder mit Leerzeichen zu trennen (funktioniert nicht wie erwartet und führt zu Parsing-/Mapping-Problemen). Wazuh dokumentiert die Decoder-Syntax und Feldextraktion über <regex> + <order> explizit. documentation.wazuh.com+1

4) regex101 ist hilfreich – aber Wazuh-logtest ist die Wahrheit

regex101 ist gut für PCRE2-Patterns, aber es testet nicht den Wazuh-Decoder-Wrapper (Parent/Child, prematch, program_name, order). Dafür ist wazuh-logtest gedacht – Wazuh dokumentiert das als Standardweg zum Testen von Decodern und Regeln. documentation.wazuh.com+2documentation.wazuh.com+2

Lösung / Best Practices

1) Decoder: robust gegen kleine Formatvarianten (Usernames, Leerzeichen, Punkt nach Klammer)

Platziere Custom-Decoder in der vorgesehenen Custom-Struktur (Wazuh Doku: Custom decoders) und teste mit wazuh-logtest. documentation.wazuh.com+1

/var/ossec/etc/decoders/local_decoder.xml

<decoder name="storage-alarm">
  <!-- Syslog-tag ist hier typischerweise "alarm" aus "Storage alarm:" -->
  <program_name>alarm</program_name>
</decoder>

<!-- Login succeeded -->
<decoder name="storage-alarm-login-success">
  <parent>storage-alarm</parent>
  <prematch>succeeded</prematch>
  <regex type="pcre2">The login of the user \(user name\s+([^)]+)\)\s+from the source\s+\(([^)]+)\)\s+succeeded</regex>
  <order>dstuser,srcip,result</order>
</decoder>

<!-- Login failed -->
<decoder name="storage-alarm-login-failed">
  <parent>storage-alarm</parent>
  <prematch>failed to login</prematch>
  <regex type="pcre2">The user \(user name\s+([^)]+)\)\s+failed to login from the source\s+\(([^)]+)\)\.\s*The error code is\s+(0x[0-9A-Fa-f]+)</regex>
  <order>dstuser,srcip,error_code</order>
</decoder>

Warum diese Anpassungen?

  • ([^)]+) statt (\w+): fängt auch mm_user, domain\user, user.name ab.
  • \s+ und \s*: toleriert Formatvarianten („).The“, zusätzliche Leerzeichen).
  • prematch: sorgt dafür, dass Success/Fail nicht miteinander kollidieren.
  • <order> kommagetrennt.

PCRE2-Syntax und Aktivierung über type="pcre2" ist dokumentiert. documentation.wazuh.com+1

2) Rules: zwei klare Alerts, Failure höher priorisieren

/var/ossec/etc/rules/local_rules.xml

<group name="storage,auth,">
  <rule id="121100" level="5">
    <decoded_as>storage-alarm</decoded_as>
    <match>succeeded</match>
    <description>Storage login succeeded: user=$(dstuser) srcip=$(srcip)</description>
    <group>authentication_success,</group>
  </rule>

  <rule id="121101" level="8">
    <decoded_as>storage-alarm</decoded_as>
    <match>failed to login</match>
    <description>Storage login FAILED: user=$(dstuser) srcip=$(srcip) error=$(error_code)</description>
    <group>authentication_failed,</group>
  </rule>
</group>

Regeln-/Decoder-Syntax und Variablenersetzung sind in der Ruleset-XML-Doku abgedeckt (Decoders/Rules und „Creating from scratch“ als Workflow). Wazuh+1

3) Realtime testen: wazuh-logtest statt nur regex101

Auf dem Manager:

/var/ossec/bin/wazuh-logtest

Logzeile einfügen → prüfen, ob in Phase 2 dstuser, srcip etc. auftauchen und in Phase 3 die Rule feuert. Wazuh dokumentiert wazuh-logtest explizit für Decoder-/Rule-Tests (CLI, Dashboard, API). documentation.wazuh.com+2documentation.wazuh.com+2

Lessons Learned / Best Practices

  • Regex-Engine bewusst wählen: Für solche Freitext-Patterns ist PCRE2 oft robuster – aber nur, wenn type="pcre2" gesetzt ist. documentation.wazuh.com+1
  • prematch einsetzen: stabilisiert Child-Decoder und reduziert Fehlmatches. documentation.wazuh.com+1
  • <order> immer mit Kommas: sonst werden Felder nicht korrekt gemappt.
  • regex101 ≠ Wazuh-Decoder-Test: regex101 hilft beim Pattern, aber Wazuh-logtest validiert das komplette Decoder-/Rule-Setup. documentation.wazuh.com+1
  • Custom-Dateien upgrade-sicher halten: Wazuh weist darauf hin, Custom-Decoders getrennt zu pflegen, um Updates des Original-Rulesets nicht zu blockieren. documentation.wazuh.com

Fazit

Für Storage-Syslog-Events ist der schnellste Weg zu stabilen Alerts: Parent nach program_name, Child-Decoders mit prematch, PCRE2 mit toleranter Regex und korrekter <order>-Liste. regex101 kann beim Regex-Bau helfen – aber die verlässliche „Realtime“-Validierung ist wazuh-logtest, weil es Decoding (Phase 2) und Rule-Firing (Phase 3) im tatsächlichen Wazuh-Parser zeigt. documentation.wazuh.com+1

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/C0A933R8E/p1767095793724279