Warum ein Sophos-Firewall-Decoder in Wazuh „nicht funktioniert“: Wenn mehrere Events in einer Logzeile stecken

von

Einleitung
Custom Decoder sind in Wazuh ein Standardwerkzeug, um herstellerspezifische Logs (z. B. Sophos Firewall „SFW“) in strukturierte Felder zu überführen. Wenn ein Decoder trotz korrekter Regex scheinbar nicht greift, liegt die Ursache häufig nicht im Regex selbst, sondern im Ingestionsformat: Wazuh decodiert grundsätzlich pro eingehendem Event eine Logmessage – wenn ein Forwarder oder ein Logfile mehrere Einzelereignisse in eine einzige Zeile „zusammenklebt“, kann die Analysis Engine nicht mehr sauber pro Event decodieren. Genau dieses Muster ist bei vielen Firewall-/Syslog-Setups eine klassische Fehlerquelle.

Ausgangslage / Problemstellung
Ein Decoder-Set soll Sophos-Firewall-Logs anhand von device_name="SFW" matchen und danach viele Key/Value-Felder extrahieren (timestamp, model, serial, rule-id, ports, bytes, etc.). Der Basismatcher ist:

<decoder name="SFW">
  <prematch>device_name="SFW"</prematch>
</decoder>

und danach folgen zahlreiche Child-Decoder (Parent SFW) mit einzelnen Regex-Ausdrücken.

In den gelieferten Rohlogs zeigt sich jedoch, dass eine einzelne „Logzeile“ mehrfach hintereinander device_name="SFW" enthält, getrennt durch Sequenzen wie #000<30>.... Zusätzlich existiert ein Beispiel aus archives.json, in dem im full_log mehrere Sophos-Ereignisse hintereinander concatenated sind.

Technische Analyse

1) Wazuh decodiert pro Event – nicht pro „Teilsegment“ innerhalb einer Logzeile

Die Wazuh Analysis Engine (wazuh-analysisd) arbeitet eventorientiert: Ein eingehender Logeintrag wird vor-dekodiert (Timestamp/Program/Location) und anschließend durch Decoder/Rules gejagt. Decoder sind darauf ausgelegt, einen Logeintrag zu strukturieren – nicht eine Kette mehrerer, ineinander verklebter Events. Wazuh Dokumentation+1

Sobald mehrere Sophos-Events in einer einzigen Logmessage stecken, passiert typischerweise Folgendes:

  • Der Decoder matcht zwar device_name="SFW", aber
  • die Extraktion kann sich nur auf den „vorderen“ Teil konsistent beziehen,
  • der Rest der verketteten Ereignisse wird nicht als eigenständige Events analysiert (damit fehlen Felder, Regeln greifen unzuverlässig, und vieles wirkt „nicht decodiert“).

2) Der eigentliche Fehler ist das Logformat: „Merged Logs“

Das bereitgestellte full_log zeigt wiederholt #000<30>device_name="SFW" ... innerhalb derselben Zeile. Das ist ein starkes Indiz, dass die Quelle/Weiterleitung (z. B. Syslog-Collector, rsyslog, Logfile-Writer) mehrere Syslog-Nachrichten in einen einzigen Write zusammenfasst.

Decoder-Feintuning kann das nicht „reparieren“, weil die Semantik „ein Event = eine Nachricht“ verloren gegangen ist.

3) Prematch/Parent ist nicht das Problem – aber Program-Name/Predecoding kann Prematch beeinflussen

Wazuhs Decoder-Syntax verlangt, dass Regex-Decoder entweder selbst ein prematch/program_name besitzen oder über den Parent erben. Außerdem kann – je nach Predecoding – ein program_name-Match zielführender sein als ein freier prematch. Wazuh Dokumentation

In diesem Fall ist der entscheidende Punkt jedoch: Selbst ein perfekter Prematch hilft nicht, wenn die Eingabe mehrere Events enthält.

Lösung / Best Practices

Schritt 1: Erst Ingestion korrigieren – ein Event pro Zeile herstellen

Die wichtigste Best Practice lautet: Sorgen Sie dafür, dass jede Sophos-Firewall-Nachricht als eigene Zeile/Message an Wazuh geht.

