Snort2c Hosts being blocked
-
Greetings,
I'm running the latest pfSense Plus release of 21.05. Last week, it started blocking all web traffic destined for port 80 and 443 for no real reason. The firewall log shows this. I am runnning Suricata and it has been tuned a decent amount to eliminate these false positives. I even have the Snort rules turned off in Suricata and this blocking of Snort2c hosts still happens from time to time.
To fix it, I have to clear the block list in Suricata and then traffic flow resumes. Any idea why pfSense and Suricata just suddenly trigger a full on Snort2c block and decide that 80 and 443 to anywhere shouldn't pass?
-
The Alerts tab will show what rule is being triggered.
-
@steveits The rule being shown as triggered is the Snort2c hosts. Even though there is no written rule for such a thing.
-
@rebelscum said in Snort2c Hosts being blocked:
@steveits The rule being shown as triggered is the Snort2c hosts. Even though there is no written rule for such a thing.
You are not understanding how Suricata blocks when using Legacy Blocking Mode. Suricata (and also Snort), when using Legacy Mode blocking, makes calls to the FreeBSD operating system to insert the IP address that needs to be blocked into a special packet filter (
pf) table calledsnort2c. That table is always created at bootup by pfSense itself, and is the target of an automatically created and hidden system rule that is very near the top of your ruleset. Any IP address inserted into that table is then blocked by thepffirewall engine. To see the entire firewall rule set, including these hidden system rules, you need to examine the/tmp/rules.debugfile on your firewall.So, as @SteveITS said, when a Suricata rule is triggered in Legacy Blocking Mode, Suricata will place the offending IP address from the triggered alert into the
snort2ctable so thatpfwill then start blocking it. To see what alert caused that to happen, you need to examine the ALERTS tab in Suricata to see what has been triggered. To see what IP addresses Suricata has put into thesnort2ctable, look on the BLOCKS tab. That tab is populated by querying thesnort2table in thepfengine.Doing the above will let you see which rule triggered. It is then up to you, as the IDS/IPS admin, to decide if the rule triggered on a false positive, or on a legitimate threat.
-
In the Block list, do you just see a ton of IP's? If so, there is a rule that is being triggered. In my experience it's something like a malformed packet or it sees as a header too small. In that case it may be a NIC setting or something upstream. When I find that, though, I find the WAN IP as being blocked in the Snort list. What are you seeing in the block table?
-
@stewart said in Snort2c Hosts being blocked:
find the WAN IP as being blocked
Your WAN IP should appear if Snort is running on the WAN interface. If you move it to LAN, you'll see LAN IPs, and it won't see/scan traffic that was blocked by the firewall.
-
@steveits said in Snort2c Hosts being blocked:
@stewart said in Snort2c Hosts being blocked:
find the WAN IP as being blocked
Your WAN IP should appear if Snort is running on the WAN interface. If you move it to LAN, you'll see LAN IPs, and it won't see/scan traffic that was blocked by the firewall.
You misunderstand, I think. I'm not saying that I see the WAN IP in the Alerts (which I do since it's on the WAN). I'm saying I sometimes see the WAN IP in the snort2c block table. In that Suricata actually places the WAN IP on the block list and won't accept any traffic to or from the WAN IP for the duration of the block time. If he's running IDS on the WAN and the WAN IP is getting blocked then it won't accept any traffic at all on the WAN. I'm wondering if that is what he is seeing since he is talking about the snort2c block table and not the Alerts or Block lists.
