• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

PfSense –> Snort Supress list not working

Scheduled Pinned Locked Moved General pfSense Questions
4 Posts 3 Posters 672 Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C
    ComputerFreek
    last edited by Dec 31, 2017, 12:49 PM

    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
    ![Snort Settings.JPG](/public/imported_attachments/1/Snort Settings.JPG)
    ![Snort Settings.JPG_thumb](/public/imported_attachments/1/Snort Settings.JPG_thumb)

    1 Reply Last reply Reply Quote 0
    • N
      NogBadTheBad
      last edited by Dec 31, 2017, 1:57 PM

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

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

      Andy

      1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

      1 Reply Last reply Reply Quote 0
      • C
        ComputerFreek
        last edited by Dec 31, 2017, 11:01 PM

        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

        ![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)

        1 Reply Last reply Reply Quote 0
        • B
          bmeeks
          last edited by Jan 1, 2018, 4:16 AM

          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

          1 Reply Last reply Reply Quote 0
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received