I activated Suricata IPS a few days ago, see IPS Ruleset automatic update - how to set time - #4 by dark0ipfire. Since then I get a lot of stream related alerts, which floods the log and could mask real important events. Also they might not be very helpful for gathering IPS data at all, as stated in Invalid Timestamp Alert flooding logs? | Netgate Forum.
I learn from Patch [1/7] suricata: Include all default rules - Patchwork that the corresponding ruleset “stream-events.rules” is activated in IPFire by default. As I do not see an option in the GUI to deactivate that ruleset, what is the best practice to disable this and other default rulesets and keep this setting while updating IPFire? I guess file /var/ipfire/suricata/suricata-default-rules.yaml will or might be overwritten each time when updating, true?
Meanwhile I looked around a bit and found the rules files in directory /var/lib/suricata, where I can dig further to get an idea, which rules applied to certain malicious IPs and so on. I think it would be great help in interpreting output of IPS Log Viewer, if alerts can be filtered by their Priority in “Settings:” options. Is there a chance, that someone will implement this?
sorry for my late reply.
Which IPFire version are you running? This sounds like you are using the testing version of Core Update 162, which contained a few quirks on the IPS side. See here on how to fix this, and get the final released Core Update 162, where this has been fixed.
Thanks, and best regards,
Dear Peter, thank you for commenting. I use the regular Core Update 162 and “flood the log” was a bit exaggerated wording of mine. However, I commented out the line containing “stream-events.rules” in file /var/ipfire/suricata/suricata-used-rulefiles.yaml and now these alerts are gone and I can focus on real ones. Nevertheless it would be great to have a filter option for priority levels in GUI.
that’s interesting to read.
On my testing machine, which has some poor NICs built-in, I observed a lot of the Suricata stream events when running the testing version of Core Update 162. After the aforementioned fix, and installing the final version of C162, they all disappeared.
Since I have a monitoring on which IPS alerts trigger, I can rule out they ever came back again.
Therefore, there must be something else causing them in your scenario. Do you perhaps have something like asymmetric routing in place?
Thanks, and best regards,
I would love a built-in checkbox in the UI to disable default suricata rulesets!
My ipfire system at work seems pretty quiet after disabling the mobile malware category. That seemed to trigger a bunch of extra suricata rules.
My ipfire system at home is still noisy with suricata rules, again mostly related to mobile malware category. When I disabled that, it quieted down form tens of thousands of log entries per day, to dozens per day. Why that category affects suricata rulesets, I don’t know. But I do know that our mobile devices at home are on the network that IPFire manages, while almost all mobile devices at work are on a separate network that does not go through IPFire.
Just a thought here, but maybe try and determine which of the home WiFi connected device(s) are actually causing the mobile malware alerts. You may actually have a security issue with one of the devices and not realize it.
Thanks, Rejjy_S. Just to clarify, it is not the mobile malware rule that is triggering, it is the default suricata rules. For some reason, when I disable the mobile malware category, the number of suricata rules triggered goes down.
Going from memory, the devices that are triggering the rules are a Roku device, an iphone 11 and a current gen ipad. I will look more closely at them to see if I can identify the behavior that is triggering the suricata rules.
On my system, the filename was suricata-default-rules.yaml, in the same location. I commented out the stream-events.rules line and it stopped the thousands of stream-events in my IPS logs.