SNORT SID Mgmt Disable not working

rtw915

Hello! I have never used SID management before. I read through @bmeeks "How Automatic SID Management and User Rule Overrides Work in Snort and Suricata" sticky and I think I set this up correctly.

I defined 2 new SID Management Configuration lists:

enable_cat-weblan.conf that contains categories that are enabled on the interface categories tab. My intention here was to override the default disabled rules in the already enabled categories. This appears to be working as the green "A" symbol is now on all the rules defined within the categories managed by SID Mgmt. Also the alerts tab is now getting filled with additional matches for the new rules (I expected and wanted this).
disabled_sid-weblan.conf this contains GID:SID to disable non-Preproc rules (we are only suppressing Preproc rules like the http_inspect ones). This is where I am having a problem.

For example 1:2003099 is causing issues in my environment, so I have disabled it in disabled_sid-weblan.conf. I made sure the SID State order was Enabled, Disabled, and that yields the correct looking screenshot below.

The problem is, even after I restarted the interface and even the entire SNORT package I am still getting thousands of these alerts.

bmeeks

While I doubt it would be, one thing to check is that SID 2003099 is NOT in the Auto-flowbits enabled rules. Go to the RULES tab and select the Auto-Flowbits category to see what rules are showing there.

Another possibility is you have more than one instance of Snort that has started and is running on the same interface. If that happens, one of those instances becomes a type of "zombie" process that will ignore changes made in the GUI. So it would ignore your SID Managment configuration changes. To see if this is the case, run this command from a shell prompt on the firewall:

ps -ax | grep snort

You should see only one instance of Snort per interface. If you see any duplicate lines, then you will need to kill the Snort processes and start them again.

Other than the two possibilities outlined above, I see no other reason for that rule to still be actively alerting. The steps you have done seem to be all correct.

Is is possible that at some time in the past you had a manual user-force enable on that rule or category? If so, user-forced rule changes (that's what you get when you click the icon to change a rule's state) override everything else including SID MGMT. You can check that by again going to the RULES tab and examing the User-Forced Enabled rules in the drop-down Category selector and checking what rules may be user-forced.

rtw915

@bmeeks

Thanks for you help! I checked if SID 2003099 is in the Auto-flowbit rule set and it is not.

I did have a "zombie" process, but removing that did not fix the issue. I killed Snort from the Status>services tab and restarted it and the "zombie" process is gone.

Pre Snort service restart:

I did in the past check the "Enable All" button on the etpro-web_server.rules category but I have since used the "Clear All" to revert it back to defaults before I tried to configure it via SID Mgmt. If I'm looking in the right spot there is no User Forced disabled rules

This rule has now alerted over 10k times.

bmeeks

You want to look in User-Forced Enabled Rules to see if it is listed. I'm wondering if, in the past, that rule category had perhaps been user-forced enabled by clicking the Enable icon on the RULES tab.

Your other option is to simply either user-forced disable that rule by clicking the icon on the ALERTS tab, or you can suppress that rule -- again by clicking the appropriate icon on the ALERTS tab.

rtw915

@bmeeks

So, I was wrong! It was a "zombie" process. I thought by restarting the Snort service it would kill it, but it did not. I Called Netgate to solve a PHP crashing issue due to Snort and he showed me how to kill a hung process. It is now working!

Incase you are interested, this was the PHP error:

[11-Mar-2021 20:52:03 America/New_York] PHP Fatal error:  Allowed memory size of 402653184 bytes exhausted (tried to allocate 102291912 bytes) in /usr/local/www/csrf/csrf-magic.php on line 161

Apparently due to the quantity of traffic we have the standard PHP allowed memory size was too low for the Alerts tab.

As always, thank you for your help!

bmeeks

@rtw915 said in SNORT SID Mgmt Disable not working:

@bmeeks

So, I was wrong! It was a "zombie" process. I thought by restarting the Snort service it would kill it, but it did not. I Called Netgate to solve a PHP crashing issue due to Snort and he showed me how to kill a hung process. It is now working!

No, restarting won't kill a zombie process. By definition those will not respond to anything from the GUI. They won't stop nor see any changes to the configuration.

Those can happen if something causes pfSense to rapidly issue a series of "restart all packages' commands. One trigger is your WAN IP changing quickly. Another possibility is Snort in the middle of an auto-restart due to a rules update and during that short interval pfSense issues a "restart all packages" command. That can result in two copies of Snort on the same interface, but one of those copies will not respond to the GUI at all.

The final thing that can lead to zombie Snort processes is the use of the Service Watchdog package to monitor Snort. That package does not understand how the internals of Snort are plumbed, and it therefore does not monitor everything necessary to adequately determine if Snort is running correctly. Also, it does not realize Snort stops and then restarts itself during a rules update (or when the admin manually cycles it via the GUI icons on the INTERFACES tab). When Service Watchdog sees the service down, it immediately calls the shell scrip to restart, but there may already be a restart in progress. Thus you can have two instances running on the same interface.