18. Wazuh OPNSense Rule
PT FPT Metrodata Indonesia (FMI) is a joint venture between FPT IS and Metrodata Electronics, focusing on providing Cybersecurity-as-a-Service—including SOC, managed security, professional services, consulting, and threat intelligence—to support Indonesia’s rapidly growing digital economy. FMI is expanding into AI and cloud GPU services to deliver innovative protection and solutions for enterprises. Learn more at https://fmisec.com.
OPNsense Logs in Wazuh: Matching pfSense Rules and the Need for Custom Parsing
1. Problem Summary
When forwarding logs from OPNsense to Wazuh, many entries are matched by existing decoders/rules (mostly written for pfSense/pf), leading to:
Wazuh assigning the group or program_name according to the pfSense ruleset (e.g., displayed as pfSense).
Alerts being less detailed, or incorrectly labeled as pfSense instead of OPNsense.
Specific OPNsense fields (e.g., log prefixes, JSON structure, Suricata/eve fields) not being parsed → alerts show up empty or only stored in archives instead of being displayed on dashboards.
Therefore, a dedicated decoder + ruleset for OPNsense is required, or at minimum, OPNsense logs should be separated (using prematch) so that default pfSense/Suricata decoders do not mistakenly apply.
2. Technical Root Cause
Both OPNsense and pfSense use pf (packet filter), so filter logs share a similar structure (e.g., filterlog:). However, OPNsense often adds prefixes or outputs JSON (via plugins like Suricata), with slight differences (e.g., iface, rule, proto fields). As a result, the pfSense decoder may overmatch or miss fields.
Wazuh already includes decoders/rules for pf/pfSense, so if logs are not explicitly distinguished beforehand, they are parsed under the pfSense ruleset → the displayed source name/group is shown as pfSense.
Suricata/eve.json logs exported from OPNsense may include prefixes (e.g., OPNSENSE:) or wrappers, which require a dedicated decoder to strip the prefix and properly decode the JSON content.
Conclusion: OPNsense logs must be explicitly distinguished using a prematch or new decoders starting with opnsense- to ensure rules are applied correctly.
3. Example Logs (Real-World Samples)
Below are common log types from OPNsense — real samples from the system should be collected for building decoders/rules:
<134>1 2025-09-30T12:15:03Z fw01.opnsense.local filterlog[982]: 1000000103,,,1000000103,em0,match,block,in,4,0x0,,64,33451,0,none,6,tcp,60,192.168.1.10,93.184.216.34,12345,80,0,S,153246246,0,,mss;nop;wscale;sackOK;TS
OPNSENSE: {"timestamp":"2025-09-30T12:34:56.123456Z","flow_id":123456789,"in_iface":"wan","event_type":"alert","src_ip":"192.168.1.10","dest_ip":"8.8.8.8","alert":{"action":"blocked","signature":"ET MALWARE SomeMalware","severity":2,"sid":2012345}}
Sep 30 12:35:01 opnsense1 sshd[12345]: Accepted password for admin from 10.0.0.5 port 50234 ssh2
The issue is that when writing a new decoder for OPNsense, the regex patterns may overlap with the existing pfSense decoders, causing conflicts and incorrect parsing.
Therefore, it is necessary to create a separate decoder with a rule name that precedes pfSense, ensuring that the OPNsense logs are matched first and parsed correctly without being overridden by the existing pfSense rules.
Wazuh/Wazuh-Rule-Custom/OPNSense/opnsense_rules.xml
After using this decoder, you can then proceed to write custom rules and parse other types of OPNsense logs accordingly.
