"
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:
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:
with a YAML warning on every start:
Looking at the generated suricata.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:
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):
(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
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.
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:
Code Select
1 rule files specified, but no rules were loaded!with a YAML warning on every start:
Code Select
Info: conf-yaml-loader: Configuration node 'rule-files' redefined.Looking at the generated suricata.yaml:
Code Select
default-rule-path: /usr/local/etc/suricata/opnsense.rules
rule-files:
- suricata.rules
...
include:
- installed_rules.yamlsuricata.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:
Code Select
grep -r "suricata.rules" /usr/local/opnsense/service/templates/
/usr/local/opnsense/service/templates/OPNsense/IDS/suricata.yaml: - suricata.rulesSo 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):
Code Select
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.
