Request for Sophos XGS Firewall Decoders, Rules, and Log Settings

[Ashish Patil]

Hello Wazuh Team,

I am working on integrating a Sophos XGS Firewall with Wazuh 4.14.x and am currently developing a production-ready ruleset. I have created custom decoders and rules, but I'm still uncertain whether my approach follows best practices.

If anyone has already built a mature or production-tested Sophos XGS ruleset, I would greatly appreciate it if you could share your decoders, rules, or any guidance.

Environment

• Wazuh Version: 4.14.x
• Firewall: Sophos XGS 2100
• SFOS Version: 22.0.0 MR1
• Log Format: Syslog (Key-Value)
• Log Source: Sophos Firewall → Wazuh Manager (UDP Syslog)

Currently Enabled Log Categories

• Firewall Rules
• DoS Attack
• IP Spoof Prevention
• SSL VPN
• Protected Application Server
• IPS (Anomaly, Signatures)
• Antivirus (HTTP, HTTPS, SMTP, SMTPS)
• Zero-Day Protection
• Web Filter
• Application Filter
• Admin, Authentication, and System Events
• Active Threat Response
• Web Server Protection

I have reviewed the official Wazuh ruleset but could not find dedicated Sophos XGS firewall decoders or detection rules. If there is an official or community-maintained ruleset available, or if you've built one yourself, could you please share it?

Additionally, if you recommend any specific Sophos log settings or categories that should be enabled or disabled for effective detection while minimizing noise, I'd be grateful for your recommendations.

If anyone has already built a mature Sophos XGS integration for Wazuh and is willing to share the decoders, rules, dashboards, or best practices, I would greatly appreciate it.

Thank you very much for your time and support.

Please go through my custom decoders and ruleset for Sophos Firewall XGS 2100

Best regards,

Ashish Patil
Cyber Security Analyst 

[victor....@wazuh.com]

Hi Ashish,

There are some different issues in your ruleset that will need to be fixed

1. Child decoders need to share one name (“sibling decoders”)

Every child decoder has a unique name (sophose_fw_srcip, sophose_fw_rule_name, etc.) under the same <parent>. Wazuh only applies one matching child per parent, not all of them:

$ wazuh-logtest
device_name=“SFW-XGS2100” … log_component=“Firewall Rule” log_subtype=“Allowed” … src_ip=“192.168.1.100” dst_ip=“8.8.8.8” protocol=“UDP”

**Phase 2: Completed decoding.
name: ‘sophose_firewall’
log_component: ‘Firewall Rule’

