imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

2026-09-15T00:00:00Z

Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)

Neue Seite

== 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:

<syntaxhighlight lang="text">
log_component="DoS Attack"
log_subtype="Denied"
</syntaxhighlight>

sorgen häufig für Verwirrung, wenn sie '''nicht wie erwartet im <code>wazuh-logtest</code> 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):

<syntaxhighlight lang="text">
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"
</syntaxhighlight>

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

== 2. Der wichtigste Punkt: Parent-Decoder (<code>SFW</code>) ==

=== ❗ 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 ===

<syntaxhighlight lang="text">
<decoder name="SFW">
<prematch>device_name="SFW"</prematch>
</decoder>
</syntaxhighlight>

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

== 3. Warum <code>log_component="DoS Attack"</code> tricky ist ==

=== Problem 1: Leerzeichen im Wert ===

Viele Decoder verwenden:

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

❌ Das funktioniert '''nicht''', weil:

* <code>\S+</code> '''keine Leerzeichen matcht'''
* <code>"DoS Attack"</code> enthält ein Leerzeichen

=== ✅ Korrekte Regex ===

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

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

📘 Regex-Referenz:
[https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html 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 <code>src_zone_type</code> enthält''', dann:

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

➡️ '''Das ist kein Fehler.'''

== 5. Warum <code>wazuh-logtest</code> manchmal „zu wenig zeigt“ ==

=== <code>wazuh-logtest</code>: ===

* zeigt '''nur den getesteten Log'''
* zeigt '''keine archivierten Rohlogs'''
* zeigt '''keine Felder ohne Match'''

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

<syntaxhighlight lang="text">
<ossec_config>
<global>
<logall_json>yes</logall_json>
</global>
</ossec_config>
</syntaxhighlight>

Danach:

<syntaxhighlight lang="text">
systemctl restart wazuh-manager
</syntaxhighlight>

Logs prüfen:

<syntaxhighlight lang="text">
/var/ossec/logs/archives/archives.json
</syntaxhighlight>

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

📘 Event Logging:
[https://documentation.wazuh.com/current/user-manual/manager/event-logging.html 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:

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

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 <code>log_component</code>''' vorhanden:

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

➡️ Immer nur '''eine korrekte Variante''' behalten.

=== ✅ 3. Felder mit Leerzeichen immer <code>[^"]+</code> ===

Gilt u. a. für:

* <code>log_component</code>
* <code>log_subtype</code>
* <code>fw_rule_type</code>
* <code>ether_type</code>

== 7. Typische Sophos-DoS-Regel (Beispiel) ==

<syntaxhighlight lang="text">
<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>
</syntaxhighlight>

📘 Rules-Syntax:
[https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html 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 ===

* Decoder Syntax[https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html]
* Regex in Decoders[https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html https://documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/regex.html]
* Event Logging[https://documentation.wazuh.com/current/user-manual/manager/event-logging.html https://documentation.wazuh.com/current/user-manual/manager/event-logging.html]

=== 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 (<code>[^"]+</code>)
und gezieltem Debugging sind sie jedoch '''sehr gut in Wazuh integrierbar'''.

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

== Quelle ==
Dieser Artikel stammt aus dem [https://wazuh-blog.max-it.de/sophos-firewall-sfw-logs-in-wazuh/ 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 [https://www.max-it.de/it-services/siem-open-source/ SIEM-Services auf Open-Source-Basis].

{{Uebermax}}
[[Kategorie:Wazuh]]

Sophos Firewall (SFW) Logs in Wazuh - Versionsgeschichte

imported>TechCorner-Redaktion: Import aus Wazuh-Blog (m.a.x. it, eigenes Copyright)