Sophos Firewall (SFW) Logs in Wazuh

Warum „DoS Attack / Denied“ korrekt decodiert wird – und trotzdem nicht immer sichtbar ist

Einleitung

Sophos-Firewall-Logs (SFW / XG / XGS) gehören zu den umfangreichsten und komplexesten Firewall-Logs überhaupt.
Besonders Felder wie:

log_component="DoS Attack"
log_subtype="Denied"

sorgen häufig für Verwirrung, wenn sie nicht wie erwartet im wazuh-logtest oder Dashboard erscheinen, obwohl Decoder vorhanden sind.

Dieser Artikel erklärt:

  • wie Sophos-Logs strukturiert sind
  • warum Decoder technisch korrekt sein können, ohne sichtbare Felder zu erzeugen
  • wie man Decoder richtig testet
  • und welche Best Practices bei großen Sophos-Decoder-Sets gelten

1. Beispiel: Sophos DoS-Attack-Log

Aus dem Thread (gekürzt, relevant):

device_name="SFW"
log_type="Firewall"
log_component="DoS Attack"
log_subtype="Denied"
severity="Warning"
src_ip="91.189.92.23"
dst_ip="192.168.99.2"
protocol="TCP"
src_port=80
dst_port=51358
hb_status="No Heartbeat"

➡️ Ziel:
log_component="DoS Attack" sauber decodieren und später in Regeln verwenden.


2. Der wichtigste Punkt: Parent-Decoder (SFW)

❗ Häufigster Fehler

Es werden nur Child-Decoder definiert, aber:

  • kein sauberer Parent-Decoder
  • oder ein Parent-Decoder, der den Log nicht zuverlässig matched

Korrektes Grundgerüst

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

📘 Decoder-Hierarchie:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html


3. Warum log_component="DoS Attack" tricky ist

Problem 1: Leerzeichen im Wert

Viele Decoder verwenden:

<regex>log_component="(\S+)"</regex>

❌ Das funktioniert nicht, weil:

  • \S+ keine Leerzeichen matcht
  • "DoS Attack" enthält ein Leerzeichen

✅ Korrekte Regex

<regex>log_component="([^"]+)"</regex>

➡️ Matcht alles bis zum nächsten Anführungszeichen

📘 Regex-Referenz:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html


4. Warum Felder manchmal „nicht auftauchen“

Wichtige Wazuh-Grundregel

Ein Decoder erzeugt nur dann ein Feld, wenn das Feld im Log existiert.

Das bedeutet:

  • Decoder ≠ Garantie für Feld
  • Logtest zeigt nur tatsächlich gematchte Felder

Wenn z. B. ein Log kein src_zone_type enthält, dann:

  • wird es nicht decodiert
  • erscheint nicht im Logtest
  • erscheint nicht im Dashboard

➡️ Das ist kein Fehler.


5. Warum wazuh-logtest manchmal „zu wenig zeigt“

wazuh-logtest:

  • zeigt nur den getesteten Log
  • zeigt keine archivierten Rohlogs
  • zeigt keine Felder ohne Match

Debug-Empfehlung: Archive Logs aktivieren (temporär)

<ossec_config>
  <global>
    <logall_json>yes</logall_json>
  </global>
</ossec_config>

Danach:

systemctl restart wazuh-manager

Logs prüfen:

/var/ossec/logs/archives/archives.json

⚠️ Achtung: Sehr hoher Speicherverbrauch
Nach Debugging wieder deaktivieren!

📘 Event Logging:
https://documentation.wazuh.com/current/user-manual/manager/event-logging.html


6. Best Practices für große Sophos-Decoder-Sets

✅ 1. Ein Decoder pro Feld – okay, aber sauber

Sophos-Logs sind Key-Value-Logs, daher ist diese Strategie korrekt:

<regex>src_ip="(\S+)"</regex>
<regex>dst_ip="(\S+)"</regex>

Aber:

  • nur Felder definieren, die wirklich benötigt werden
  • sonst steigt CPU-Last unnötig

✅ 2. Keine Duplikate

Im Thread waren zwei Decoder für log_component vorhanden:

<regex>log_component="(\S+)"</regex>      ❌
<regex>log_component="([^"]+)"</regex>    ✅

➡️ Immer nur eine korrekte Variante behalten.


✅ 3. Felder mit Leerzeichen immer [^"]+

Gilt u. a. für:

  • log_component
  • log_subtype
  • fw_rule_type
  • ether_type

7. Typische Sophos-DoS-Regel (Beispiel)

<group name="sophos,dos,firewall">
  <rule id="120001" level="10">
    <if_matched_sid>SFW</if_matched_sid>
    <field name="log_component">DoS Attack</field>
    <field name="log_subtype">Denied</field>
    <description>Sophos Firewall: DoS attack blocked from $(src_ip) to $(dst_ip)</description>
  </rule>
</group>

📘 Rules-Syntax:
https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html


8. Warum das Problem im Thread „eigentlich keines war“

Die finale Einschätzung von Wazuh-Support war korrekt:

„Your decoder is working fine. The fields are not present in every log.“

➡️ Decoder funktionieren
➡️ Logs enthalten nicht immer alle Felder
➡️ Wazuh verhält sich korrekt


9. Weiterführende Quellen

Wazuh

Sophos


Fazit

❝ Wenn ein Feld nicht erscheint, heißt das nicht,
dass der Decoder falsch ist –
sondern meist, dass der Log es nicht enthält. ❞

Sophos-Logs sind inkonsistent je nach Event-Typ, besonders bei:

  • DoS
  • Heartbeat
  • Network Flood Protection

Mit sauberem Parent-Decoder, korrekter Regex ([^"]+)
und gezieltem Debugging sind sie jedoch sehr gut in Wazuh integrierbar.

https://wazuh.slack.com/archives/C0A933R8E/p1766216316132299