Only log_component comes out of a log with six extractable fields present. Fix: give every child decoder the same name as the parent (Wazuh’s documented “sibling decoders” pattern: https://documentation.wazuh.com/current/user-manual/ruleset/decoders/sibling-decoders.html), keeping each one’s own <regex>/<order>. Identical log line after the fix:

**Phase 2: Completed decoding.
name: ‘sophose_firewall’
dstip: ‘8.8.8.8’
log_component: ‘Firewall Rule’
log_subtype: ‘Allowed’
log_type: ‘Firewall’
protocol: ‘UDP’
srcip: ‘192.168.1.100’

2. Double-check your decoder regexes against your device’s actual log output: quoting and field names can silently mismatch

I don’t have a captured log from your specific XGS 2100/SFOS build, so I can’t verify this against your real traffic. But it’s worth flagging as potentially a serious, hard-to-notice issue, because this class of bug produces no error at all, just silently empty fields.

Your decoder assumes several values are unquoted numbers, e.g.:

<regex type="pcre2">src_port=(\d+)</regex>

<regex type="pcre2">duration=(\d+)</regex>

If your device actually quotes these (src_port="52344" instead of src_port=52344), the regex silently never matches, no warning, no error, the field is just absent from Phase 2 output. Same risk applies to field naming: if your firmware/log-format version sends rule_id/rule_name/sent_bytes/recv_bytes instead of the fw_rule_id/fw_rule_name/bytes_sent/bytes_received your decoder looks for, those fields will never populate either, and any rule referencing $(fw_rule_name) etc. will render empty.

If you're able to, could you share a handful of real, raw log lines straight from your XGS 2100 (one per log category you have enabled: Firewall, IPS, AV, Web Filter, etc., with any sensitive IPs/hostnames redacted)? That would let us actually confirm whether this is a real problem in your deployment rather than a hypothetical one, and check it properly instead of guessing at the format. In the meantime, you can check it yourself with wazuh-logtest: feed it your own captured lines and confirm every field you expect actually shows up in Phase 2 output.

3. Your rule IDs collide with Wazuh's built-in ruleset — and this alone blocks everything, even after fixing #1 and #2

id="500000", id="500001", id="500002" are already used by Wazuh's stock 0335-unbound_rules.xml:

** Wazuh-Logtest: WARNING: (7612): Rule ID '500000' is duplicated. Only the first occurrence will be considered.

** Wazuh-Logtest: WARNING: (7612): Rule ID '500001' is duplicated. Only the first occurrence will be considered.

** Wazuh-Logtest: WARNING: (7612): Rule ID '500002' is duplicated. Only the first occurrence will be considered.

The built-in Unbound rule wins the conflict, so your base rule (<decoded_as>sophose_firewall</decoded_as>) never runs. I proved this compounds with #1/#2: even with decoding fully fixed, the log still fell through to Wazuh's generic catch-all:

**Phase 3: Completed filtering (rules).

     id: '1002'

     level: '2'

     description: 'Unknown problem somewhere in the system.'

     groups: '['syslog', 'errors']'

Official Wazuh docs reserve 0–99999 for the built-in ruleset and recommend 100000–120000 for custom rules (https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html). I checked your entire 500000–500031 range against the default ruleset — only 500000–500002 currently collide, but that's not guaranteed to stay true in future Wazuh releases. After renumbering into 100000–100031, the same log correctly produces:

**Phase 3: Completed filtering (rules).

     id: '100002'

     level: '5'

     description: 'Sophos Firewall: Traffic blocked from 203.0.113.45 to 10.0.0.5 - Rule: Block-Inbound-SSH'

     groups: '['sophos', ' firewall', ' network', ' inno_soc_fw', 'firewall_drop']'

**Alert to be generated.

4. Brute-force detection (rule 500008) can never fire: <same_user/> doesn't see your user_name field

Rule 500008 escalates repeated failed logins using <same_user/> + frequency="5" timeframe="120", chained off rule 500007. I fed 5 identical failed-login events (same user, same source IP) through wazuh-logtest:

**Phase 3: Completed filtering (rules).

     id: '500007'

     firedtimes: '5'

Rule 500007 fired every time, but the 500008 escalation never appeared. <same_user/> compares Wazuh's reserved user field (srcuser/dstuser), not your decoder's custom user_name field. Since nothing populates the reserved field, the correlation permanently fails to find a match. I confirmed the fix directly: pointing the decoder's user field at the reserved dstuser slot instead of user_name made the exact same escalation fire correctly on the 2nd matching event. As shipped, this rule is dead regardless of real-world brute-force activity.

5. The high-risk-application rule (500013) silently never fires

<field name="app_risk">^[4-5]$</field>

No type="pcre2". I tested this exact regex on app_risk=5, and it did not fire. Adding type="pcre2" to the identical regex fixed it immediately:

**Phase 3: Completed filtering (rules).

     id: '100014'

     description: 'WITH-PCRE2-CHARCLASS: TikTok'

This is specific to character-class regex ([4-5]), your other untyped <field> rules using plain anchored strings (^Antivirus$, ^System$) already work fine without type="pcre2", so this only needs fixing on this one rule (and anywhere else you use a character class without declaring the type).

Everything else, the MITRE tags, the other frequency/if_matched_sid correlation chains, the <match>-based rules (DoS, DNS tunneling, SSL failures), loaded and matched correctly once fed properly decoded data. The structure and logic of the ruleset is solid; these six issues are what's currently keeping it from producing real alerts against your actual device.

Fix in this order: #1 and #2 first (nothing decodes correctly until then), #3 next (nothing evaluates correctly until then either), then #4–#6. Validate each change with wazuh-logtest against your own real log samples that's how all six of these were actually found, not by reading the XML alone.

Let me know if you have further doubts

[Ashish Patil]

Hello Victor,

Thank you for the detailed review and for identifying the issues in my current decoder and ruleset. Your findings are very helpful, especially regarding the sibling decoder structure, custom rule ID range, reserved user fields, and PCRE2 requirement.

I have now captured the actual raw logs directly from my Sophos XGS 2100 and am sharing representative samples below so that the decoder behavior can be validated against the real log format generated by my appliance.

Environment:

• Wazuh: 4.14.7

• Sophos Firewall: XGS 2100

• SFOS: 22.0.0 MR1

• Log transport: Syslog/UDP

• Log format: Key-value

• Sophos → Wazuh Manager

Sample Firewall log:

2026-08-07T06:29:53.923314+00:00 154-86-109-203.static.youbroadband.in device_name="X21025QFK3DG744" timestamp="2026-08-07T11:59:53+0530" device_model="XGS2100" device_serial_id="X21025QFK3DG744" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="11" fw_rule_name="Limited Access 26-100" fw_rule_section="Local rule" nat_rule_id="7" nat_rule_name="Limited Access 26-100" fw_rule_type="USER" sdwan_profile_id_request=1 sdwan_profile_name_request="Load-Balance" gw_id_request=2 gw_name_request="UbroadBand-Gateway" sdwan_route_id_request=2 sdwan_route_name_request="Load Balance" web_policy_id=15 app_filter_policy_id=1 ether_type="Unknown (0x0000)" in_interface="Port5" out_interface="Port3" src_mac="30:F6:EF:CA:78:17" dst_mac="A8:91:62:18:8E:65" src_ip="192.168.1.71" src_country="R1" dst_ip="162.247.241.14" dst_country="USA" protocol="TCP" src_port=51190 dst_port=443 src_trans_ip="203.109.86.154" src_zone_type="LAN" src_zone="LAN" dst_zone_type="WAN" dst_zone="WAN" con_event="Start" con_id="533606492" hb_status="No Heartbeat" app_resolved_by="Signature" app_is_cloud="FALSE" qualifier="New" in_display_interface="Port5" out_display_interface="UbroadBand" log_occurrence="1"

Sample Content Filtering / HTTP log:

2026-08-07T06:29:53.938741+00:00 154-86-109-203.static.youbroadband.in device_name="X21025QFK3DG744" timestamp="2026-08-07T11:59:53+0530" device_model="XGS2100" device_serial_id="X21025QFK3DG744" log_id="050901616001" log_type="Content Filtering" log_component="HTTP" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="11" fw_rule_name="Limited Access 26-100" fw_rule_section="Local rule" web_policy_id=15 http_category="Information Technology" http_category_type="Acceptable" url="http://c.pki.goog/r/r1.crl" src_ip="192.168.1.71" dst_ip="192.178.174.94" protocol="TCP" src_port=51189 dst_port=80 bytes_sent=200 bytes_received=223 domain="c.pki.goog" http_user_agent="Microsoft-CryptoAPI/10.0" http_status="304" transaction_id="1344c687-f407-4801-affa-97eb1d607da8" download_file_name="r1.crl" con_id=3912932324 app_is_cloud="FALSE" used_quota="0" src_zone_type="LAN" src_zone="LAN" dst_zone_type="WAN" dst_zone="WAN" src_country="R1" dst_country="USA"

Based on these real logs, could you please advise whether Wazuh has an established or recommended enterprise architecture for Sophos XGS/SFOS integrations?

More specifically, I would appreciate your guidance on the following:

1. Is there an existing Wazuh-supported or community-maintained Sophos XGS decoder/ruleset that is considered production-tested?

2. If there is no official ruleset, could you recommend the best enterprise approach for structuring the custom decoder and ruleset — for example, whether Firewall, IPS, Antivirus, Web Filtering, VPN, Authentication, System, and other Sophos categories should use separate decoder/rule layers?

3. Based on the raw logs above, could you confirm the recommended field mappings and regex approach, particularly for fields such as src_ip, dst_ip, src_port, dst_port, fw_rule_id, fw_rule_name, bytes_sent, bytes_received, user-related fields, and the quoted/unquoted values?

4. Could you recommend an enterprise-grade rule ID namespace and ruleset organization that will remain safe across future Wazuh upgrades?

5. For correlation rules such as brute-force, DoS, scanning, DNS tunneling, suspicious applications, VPN failures, and repeated security events, are there any Wazuh best practices you recommend for avoiding false positives and excessive alert volume?

6. Would it be possible for you or the Wazuh team to provide a reference Sophos XGS ruleset/decoder architecture, even if it is only a recommended template rather than an officially supported ruleset?

My objective is not simply to make the current logs decode successfully. I want to build a maintainable, production-ready Sophos XGS integration suitable for an enterprise SOC, with reliable field extraction, meaningful detection coverage, proper correlation, MITRE ATT&CK mapping, and controlled alert noise.

I can also provide additional raw samples for IPS, Antivirus, Web Filtering, Authentication, SSL VPN, DoS, System, and other Sophos event categories if those would help validate the decoder design.

Thank you again for taking the time to review my integration. Your feedback has already helped identify several issues that were not obvious from the XML alone.

Best regards,

Ashish Patil
Cyber Security Analyst

Innover Systems Pvt Ltd

[victor....@wazuh.com]

Thanks for capturing real logs. This actually overturns part of my earlier caution, in a good way. Let me correct the record first, then answer your architecture questions.

Correction: issue #2 doesn't apply (verified against your real logs)

My earlier warning about quoting/field-name mismatches was speculative (built from a hypothetical sample, not your real device), and I explicitly flagged it as unverified. Now that I have your real logs, I tested both against the sibling-decoder-fixed version of your original decoder, with none of my previously-guessed regex changes applied, and everything decodes correctly as originally written, so: `fw_rule_id`, `fw_rule_name`, `src_port`, `dst_port`, `bytes_sent`, `bytes_received` are all correctly named and correctly quoted/unquoted exactly as you originally wrote them. No changes needed there; disregard my earlier guess. The sibling-decoder fix (#1 below) plus fixing the rule-ID collision (#3 below) are still required and still the two blocking issues; everything else in that correction is resolved.

However, your real logs also show several fields you're not decoding yet that could be worth adding depending on what detections you want: `device_model`/`device_serial_id` (useful if you ever have more than one XGS reporting to the same manager), `nat_rule_id`/`nat_rule_name`, `web_policy_id`/`app_filter_policy_id`, `src_zone`/`dst_zone` (zone names, distinct from the zone *type* you already capture), and on the Content Filtering side `http_category_type`, `http_user_agent`, `download_file_name` (useful for flagging suspicious downloads by filename/extension).

Is there an official or established community Sophos XGS ruleset?

Wazuh does ship official Sophos decoders/rules out of the box, but neither one covers what you're doing:
- 0300-sophos_decoders.xml / 0415-sophos_rules.xml cover Sophos Anti-Virus (the endpoint AV product, unrelated to the firewall).
- 0510-sophos_fw_decoders.xml / 0705-sophos_fw_rules.xml cover the Sophos XG210 Firewall, a predecessor to what you're building, worth knowing about because it uses the exact same "sibling decoder" technique (every child decoder literally named `sophos-fw`) that fixes your issue #1

I tested that official decoder directly against your real XGS 2100 log, and it does not match at all:
```
**Phase 2: Completed decoding.
No decoder matched.
```
It's designed for the older XG210 log layout. Your SFOS 22.0.0/XGS 2100 output uses a different schema entirely (`device_name="..." timestamp="..." device_model="XGS2100"...`, no separate `date=`/`time=`/`timezone=` fields, several fields like `fw_rule_section`/`nat_rule_id`/`sdwan_*` that don't exist in the old format at all). So: official support exists for the old XG210 line, not for current XGS/SFOS.

There are also some community-built rulesets for Sophos firewalls floating around outside the official ruleset. Worth searching the Wazuh community Slack and GitHub yourself before building everything further from scratch. Whatever you find, validate it against your own real logs with `wazuh-logtest` the same way we've been doing here, rather than trusting it as-is.

Should each Sophos category (Firewall, IPS, AV, Web Filter, VPN, Auth, System) get separate decoder/rule layers?

Given what your real logs show, all Sophos log categories share one common KV envelope (device_name="..." plus a flat set of `key="value"` pairs), so one shared base decoder (matching on `device_name="`) with sibling field-decoders covering the union of fields across all categories works well, and is simpler to maintain than a separate top-level decoder per category. Where I'd split things is on the rules side, not the decoder side: keep one decoder file, but organize rules into separate files per category (`local_rules_sophos_firewall.xml`, `local_rules_sophos_ips.xml`, `local_rules_sophos_webfilter.xml`, etc.) rather than one 300-rule monolith: easier to review, easier to disable a whole category, and each file's base rule can key off log_type/log_component to scope itself.

Field mapping/regex approach

Confirmed correct above for `src_ip`, `dst_ip`, `src_port`, `dst_port`, `fw_rule_id`, `fw_rule_name`, `bytes_sent`, `bytes_received`. I can't yet confirm the user-related fields (`user_name`, `app_name`, `app_risk`) or `message` since none of those appear in the Firewall/Content Filtering samples. If you can share a real Authentication, VPN, or IPS log, I'll verify those the same way.

Rule ID namespace that survives future Wazuh upgrades

Stick to the officially reserved 100000–120000 block (https://documentation.wazuh.com/current/user-manual/ruleset/rules/custom.html), and within that, carve out sub-ranges per category so you don't have to renumber later as it grows, e.g.:
```
100000-100099  Firewall (base + allow/deny/recon)
100100-100199  IPS / ATP
100200-100299  Antivirus / Zero-Day
100300-100399  Web Filter / Content Filtering
100400-100499  VPN / Authentication
100500-100599  System / Admin / Config audit
```
Before assigning any ID, grep the shipped ruleset to confirm it's actually free: `grep -r 'id="100050"' /var/ossec/ruleset/rules/`.

Avoiding false positives / alert volume on correlation rules

A few concrete practices:

• Set "Allowed" traffic rules to a low level (2–3) purely for search/audit visibility, not alerting: don't let normal traffic generate real alerts.

• Tune `frequency`/`timeframe` against your own real traffic baseline before going to production: run a dry period, look at how often each base rule actually fires, then set thresholds relative to that instead of guessing round numbers.

• Use `<if_matched_sid>` escalation chains (as you're already doing for brute-force/port-scan) so you alert on the pattern, not the individual event; it just needs the reserved-field fix from before to actually work.

• Reduce noise at the source too, per your original question: you don't need everything enabled at the Sophos side; categories you're not actively hunting in (e.g., verbose Allow logging) can be trimmed on the device itself rather than filtered downstream.

Would Wazuh provide a reference architecture/template?

 I can keep helping you put one together as you share more log samples. Send over those additional samples whenever you have them, and we'll help you with your custom ruleset

[Ashish Patil]

Hi Victor,

At my office i have Sophos XGS2100/SFOS22.0 MR1→Wazuh4.14.x, 

could you provide the recommended end-to-end setup: Syslog vs rsyslog, UDP514 vs another port, Wazuh listener/localfile, log path/permissions, decoders/rules, and Discover verification?

Thank You 

Regards, 

Ashish Patil