OPNsense Forum

Suricata: ET Open/abuse.ch ruleset produces zero alerts despite correct config — possible rule-files template issue (OPNsense 26.1.10)

Disclaimer: I'm new to OPNsense/Suricata and security topics in general, and worked through this with AI assistance (asking it to help interpret logs and summarize findings here). Apologies if I've made any beginner mistakes along the way — happy to be corrected on any of this.

Environment:

• OPNsense 26.1.10
• Suricata 8.0.5
• Capture mode: PCAP live mode (IDS)
• Pattern matcher: Aho-Corasick ("Ken Steele" variant)
• Interfaces: LAN + WAN, promiscuous mode enabled
• Rulesets enabled: abuse.ch/ThreatFox, abuse.ch/URLhaus, ET open/botcc, ET open/botcc.portgrouped, ET open/emerging-attack_response, ET open/emerging-exploit, ET open/emerging-exploit_kit, ET open/emerging-scan, ET open/emerging-malware, ET open/emerging-shellcode, ET open/emerging-web_server

Symptom

After enabling these rulesets and creating a Policy (action: Alert) covering all of them, I got zero alerts, from nmap SYN scans against both the firewall and the server behind it, and from a plain-HTTP EICAR test-file download. Traffic capture itself seemed to be working fine — eve.json showed correct flow logging for all this traffic — so it looked like a rule-matching problem specifically, not a capture problem.

What I found

Checked Suricata's startup log and saw:
1 rule files specified, but no rules were loaded!
with a YAML warning on every start:
Info: conf-yaml-loader: Configuration node 'rule-files' redefined.
Looking at the generated suricata.yaml:
default-rule-path: /usr/local/etc/suricata/opnsense.rules
rule-files:
  - suricata.rules
...
include:
  - installed_rules.yaml
suricata.rules doesn't exist anywhere on disk. The actual rules are correctly staged as 16 separate per-category files and referenced via installed_rules.yaml's own rule-files: list (included via include:). It looks like these two rule-files: entries collide, and the dead reference wins, so nothing loads.

Tracing further, this dead reference seems to come from OPNsense's own template:
grep -r "suricata.rules" /usr/local/opnsense/service/templates/
/usr/local/opnsense/service/templates/OPNsense/IDS/suricata.yaml:  - suricata.rules
So it looks like the template may not have been updated to match how the rule-compilation backend (installRules.py) actually generates rules now (per-category files + manifest, not one combined file). I could be wrong about this being the root cause, but it's what the evidence pointed to.

What did work

To check whether Suricata itself was capable of alerting at all (vs. specifically the bulk ruleset), I manually staged a simple custom rule outside the normal Download/Policy flow based on the blog here (https://medium.com/@hariharanss/exploring-ids-ips-network-security-custom-rules-with-opnsense-suricata-5406947d2151):

echo 'alert tcp any any -> 192.168.10.10 any (msg:"Possible Nmap SYN scan detected"; flow:stateless; flags:S; threshold:type both, track by_src, count 5, seconds 1; classtype:attempted-recon; sid:9000001; rev:1;)' > /usr/local/etc/suricata/opnsense.rules/custom-nmap-test.rules

sed -i '' 's/rule-files:/rule-files:\n - custom-nmap-test.rules/' /usr/local/etc/suricata/installed_rules.yaml

pkill -f suricata
sleep 3
service suricata start
(sed -i '' is FreeBSD syntax — the empty string is required there, not a typo.)

This rule fired correctly on the first test (nmap -sS), with a proper alert showing correct source/dest/port/interface. So the engine itself seems fine — the issue seems confined to the bulk Download/Policy ruleset specifically.

Questions

• Is this a known mismatch between the template and the current rule-compilation backend?
• Is there a supported way to fix rule-files so it survives the next rule update/regen?
• Has anyone else hit this on 26.1.10?

I apologise in advance if I'm slow to provide more logs/diagnostics. I'm on a deadline and need to move on to other security topics now.