How do I disable snort2c firewall blocks


  • Banned

    Can't seem to find a way to stop all the legitimate blocking of the following rules in the firewall
    Block snort2c hosts (1000000117)
    Block snort2c hosts (1000000118)
    I am getting lots of legitimate hits being block by this rule.
    I have Suricata installed but not Snort. I have Suricata stopped on WAN, but the blocks continue even if I stop the Suricata service.
    How do I ignore these blocks? I even tried an Easy Rule to pass the traffic and that doesn't stop the blocks either.
    Is there a disablesid rule that I can use? 1:1000000117 doesn't work.
    Since I do not know where this is coming from I don't know how to fix this.
    Using PFsense 2.4.1

    Please help!



  • You need to understand how Snort and Suricata (when in Legacy Mode Blocking) work on pfSense.  Let me explain for the benefit of others who may see this thread, then I will tell you how to clear the blocks.

    Blocking is not done directly by the Snort or Suricata packages.  Instead, the underlying binary used in both packages makes a FreeBSD system call to pass the offending IP address (the address to be blocked) to the packet filter (pf) firewall.  The pfSense source code includes a section that creates a dedicated pf table during boot up of the firewall.  That table is named snort2c.  Custom firewall rules are then created very near the top of the firewall rules chain.  Those rules reference the snort2c packet filter table.  The rules basically tell the firewall to block any IP addresses that are loaded into the snort2c table.  The snort2c table is used by both Snort and Suricata.  Its creation got into pfSense way back when the Snort package was first added to the firewall.  When Suricata came along, I just used the already existing snort2c table for Suricata's Legacy Mode blocking.

    You can see the contents of this special firewall table by looking under DIAGNOSTICS > TABLES and choosing snort2c from the drop-down list.  Any IP addresses you then see listed in that table are currently being blocked by the firewall.  The Snort (or Suricata) binary put the IP addresses in that table when a rule was triggered on traffic to or from that IP address.

    So, the blocking of traffic when using Snort or Suricata is a two-part process.  First, the IDS package detects offending traffic.  This is traffic that triggered a Snort or Suricata rule.  Next, the IP addresses from that traffic are stored in the snort2c table using a FreeBSD system call.  It is then the responsibility of the packet filter firewall to actually implement the block.  It does that using firewall rules whose source and destination IP address fields use the contents of the snort2c table.

    So now on to your problem.  Likely you are still getting blocks because those IP addresses are still in the snort2c table.  That table is cleared in one of three ways: (1) by you manually clicking the button on the BLOCKED tab to clear blocked hosts; (2) by the cron job that runs to clear blocked hosts on a periodic basis if that that option is enabled on the GLOBAL SETTINGS tab; or (3) by rebooting the firewall.  Rebooting clears the blocked table because it is a RAM-based construct and starts fresh and empty on each reboot.

    There is a final fourth method to clear the table.  When viewing the table's contents via DIAGNOSTICS > TABLES, you can click the Clear Table button to remove all the IP addresses.  Removing the IP addresses from the snort2c table will clear the blocks.

    Bill


  • Banned

    Bill, you are one smart cookie. Thanks for laying this process out.
    Now I know how to delete an IP in the snort2c table. Thanks for that.
    Now my task is to find out how it got there in the first place.

    More questions. if you don't mind.
    How long does the IP stay in the table and is that function controllable?
    Does any other process besides Snort and Suricata insert IP's in that table?
    Is there any log that may show what inserted the IP into the snort2c table?

    Also, I assume from your wording that Inline mode does not use the snort2c table. Is that a correct assumption?

    Great work. Thanks



  • @dcol:

    Bill, you are one smart cookie. Thanks for laying this process out.
    Now I know how to delete an IP in the snort2c table. Thanks for that.
    Now my task is to find out how it got there in the first place.

    More questions. if you don't mind.
    How long does the IP stay in the table and is that function controllable?
    Does any other process besides Snort and Suricata insert IP's in that table?
    Is there any log that may show what inserted the IP into the snort2c table?

    Also, I assume from your wording that Inline mode does not use the snort2c table. Is that a correct assumption?

    Great work. Thanks

    IP addresses stay in that table until they are either deleted by the cron process, by the user manually or until the firewall is rebooted.  There is a setting on the GLOBAL SETTINGS tab called "Remove Blocked Hosts Interval".  You can choose there an interval for clearing the table.  IP addresses that have not seen "action" within the time period set are removed from the table.

    No other processes except Snort and Suricata use that table.  They are the only processes putting IP addresses in there.

    Suricata, when using Inline IPS Mode blocking, does not use the snort2c table at all.  It uses a completely different method with a Netmap pipe between the NIC and the kernel.

    No, there is no log of who (or what process) inserted the IP address into the table, but only Snort or Suricata will do it anyway.

    The only way an IP can get into that table is by a Snort or Suricata rule triggering when either package is configured for blocking mode operation.  This means Legacy Mode blocking for Suricata.  As stated earlier, Inline IPS Mode does not use the snort2c table.

    Bill


Log in to reply