Sophos Central reporting syslog format silently produces no Wazuh alerts

Sophos's newer syslog layout slips past Wazuh

A post on dev.to by Dong Nguyen of ATK New Technology documents a quiet operational gap for teams running Sophos Firewall alongside Wazuh: Sophos can send syslog in two layouts, and Wazuh 4.14.7's stock ruleset only decodes the older one. Firewalls emitting the newer "Central reporting" format still deliver their logs, but every line falls through to a low-level generic rule and no alert is ever raised.

Two layouts, one decoder

Sophos's own syslog guide documents both formats, the post notes. The legacy layout, which Sophos calls "Device standard", opens with device=\"SFW\" followed by separate date and time fields. The newer Central reporting layout instead begins with device_name=\"SFW\" and a single ISO-style timestamp, and it replaces the legacy status field, such as "Deny", with a log_subtype field, such as "Denied" or "Allowed".

The stock decoder in ruleset/decoders/0510-sophos_fw_decoders.xml is anchored on the legacy line opening: its prematch expects device=\"…\" followed by date and time keys. A Central reporting line starts differently, so the decoder never fires.

Nguyen tested both on a Wazuh 4.14.7 manager, sending one denied-traffic line in each format over UDP syslog. The legacy line decoded as sophos-fw and matched rule 70021 at level 5, "Traffic Denied". The Central reporting line matched no decoder, fell to the generic rule 1002 at level 2, and produced no alert.

The mismatch compounds: the stock rules key on the decoded status field, and Central reporting lines do not carry status at all. The newer format therefore fails twice over — no decoder match, and no field the existing rules could act on even if decoding were fixed.

Fix 1: send the legacy layout

If the firewall's syslog server settings allow choosing a format, switching to device-standard makes the stock decoder and rules work unchanged. The post cautions that any other consumer of the same log stream should be checked first, in case it expects the new layout.

Fix 2: decode Central reporting yourself

The alternative is custom decoders: a parent decoder anchored on the new line opening, with child decoders using PCRE2 regexes to extract log_type, log_component, log_subtype, the source and destination addresses, ports, protocol and the firewall rule ID. Rules then trigger on log_type "Firewall" with log_subtype "Denied" or "Allowed", alongside a frequency rule that fires on 18 events within 45 seconds from the same source IP.

One detail the post singles out: map the source address to Wazuh's srcip field rather than the src_ip naming the stock decoder uses, because <same_source_ip> and the firewall-drop active response only read srcip.

Measured results on 4.14.7: a single Central reporting denied line went from zero alerts to a level 5 alert with source, destination and destination port extracted; the same line repeated 18 times in quick succession produced 17 level-5 hits followed by the level-10 frequency rule; Sophos's own published Allowed example, previously undecoded, produced a level 3; and a legacy denied line still hit rule 70021 exactly as before. wazuh-analysisd -t reported no warnings.

Caveats

The testing ran on a Wazuh 4.14.7 manager container using UDP syslog and wazuh-logtest; no actual Sophos Firewall was involved. The denied lines were constructed to match the layout, while the Allowed line is Sophos's published example. The custom decoder covers firewall-rule events only — not admin logins, IPS, web filtering or VPN. The post also does not establish which SFOS release made Central reporting the default, nor the exact menu name for the format setting.

Why it matters

This is a silent failure mode. A firewall that ships logs without ever producing alerts looks healthy from a distance: the network path works, Wazuh ingests events, nothing throws an error — detection is simply off. Teams pairing Sophos with Wazuh should check which layout their firewalls actually emit; a single test line in wazuh-logtest settles it. Then either pin the legacy format or deploy decoders for the new one. The srcip detail carries a second lesson: field-name mismatches inside decoders can quietly disable active responses even after the visible alerting appears to be fixed.