PfSense –> Snort Supress list not working

[ComputerFreek]

Hello Everyone.

Not sure if this is a bug or if I'm doing something wrong. I get a alert which causes a block and I suppress the block and remove the block. But it still blocks the suppression during the next attempt.

See PDF Files for Snort Settings

Current Suppression list:
suppress gen_id 120, sig_id 3
suppress gen_id 120, sig_id 8
suppress gen_id 119, sig_id 32
suppress gen_id 119, sig_id 2
suppress gen_id 137, sig_id 1
suppress gen_id 119, sig_id 4
suppress gen_id 119, sig_id 33
suppress gen_id 120, sig_id 10
suppress gen_id 119, sig_id 7
suppress gen_id 1, sig_id 2013504
suppress gen_id 1, sig_id 2017871
suppress gen_id 1, sig_id 2012648
suppress gen_id 1, sig_id 2013504
suppress gen_id 1, sig_id 2020565
suppress gen_id 1, sig_id 2003311
suppress gen_id 1, sig_id 2018959
suppress gen_id 1, sig_id 2013031

But the 1:2013031 keeps coming back…. Even Stopping Snort does not allow the data to go through. All i'm trying to do is perform a APT-GET within Ubuntu.

Thanks,
Kyle

[NogBadTheBad]

Have you tried going into ET POLICY and disabling it there ?

1:2013031 =  POLICY Python-urllib/ Suspicious User Agent

[ComputerFreek]

Hey NogBadTheBad,

Thanks for the reply. I did what you suggested - and it didn't work… See screen shots. I tried reloading the live data and that didn't fix the issue either. Until......

I restarted the firewall it self.... Do I have an issue with the live data within snort?

~Kyle


[bmeeks]

The most likely reason for the blocking to continue even after the rule is suppressed or disabled is that you had two instances of Snort running on the same interface, but one is in a sort of zombie state and does not see changes made within the GUI.  That process would continue with the original rules in place.  Rebooting the firewall will of course kill everything and start from scratch.  There should be only a single Snort process running on each configured interface.  You can check that using this command line:

ps -ax | grep snort

Sometimes multiple copies of Snort can happen if something causes the firewall to issue a "restart all packages" command while another Snort restart is already in progress (such as a rule update download).  Another way to get multiple Snort copies running on the same interface is using the Service Watchdog package.  Never use that package with either Snort or Suricata!.  It does not understand how to properly start Snort and Suricata, nor does it know how to properly monitor all the configured interfaces.  It will see Snort "down" during the restart from a rules update and thus issue its own "start up" command without knowing that Snort is already restarting.  Thus you can wind up with two Snort instances running on the same interface, but only one of them will respond to GUI changes.

Bill