OPNsense Suricata: Rule Tuning Without False-Positive Floods

Suricata in OPNsense is enabled with two clicks — and that is exactly the problem. Flipping the Emerging-Threats-Open ruleset live without curation generates five-digit alert numbers in a typical SMB network within hours. After a week nobody looks at the log console anymore, and the expensive IDS sensor is essentially blind.

Rule tuning is the decisive discipline that turns Suricata into a productive detection tool. In this article we show how to systematically suppress noise, close real detection gaps and hand relevant events cleanly to a SIEM using OPNsense 25.7 and Suricata 7.x. The focus is deliberately on craftsmanship, not on miracle configurations.

Ruleset selection: ET/Open vs. commercial sources

The Suricata integration in OPNsense ships with a selection of pre-defined rule sources. Practically relevant:

Ruleset	Rules (approx.)	License	Typical noise class
ET Open	60,000+	free, GPLv2	high, many generic signatures
ET Pro (Proofpoint)	90,000+	commercial	medium, curated, IOC feed included
Abuse.ch (SSLBL, Feodo)	few thousand	free	low, very precise
OPNsense-native	few hundred	free	low

Our recommendation for SMB environments: ET Open as the base, complemented by the Abuse.ch feeds for high-quality C2 detection. ET Pro only pays off once you have a dedicated SOC or an MSSP that actually works the alerts. Buying ET Pro without staffing means more rules, but not more security.

The ruleset update strategy matters: Suricata should not reload every category every day, but by class. Categories like emerging-info or emerging-policy are irrelevant for most networks and should be deactivated completely — not via suppression, but by deselecting the category in the downloader. That saves rule-compile time and RAM.

Deactivate categories instead of suppressing rules

The first tuning step happens under Services > Intrusion Detection > Administration > Download. Here you disable whole rule categories that have no relevance for your network. In a typical SMB network without gaming, without chat servers and without P2P these are:

• emerging-chat (IRC, ICQ, legacy XMPP)
• emerging-games
• emerging-p2p
• emerging-info (pure information events, no threat)
• emerging-policy (internal policy violations without security context)
• emerging-icmp_info

Active should stay: emerging-malware, emerging-exploit, emerging-trojan, emerging-current_events, emerging-mobile_malware and the Abuse.ch feeds. For webserver DMZs additionally emerging-web_server and emerging-web_specific_apps.

After the category cleanup you typically end up with 8,000 to 15,000 active signatures — a range that runs cleanly on modern firewall appliances with four cores and 8 GB RAM in IPS mode.

Threshold and suppression: the core discipline

Even after category cleanup, signatures remain that fire false-positive in your own network. Classic candidates:

• SNMP polling by your own monitoring
• Legitimate update connections to unusual CDN ranges
• VoIP traffic that SIP signatures interpret as scans
• Internal backup jobs recognised as data exfiltration

Two mechanisms are available for these cases: threshold (limit frequency) and suppression (mute the rule completely for defined IPs).

A look at the generated suricata.yaml or the OPNsense configuration under /usr/local/etc/suricata/ shows the syntax. In OPNsense you maintain these entries conveniently via Services > Intrusion Detection > Administration > Schedule > User defined. A typical example of a threshold configuration:

# Threshold for SIP scan signature, only alert if more than 20 events / 60s
threshold gen_id 1, sig_id 2019876, type threshold, \
  track by_src, count 20, seconds 60

# Suppression: backup server may export large data volumes unrestricted
suppress gen_id 1, sig_id 2013504, track by_src, ip 10.10.20.15

# Suppression per network: monitoring segment is exempt from SNMP signatures
suppress gen_id 1, sig_id 2101411, track by_src, ip 10.10.99.0/24

Important: suppression is not “delete the rule”. The signature remains active, but no event is generated for the named source or destination IPs. Detection stays intact for the rest of the network.

Rule of thumb for the initial rollout: start in pure IDS mode (alert only), collect events for seven days, classify the top 30 rules by frequency and decide per rule: legitimate detection, threshold, or suppression. Only then switch to IPS mode.

Custom rules: targeted IOC detection

The actual value of Suricata comes from customer-specific rules. If you know from a CERT bulletin, a threat intel feed or your own incident that certain IP addresses, domains or JA3 fingerprints are compromised, that information belongs in a local signature file.

