How do I disable snort2c firewall blocks
-
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.1Please 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 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
-
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
-
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
-
@bmeeks If snort2c tables have 100,000 ip, I only remove one ip of 100,000 ip, BLOCKED tab show 100,000 ip long time, any method can do it?
-
@everfree said in How do I disable snort2c firewall blocks:
@bmeeks If snort2c tables have 100,000 ip, I only remove one ip of 100,000 ip, BLOCKED tab show 100,000 ip long time, any method can do it?
They should match. Are you refreshing the tab view in your browser? The code on the BLOCKED tab simply calls the
pfctlutility to dump the contents of the snort2c table into a PHP array. It then walks that array to display the blocked IPs on the BLOCKED tab.Have you verified that the IP you removed from the table is NOT showing on the BLOCKED tab? Maybe there is some kind of counting error on that page ???
-
The table in showing on BLOCKED tab, But it take 2 mins 20s to loading page. I just only remove one or two IP. It spent too long. =.=
-
You are hitting the limits of PHP and the GUI with 100,000 rows in that table. There is a limit to the amount of memory the PHP sub-system will allocate for arrays. There will also be slowdowns when processing such large lists.
This code is designed for much smaller lists. If you have 100,000 IPs showing as blocked, you must not be using the periodic cron task for clearing blocks. I would suggest you enable that task, if it's not enabled, and set it to a reasonable interval such as an hour.
Finally, there is a problem with the lastest pfSense 2.4.5 version and the
pfctlutility. The problem is actually present in FreeBSD 11.3/STABLE. The problem causespfctlto consume lots of CPU time and cause lags in the firewall's GUI response times as well as even impacting traffic flow under some circumstances when reading or editing large tables. Mentioning this in case you have updated to 2.4.5 of pfSense. Tables with entries above 65,535 can trigger the issue. -
@bmeeks
I update to 2.5.0 - Dev, I think If snort2c functions similar to pfblocker NG suppression, that is good. 
-
@everfree said in How do I disable snort2c firewall blocks:
@bmeeks
I update to 2.5.0 - Dev, I think If snort2c functions similar to pfblocker NG suppression, that is good. Yes, both packages use the
pfctlutility to interact withpftables. And thepfctlutility is showcasing some sort of issue that is present in FreeBSD 11.3/STABLE. The pfSense team is looking into it.
