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.
1 Like
What is this file called
Where did you put it.
I guess the path would help.
Great work to find a solution.
2 Likes
@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.
1 Like
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
1 Like
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.
2 Likes
@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.
3 Likes