Sophos Firewall (SFW) Logs in Wazuh

Aus maxTechCorner

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

  • Sophos Firewall Log Guidehttps://docs.sophos.com/nsg/sophos-firewall/19.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/LogsReports/Logs/

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

Quelle

Dieser Artikel stammt aus dem Wazuh-Blog von m.a.x. it (veröffentlicht am 20. März 2026).

Unterstützung von m.a.x. it

Bei Einführung, Betrieb und Feintuning von Wazuh (SIEM) unterstützt Sie m.a.x. it mit SIEM-Services auf Open-Source-Basis.


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=Sophos_Firewall_(SFW)_Logs_in_Wazuh&oldid=2873“