Snort: Alerts in the suppress list still visible in logg
-
Is there nobody with the same experience? I'm unable to suppress alerts on the OPT1 interface. The alerts are greyed out but they still appear in the log. Must be a bug of some sort.
-
@Ip:
Is there nobody with the same experience? I'm unable to suppress alerts on the OPT1 interface. The alerts are greyed out but they still appear in the log. Must be a bug of some sort.
Look on the INTERFACE SETTINGS tab for the interface and down near the bottom of the page note which Suppress List is actually assigned to the interface. There is also a small VIEW LIST button to the side of the drop-down selector for the Suppress List. Click that to view the actual list contents. You can change the assigned Suppress List on this tab.
Bill
-
FWIW … I saw the same behavior that the OP described in Suricata. It was occurring on both interfaces that I had configured (LAN and OPT1). I verified that the correct suppress lists were applied to the interfaces and that the lists contained the proper entries.
I finally uninstalled the package (along with the current config). I then manually reentered the previous configuration and the problem has not reappeared.
-
Going to have to take back my previous post.
Yesterday, I uninstalled SURICATA and manually reconfigured everything. I've been manually adding items to the suppress list (different list for each interface) as they come up. There have been no alerts for items in the suppress lists.
UNTIL I did a restart of Suricata. Now all of the items in the suppress lists are showing up again as alerts. The add to suppress list button is grayed out and when you hover it says "This item is already in the Suppress List". Which is true, it's in the list and the proper list is associated with the interface … and was working properly until I restarted the service.
Hum???
-
Going to have to take back my previous post.
Yesterday, I uninstalled SURICATA and manually reconfigured everything. I've been manually adding items to the suppress list (different list for each interface) as they come up. There have been no alerts for items in the suppress lists.
UNTIL I did a restart of Suricata. Now all of the items in the suppress lists are showing up again as alerts. The add to suppress list button is grayed out and when you hover it says "This item is already in the Suppress List". Which is true, it's in the list and the proper list is associated with the interface … and was working properly until I restarted the service.
Hum???
Was this exact alert (the ICMP v6 unknown type) the one that was suppressed and then "unsuppressed" after the reboot? Just wondering as I think this is from one of Suricata's decoder alert streams instead of a rules-based alert.
For what it's worth, I have noticed issues in testing with Suricata and Suppress Lists. I have not yet been able to isolate the problem. It says in the logs that it parses and understands the suppress list (they call it "threshold", but it's the same thing). However, I've seen suppressed alerts still show up.
Bill
-
Is it possible that there are duplicate sessions of suricata running?
Try pgrep suricata
-
@BBcan17:
Is it possible that there are duplicate sessions of suricata running?
Try pgrep suricata
I have 3 interfaces configured and have 3 instances running.
[2.1.2-RELEASE][admin@pfsense.localdomain]/root(1): pgrep suricata 84633 83849 83229–-
Was this exact alert (the ICMP v6 unknown type) the one that was suppressed and then "unsuppressed" after the reboot?
As I recall, all the "bad actors" have been stream events that had already been added to the suppress list. But, that may be just because there are so many it's more apparent.
However, I have noticed something interesting.
There was a large burst of the unexpected suppressed alerts right after I restarted Suricata (some of these stream events are very noisy). And none since, of a new type.
–-
Thereory : It looks like a timing or order of execution issue. Suricata starts processing alerts before the Suppress Lists are read in. So, the alerts make their way into the Alert Log. Shortly thereafter they become recognized as being in the Suppress List (icon is then grayed out), just a couple of seconds too late!
Also, once a rule "slips through" in this manner, it will keep alerting regardless. I finally had to do a force-disable on this "ICMP v6 unknown type" rule.
–-
Sorry if I have hijacked the OP's original issue in Snort. But, it sounded like a related issue.
-
Thereory : It looks like a timing or order of execution issue. Suricata starts processing alerts before the Suppress Lists are read in. So, the alerts make their way into the Alert Log. Shortly thereafter they become recognized as being in the Suppress List (icon is then grayed out), just a couple of seconds too late!
Also, once a rule "slips through" in this manner, it will keep alerting regardless. I finally had to do a force-disable on this "ICMP v6 unknown type" rule.
–-
Sorry if I have hijacked the OP's original issue in Snort. But, it sounded like a related issue.
You may be on to something with this theory. There is a setting in Suricata to start processing rules early in the startup process. I defaulted it to "on". Perhaps we should try "off" instead. Try this for me and report back –
Edit /usr/local/pkg/suricata/suricata_yaml_template.inc and find this section of the file:
detect-engine: - profile: {$detect_eng_profile} - sgh-mpm-context: {$sgh_mpm_ctx} - inspection-recursion-limit: {$inspection_recursion_limit} - rule-reload: true - delayed-detect: yesChange the delayed-detect line to "no" instead of "yes" and then restart Suricata.
For general reference, this "template file" is used to create the suricata.yaml config file for each interface. The parameters in {} are string variables that get replaced with GUI configurable settings. The other lines are just hard-coded and output as written. DO NOT change any of the {} lines as errors will likely result. You can edit any of the hard-coded lines and they will be reflected in all future suricata.yaml files for all interfaces.
Bill
-
Oh ya, much better changing that to 'no'.I first verified I was able to reproduce the behavior by restarting Suricata a number of times … and I was.
I then made the change and have restarted 5 times without seeing it.EDIT: Scratch that. 12 minutes after the last restart, suppressed rules started showing up in the alerts.
-
Oh ya, much better changing that to 'no'.I first verified I was able to reproduce the behavior by restarting Suricata a number of times … and I was.
I then made the change and have restarted 5 times without seeing it.EDIT: Scratch that. 12 minutes after the last restart, suppressed rules started showing up in the alerts.
I'm out of ideas at this point. I will need to walk through the Suricata binary source code to see if I see a problem. Curious that I've seen nothing similar in my Google searches, though. I will look at this, but let me put it on the back burner for several days while I get the Snort bug fixes posted and finish up the blocking code for Suricata.
As a temporary workaround, how about just disabling the problem rules??
Bill
-
Thanks. Not critical. I'm just running Suricata to help with beta testing.
-
I'm just running Suricata to help with beta testing.
…And that and the feedback are very much appreciated... :)
Bill
-
@Priller, Did you try to re-install Snort? Or a De-install and re-install (Make sure the Checkbox is click to keep settings after deinstall)
-
@BBcan17:
@Priller, Did you try to re-install Snort? Or a De-install and re-install (Make sure the Checkbox is click to keep settings after deinstall)
My bad for hijacking the original Snort problem reported. Snort is working fine for me, it's Suricata that is exhibiting the identical problem that the OP reported with Snort.
So, for Suricata, yes I did try a de-install and re-install. I performed that both keeping the config … and also a total removed and rebuilt the config by hand.
