Hi all,
thanks for raising this issue and the lively discussion.
To be honest, the value of Suricata’s own IPS rules is rather limited to me as well. Even very small networks are already way too noisy to investigate on IPS hits generated by those.
@stevee: What is your opinion on that front? Do you see a better balance between making use of Suricata’s own rules and keeping the IPS logs relevant to NOC/SOC/IT security folks?
Thanks, and best regards,
Peter Müller
Out of curiosity, how are Suricata’s priorities used in IPFire. The Suricata documentation indicates priorities can range from 1 to 255 (priorities 1 to 4 being the most common). The priority is used to dictate the order for the processing the rule sets. A priority 1 rule is processed before a priority 2 and so on.
Looking back through the logs, I see many of the ET rules triggered with priority 1 or 2 and Suricata’s built in set being logged with a priority of 3. Are all IPS rule set blocked regardless of priority or are Suricata’s IPS actions based on priority, that is priority 1 is blocked with other priorities being some other action?
Thanks for the help, PZ
The standard rules from my attachment with priority 3 are definitely not blocked, only logged. ET rules with priority 1-2 are blocked.
Hello,
Here are the files that tells suricata to use Default rules
/etc/suricatasuricata.yaml
Contains this line:
# Include default rules.
include: /var/ipfire/suricata/suricata-default-rules.yaml
and /var/ipfire/suricata/suricata-default-rules.yaml contains
cat /var/ipfire/suricata/suricata-default-rules.yaml
%YAML 1.1
---
#Autogenerated file. Any custom changes will be overwritten!
- /var/lib/suricata/whitelist.rules
#Default rules for used application layer protocols.
- /usr/share/suricata/rules/app-layer-events.rules
- /usr/share/suricata/rules/decoder-events.rules
- /usr/share/suricata/rules/dhcp-events.rules
- /usr/share/suricata/rules/dns-events.rules
- /usr/share/suricata/rules/files.rules
- /usr/share/suricata/rules/http-events.rules
- /usr/share/suricata/rules/ipsec-events.rules
- /usr/share/suricata/rules/kerberos-events.rules
- /usr/share/suricata/rules/nfs-events.rules
- /usr/share/suricata/rules/ntp-events.rules
- /usr/share/suricata/rules/smb-events.rules
- /usr/share/suricata/rules/smtp-events.rules
- /usr/share/suricata/rules/stream-events.rules
- /usr/share/suricata/rules/tls-events.rules
How suricata is started: with config file /etc/suricata/suricata.yaml
/usr/bin/suricata -c /etc/suricata/suricata.yaml -D -q 0:3
Hope it helps
Late edit: same /etc/suricata/suricata.yaml tells suricata to use threshold.config from /usr/share/suricata/rules/
And then oinkmaster.conf tells suricata to skip it
And same oinkmaster.conf tells suricata to also skip local.rules the user manually created
# have put some local rules in our own local.rules and we don't want it
# to get overwritten by the empty one from the archive after each
# update.
skipfile local.rules
So on and so forth…
These 2 files /etc/suricata/suricata.yaml and /var/ipfire/suricata/oinkmaster.conf controlls suricata behavior…
Is this an old setup? On my system the following files do not exist:
/var/ipfire/suricata/suricata-default-rules.yaml
/var/ipfire/suricata/oinkmaster.conf
But /var/ipfire/suricata/suricata-used-rules.yaml is included by suricata.yaml and in this file are the standard-rules. After commenting them out, it works for me. But they’re back, when the rules are updated.
I don’t believe oinkmaster.conf configures suricata, does it? It configures the automatic rules updater. If so, it’s not telling suricata to skip those files. It’s telling the updater not to change them.
At least, that’s my understanding (but I haven’t verified it.)
-Dan
It does during rules upgrade - this files controll the update process to add, or bypass rules or setting from various files (threshold.config, local.rules, etc)
Not that old: core 167
Suricata changed significantly from CU167 to CU168 with multiple providers and modified update process etc.
What interfaces have you enabled ISP on?
I Have just updated to CU169
ISP on GREEN
Will monitor logs.
I’m sure it makes more sense to enable on RED.
I also have problems with a lot of logs, see How to stop IPS "SURICATA ICMPv4 invalid checksum" logs?
Hi!
I have fireinfo.ipfire.org - Profile 72a721ca22ee04f59b30ada2f17f4a85fb1ebd07 and I am using Emergingthreats.net Community Rules 2022-08-10 00:08:52.It seems like my HarmonyHub ( Harmony Hub = remote control system for TV etc = 192.168.0.57) is spamming the IPS logs every 30 seconds with:
Date: 08/11 10:08:02 Name: SURICATA ICMPv4 invalid checksum Priority: 3 Type: Generic Protocol Command Decode IP info: 192.168.0.254:0 → 192.168.0.57:0 References: none found SID: 2200076 It started like a month ago, don’t know if it was after update of HarmonyHub or Ipfire.
I have searched in WUI - Firewall - Intrusion Prevention - Customize Ruleset, but can’t find what to turn off to stop the flood.
While it is annoying, it is also making it hard to see if there are other important stuff in the logs that I should know about.
Any tips for fixing this, that do not include threats and/or violence against the stupid HarmonyHub?
So maybe I can temporary edit /usr/share/suricata/rules/decoder-events.rules, eg under # checksum rules comment out this:
alert icmp any any -> any any (msg:"SURICATA ICMPv4 invalid checksum"; icmpv4-csum:invalid; classtype:protocol-command-decode; sid:2200076; rev:2;)
Maybe with:
sed -i 's/alert icmp any any -> any any (msg:\"SURICATA ICMPv4/#alert icmp any any -> any any (msg:\"SURICATA ICMPv4/g' /usr/share/suricata/rules/decoder-events.rules
/etc/init.d/suricata restart
Is it possible to run the above automatically every time the rules have been updated? Naturally temporary until something better is figured out. Maybe put above commands in tempskipicmp.sh, then do fcrontab -e and edit
@ 12h [ -f "/var/ipfire/red/active" ] && /usr/local/bin/update-ids-ruleset >/dev/null 2>&1
to
@ 12h [ -f "/var/ipfire/red/active" ] && /usr/local/bin/update-ids-ruleset >/dev/null 2>&1 && /root/tempskipicmp.sh
This may not help, but on my home system I need to disable a few of the Suricata rules due to a high volume of false-positives.
As a temporary work-around, I’ve found a configuration which works. (Note: I made a few attempts but I believe these are the steps which succeeded after a normal ruleset update)
The emerging-threats ruleset is enabled on my system. There is a /var/ipfire/suricata/oinkmaster-emerging-modified-sids.conf file. It warns that it can’t be modified as it will be overwritten, but has an include reference to a file which doesn’t exist. So, I created that missing file and disabled the specific rules which were causing problems (using oinkmaster configuration, not the 2210007=disabled syntax).
For example in a /var/ipfire/suricata/oinkmaster-emerging-modified-sids.conf file
# Oinkmaster.conf included file created by me but originally referenced in default IPFire configuration
# Disable Suricata built in - "SURICATA STREAM ESTABLISHED SYNAC resend with different seq"
disablesid 2210024
# Disable Suricata built in - "SURICATA STREAM 3way handshake SYNACK with wrong ack"
disablesid 2210007
I forced a rule reload which didn’t do anything as no update was required, however by the next day it seems to have worked.
What is this file called
Where did you put it.
I guess the path would help.
Great work to find a solution.
@hvacguy oops, I accidentally named the wrong file the first time.
On my system oinkmaster-provider-includes.conf already existed. It referenced a oinkmaster-emerging-modified-sids.conf file which didn’t. After creating the second and adding the appropriate entries (explained in my last post) I found that it had worked when I checked the next day.
We’ll see if it still works with the latest IPFire update. I’ll test and let you know once that update has hit my local mirrors.
It appears to be working with Update 170! Let me know if it doesn’t for you.
It’s quite possible that these files are specific to the configuration I use as the oinkmaster-provider-includes.conf file, which was created by IPFire specifically mentioned Emerging Threats and I have that ruleset enabled.
For me it looks like this:
[root@ipfire ~]# cat /var/ipfire/suricata/oinkmaster-provider-includes.conf
#Autogenerated file. Any custom changes will be overwritten!
include /var/ipfire/suricata/oinkmaster-emerging-modified-sids.conf
So I created this:
[root@gateway ~]# cat /var/ipfire/suricata/oinkmaster-emerging-modified-sids.conf
# Oinkmaster.conf included file created by me but originally referenced in default IPFire configuration
# Disable Suricata built in - "SURICATA STREAM ESTABLISHED SYNAC resend with different seq"
disablesid 2210024
# Disable Suricata built in - "SURICATA STREAM 3way handshake SYNACK with wrong ack"
disablesid 2210007
I am sorry but this does not work here. I went the same way as you did @dnl, but there are the rules still firing, that I put into the /var/ipfire/suricata/oinkmaster-emerging-modified-sids.conf.
Sorry to hear that @waynetsun
I had also added rules to the standard configuration file, which in the case of Emerging Threats is /var/ipfire/suricata/emerging-modifications. Just note that this file is likely to be overwritten by the UI if you make changes there (I don’t as before these Suricata rules were added my rulesets had very few false positives).
The end of that file looks like this for me…
[root@ipfire suricata]# tail -6 /var/ipfire/suricata/emerging-modifications
# Tried to disable Suricata built in - "SURICATA STREAM ESTABLISHED SYNAC resend with different seq"
2210024=disabled
# Tried to disable Suricata built in - "SURICATA STREAM 3way handshake SYNACK with wrong ack"
2210007=disabled
# Disable SURICATA - Applayer Detect protocol only one direction
2200074=disabled
I’m not sure who made the major changes to the IPS, they’re great!
It would be really helpful if the built-in Suricata rules could please shown in the configured Rulesets in the UI. That way we could selectively disable specific rules. I personally feel the ruleset has value, there’s just a few of them which cause hundreds of false positives.
@dnl Doesn’t work here as well. I found s.th. interesting at suricata forum: Asymmetric Traffic within Suricata - Help - Suricata (especially post #4)
Maybe there should be a switch on/off for these default suricata rules? In particular these rules are firing a lot of false positives.
You’re right. While I had a decrease in false-positives, the rules are all still firing now. 
It must have been a co-incidence.
Reviving this: It would be really helpful if we could disable rules or rules files from the Default Suricata rulesets.
I’ve been commenting out the references to app-layer-events.rules and stream-events.rules in /var/ipfire/suricata/suricata-used-rulesfiles.yaml due to various false positives. Unfortunately that file is maintained by IPFire and is overwritten occasionally on updates, which makes the changes only temporary.