Wenn die Logs aus einer Datei wie /var/log/sophos.log per Wazuh Agent gesammelt werden, sollte die localfile-Konfiguration sauber gesetzt sein (für Syslog-artige Zeilen typischerweise syslog). Wazuh dokumentiert die Logfile-Überwachung über <localfile> inklusive log_format und location. Wazuh Dokumentation+1

Beispiel (konzeptionell):

<localfile>
  <log_format>syslog</log_format>
  <location>/var/log/sophos.log</location>
</localfile>

Wenn dennoch mehrere Events in einer Zeile landen, liegt die Ursache meist vor Wazuh: ein Upstream-Collector schreibt gebatcht oder ohne Zeilentrennung.

Pragmatischer Workaround, wenn der Upstream nicht änderbar ist:

  • Ein kleines Split-Script auf dem System, das /var/log/sophos.log liest,
  • am Marker device_name="SFW" (oder #000<30>device_name="SFW") trennt,
  • und die resultierenden Einzelereignisse in eine neue Datei schreibt,
  • die Wazuh dann überwacht.

Damit bekommt Wazuh wieder „ein Event pro Message“ – erst dann lohnt sich Decoder-Arbeit.

Schritt 2: Decoder vereinfachen und robust machen

Wenn die Events wieder sauber getrennt sind, lohnt es sich, den Decoder-Ansatz zu härten:

  • Ein Basisdecoder (prematch auf device_name="SFW" oder alternativ program_name, falls eindeutig).
  • Child-Decoder mit Offsets nur dann, wenn die Positionierung nötig ist. Offsets sind mächtig, aber bei Key/Value-Logs oft nicht erforderlich. Wazuh Dokumentation+1
  • Problematische Regex wie (\.+) sollten vermieden werden (matcht „mindestens ein Punkt“ und ist für Texte wie Local rule ungeeignet). Für „beliebiger Text bis zum nächsten Quote“ ist typischer: ([^"]+).
  • Felder, die manchmal quoted und manchmal unquoted sind (z. B. log_version=1 vs. "1") brauchen entweder zwei Decoder oder einen Regex, der beide Varianten toleriert.

Schritt 3: Verifizieren mit echtem Input (archives.json / logtest)

Für Decoder-Validierung ist entscheidend, mit vollständigen Beispielereignissen zu testen (z. B. aus archives.json oder dem originalen full_log). So sieht man exakt, was analysisd wirklich verarbeitet. Wazuh beschreibt das Archiving/Logging-Konzept und wie Events nachvollziehbar gemacht werden. Wazuh Dokumentation

Lessons Learned / Best Practices

  • Decoder „funktionieren“ nur, wenn das Event-Granulat stimmt: ein Logeintrag muss ein einzelnes Ereignis sein.
  • Wenn ein Log mehrere device_name="SFW" enthält, ist das kein Decoder-Problem, sondern ein Upstream-Merge.
  • localfile korrekt konfigurieren und die Quelle so bauen, dass jede Nachricht einzeln geschrieben/weitergeleitet wird. Wazuh Dokumentation+1
  • Decoder-Syntax sauber halten: Parent/Prematch/Program-Name und Offsets gemäß Doku einsetzen. Wazuh Dokumentation
  • Erst nach der Trennung lohnt sich Feintuning der Regex (Quoted vs unquoted, whitespace, Textfelder mit Spaces).

Fazit
Wenn ein Sophos-Firewall-Decoder auf device_name="SFW" basiert und „nicht funktioniert“, ist der häufigste Root Cause nicht die Decoder-Definition, sondern ein eingehendes Logformat mit zusammengeklebten Einzelereignissen. Wazuh analysiert pro eingehender Message – stecken mehrere SFW-Events in einer Zeile, wird effektiv nur ein Teil zuverlässig decodiert. Die nachhaltige Lösung ist daher zweistufig: zuerst Events sauber trennen (Upstream oder per Split-File), danach den Decoder vereinfachen und robust gegen Quoting/Spaces machen. Auf dieser Basis werden Felder konsistent extrahiert und Regeln greifen zuverlässig. Wazuh Dokumentation+2Wazuh Dokumentation+2

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