PfSense –> Snort Supress list not working

  • 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.

    ![Snort Settings.JPG](/public/imported_attachments/1/Snort Settings.JPG)
    ![Snort Settings.JPG_thumb](/public/imported_attachments/1/Snort Settings.JPG_thumb)

  • Galactic Empire

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

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

  • 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?


    ![Snort Settings within the Policy.JPG](/public/imported_attachments/1/Snort Settings within the Policy.JPG)
    ![Snort Settings within the Policy.JPG_thumb](/public/imported_attachments/1/Snort Settings within the Policy.JPG_thumb)
    ![Snort Blocked.JPG](/public/imported_attachments/1/Snort Blocked.JPG)
    ![Snort Blocked.JPG_thumb](/public/imported_attachments/1/Snort Blocked.JPG_thumb)

  • 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.


Log in to reply