Turning off rule(s) does not stop blocking
-
System Setup:
-
pfSense v2.4.1
-
Snort v3.2.9.5_3
-
Celeron J1900 w/ 4GB RAM
Initial state: Snort running on LAN interface w/ no categories enabled, no pre-processor rules disabled, and nothing in the suppression list.
Issue: When trying to access a given site, the site fails to load and I observe several blocked hosts due to a variety of issues. After some research, I disable several rules on the LAN interface based on the recommended suppression lists found in many forum posts that discuss recommended initial setups and how to combat false-positives. I then restart Snort on the LAN interface and clear the blocked hosts.
Upon trying to access the same site, I observe similar behavior however this time, the blocked hosts are due solely to (http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE. In looking through the pre-processor rules for the LAN interface, the above message appears to be due to rule 120:3 which I confirm has already been disabled due to the work performed above. I decide to head over to the pre-processor tab and disable the HTTP_INSPECT pre-processor. I again restart Snort on the LAN interface and clear the blocked hosts.
This time, when trying to access the desired host, all is well…..So, why?
I mean I understand why disabling the HTTP_INSECT pre-processor solved the issue but I don't understand why it is required…or maybe it isn't required and I'm just not understanding something here.
I did go and inspect the other pre-processor rules and nothing else jumped out as a possible culprit. I do remember reading in at least one of the forum posts that some rules cannot be disabled and therefore are not shown in the GUI. Is this what is occurring here?
Switching gears for a moment, another issue I'm seeing is that despite the suppression list being empty, I do not see any alerts regarding the above blocking. At one point in my testing, the suppression list did have some entries but I cleared those out manually and then re-executed the above steps to ensure I had good test data. However, still no joy...even after clearing out the suppression list and restarting Snort on the LAN interface...no alerts.
Thanks in advance for any help and insight you can provide.
PS: Before posting this, I did exercise a fair degree of diligence in trying to find the answers so apologies if I missed anything obvious. :o ??? ::)
-
-
UPDATE w/ screenshots.
The attached screenshots show the alerts for a blocked host as well as the host block log entry - both despite the rules in question being disabled (120:3 & 120:8). Also note in the alert screenshot, the entries have the little yellow "X" indicating that the rule for that log entry is supposed to be in force-disabled state.
-
Your two posts are confusing and seem to contradict each other a bit. In the first post you said –
Switching gears for a moment, another issue I'm seeing is that despite the suppression list being empty, I do not see any alerts regarding the above blocking.
But then your second post includes screen shots of said alerts from the ALERTS tab.
1. Are you only running Snort on the LAN?
2. Have you checked to be sure a duplicate Snort process is not running? Run this from a CLI to verify only one instance of Snort is running per enabled interface –
ps -ax |grep snort
You should not disable the HTTP_INSPECT preprocessor. It is a required dependency for a number of other rules, so as you enable additional rules later you are going to experience errors and Snort will fail to start. In fact, you generally should not disable any of the preprocessors enabled as part of a default clean install.
The correct way to handle the 'false positive prone" HTTP_INSPECT rules is to put them in a Suppress List and then be sure you go to the INTERFACE SETTINGS tab and select and enable that Suppress List for the interface. Save the change and then restart Snort.
Bill
-
bmeeks–-
Agreed that my original post is confusing - I am going to re-test everything and then clarify as needed. Before doing so however, I want to clarify disabling vs. suppression.
My understanding of what suppress does is as follows: Disables the alert for a given rule and if blocking is enabled, then it also also disables the blocking for that rule. Please correct if this is inaccurate.
Next is the question of the delta between disabling and suppression - the only difference I see is that disabling is basically suppression + the added benefit of not wasting resources for analysis of the rule in question. Feel free to also correct if this is inaccurate.
Finally, when to use one over the other. In this forum post, jflsakfja states that the "correct" method for dealing with false positives is to disable rather than suppress. Would you agree with this or is your view that suppression is better?
Thanks again for your help…
-
Disabling a rule removes it from RAM entirely and it is never used to evaluate traffic. Thus computing resources are not wasted. However, if a rule is disabled, then it is naturally disabled for all hosts (and networks) on the interface.
Suppressing a rule allows for selectively disabling the alert for some combination of hosts or networks, but it does not disable it for all hosts and networks. This is assuming you have elected to suppress by IP using one of those options. Of course if you suppress simply by GID:SID, then that's the same functional result as disabling the rule but with the downside of leaving the rule in RAM where computing resources get wasted evaluating it.
In the real world, with today's high-speed CPUs, there is essentially no measureable difference in suppression versus disabling unless we are talking thousands of rules on multiple hundreds of megabits of traffic per second. I will further qualify this generalization by saying this assumes a modern Intel/AMD multi-core CPU. Now if you have a less capable CPUs like many of the very small footprint motherboards use, then there can be measurable differences in suppressing versus disabling rules even on relatively low-traffic networks.
You can safely disable some of the Snort preprocessor rules, but do not disable the preprocessor itself! The preprocessor is responsible for basic traffic normalization before passing it on to the rules engine.
As for "suppress" versus "disable", if I know I do not want the rule active for any of my hosts or networks I am inclined to disable it. Suppression is good when you want to "disable the rule" only for certain IP addresses, for example.
Bill
-
Incredible explanation - beyond awesome - Thank you…