In OPNsense you create your own rules under Services > Intrusion Detection > Administration > User defined. An example of an IOC rule that reports outbound connections to a known C2 infrastructure:

alert tcp $HOME_NET any -> [185.220.101.0/24,45.132.192.15] any \
  (msg:"DATAZONE-IOC C2 Outbound Connection"; \
   flow:established,to_server; \
   classtype:trojan-activity; \
   priority:1; \
   sid:9000101; rev:1;)

alert dns $HOME_NET any -> any any \
  (msg:"DATAZONE-IOC Suspicious Domain Lookup"; \
   dns.query; content:"malicious-c2.example"; nocase; \
   sid:9000102; rev:1;)

alert tls $HOME_NET any -> $EXTERNAL_NET any \
  (msg:"DATAZONE-IOC Known Bad JA3 Fingerprint"; \
   ja3.hash; content:"a0e9f5d64349fb13191bc781f81f42e1"; \
   sid:9000103; rev:1;)

The SID range 9000000-9999999 is reserved by convention for local rules — so it does not collide with ET signatures. Use a consistent prefix in the msg field (in the example “DATAZONE-IOC”) so your SIEM can automatically filter your own rules.

For dynamic IOC lists we recommend a cron job that periodically generates a .rules file from MISP, Abuse.ch or an internal feed and reloads it via configctl ids reload into Suricata. Detection stays current without restarting the firewall completely.

SIEM integration: syslog and EVE-JSON

Alerts that only sit in the OPNsense GUI never get worked. For productive detection Suricata must forward its events to a central system. OPNsense offers two paths for this:

Syslog export via System > Settings > Logging > Remote. Sufficient for small environments, but alerts arrive as unstructured text — parsing in the SIEM is tedious.

EVE-JSON log is the better path. Suricata already writes structured JSON events with full context (flow, HTTP, DNS, TLS, files) to /var/log/suricata/eve.json. A Filebeat or Vector agent on OPNsense (or a log shipper on a separate collector that picks up the file via NFS/syslog) transports this directly into Elastic, Wazuh, Graylog or Splunk.

An example event from eve.json:

{
  "timestamp":"2026-08-05T10:23:41.123456+0200",
  "event_type":"alert",
  "src_ip":"10.10.20.15","src_port":52341,
  "dest_ip":"185.220.101.44","dest_port":443,
  "proto":"TCP",
  "alert":{
    "signature_id":9000101,
    "signature":"DATAZONE-IOC C2 Outbound Connection",
    "category":"A Network Trojan was detected",
    "severity":1
  },
  "flow":{"pkts_toserver":8,"bytes_toserver":1204}
}

Such an event can be enriched with asset database and user context immediately in the SIEM. In our customer projects we typically see: after clean tuning, the relevant event volume settles at 20 to 200 alerts per day for a 100-client network — a volume an IT team can actually review as part of normal operations.

Performance and IPS activation

Suricata in OPNsense can run as pure IDS (alert only) or active IPS (packet drop via netmap). Switching to IPS mode deserves its own maintenance window — a badly tuned rule in blocking mode can interrupt legitimate traffic completely.

Recommended procedure: at least two weeks IDS with clean tuning, then IPS activation category by category. emerging-malware and the Abuse.ch feeds are usually unproblematic as blockers. Rules from emerging-scan or emerging-web_specific_apps should only go active after prolonged observation.

For hardware sizing: per gigabit of inspected bandwidth we conservatively budget one CPU core (modern x86, from Xeon-D or AMD EPYC Embedded upwards). For smaller environments up to 250 Mbit/s WAN, Suricata runs comfortably on any current SMB appliance with four cores. Anyone needing 10-GbE inspection must think about network architecture and possibly dedicated sensors.

Conclusion

Suricata in OPNsense is an excellent tool — but only if the ruleset is curated with discipline and the output is wired into a SIEM. Skipping the ruleset catalogue clicks and jumping straight into IPS mode produces either outages or alert fatigue. Both are more expensive than one week of clean tuning at project start.

DATAZONE supports OPNsense and Suricata deployments from ruleset selection through custom IOC integration to SIEM connection (Wazuh, Graylog, Elastic). If you want to grow your firewall from a pure packet filter into a real detection sensor, talk to us: Contact DATAZONE — your IT systems house in Neuburg an der Donau.