Snort http inspection
-
I'm getting several false positives with "Use HTTP Inspect to Normalize/Decode and detect HTTP traffic and protocol anomalies" enabled. Is there any harm to not enabling it if I am not very concerned about malicious outbound http traffic? It seems when it's not enabled snort crashes frequently.
-
I'm getting several false positives with "Use HTTP Inspect to Normalize/Decode and detect HTTP traffic and protocol anomalies" enabled. Is there any harm to not enabling it if I am not very concerned about malicious outbound http traffic? It seems when it's not enabled snort crashes frequently.
The HTTP Inspect Preprocessor is critical to Snort's operation when it comes to assembling and analyzing HTTP traffic. What you are seeing with the "crashes" is the result of Snort's internal dependence on the HTTP Inspect preprocessor. It does generate an awful of false positives, though. Here is a thread with a list of Suppress List entries many folks use to silence the most frequent known-to-be false positives.
https://forum.pfsense.org/index.php/topic,56267.0.html
You can disable the HTTP Inspect preprocessor by unchecking that box you referenced, but in order to prevent "crashes" you will need to also disable all the Snort VRT and ET rules that use rule options provided by that preprocessor. There is an automatic mechanism to do this in the Snort package, but it comes with lots of warnings for a good reason. At the top of the Preprocessors tab you will see a check box for automatic rule disable for disabled preprocessors. Clicking that and saving will generate a new list of rules with all the ones disabled that depend on preprocessors you have not enabled on the tab. It will write a log showing you how many and which rules were auto-disabled. If you try this and look at that log, you will be quite surprised at how much protection goes out the window in the way of auto-disabled rules. Or stated differently, there are many, many rules that depend on the HTTP Inspect preprocessor being enabled in order for them to work.
So to wrap up a long answer, the preferred way to deal with false positives is via the Suppress List and not by disabling HTTP Inspect. Follow the lead of the users in the thread link I posted.
Bill
-
Should I also enable all the imap preprocessors, etc if I am not running any mail servers?
-
Should I also enable all the imap preprocessors, etc if I am not running any mail servers?
I would enable them, because you never know when the daily rule updates from VRT or ET will suddenly enable a formerly disabled rule that depends on a preprocessor you have not enabled. If that happens, Snort will fail to restart due to the dependency (just like with the HTTP Inspect preprocessor being disabled). If you look in the rule sets for either VRT or ET, you will see lots of disabled rules here and there. Sometimes, these get enabled again, or modified slightly and then enabled as new threats emerge or old ones mutate. This can really show up if you run one of the Snort VRT canned security policies.
The only Preprocessors you can relatively safely disable are: Sensitive Data (sdf) and the two SCADA ones (Modbus and DNP3). Those are the only preprocessors I disable in my environment. With today's CPU hardware, there is essentially zero penalty for running all the preprocessors unless you are trying to maintain 10 Gigabit/sec speeds or something.
Bill
-
If I only want the ability to block port scans on WAN, should I just enable port scan detection and the scan rules for ET? Or do I even need to enable any rules? Thanks for your help on this and the contributions you make to the project.
-
If I only want the ability to block port scans on WAN, should I just enable port scan detection and the scan rules for ET? Or do I even need to enable any rules? Thanks for your help on this and the contributions you make to the project.
The built-in Snort port scan preprocessor does not need any separate rules to work, but it might miss some things the elaborate ET rules could catch. There are several settings for "sensitivity" for the built-in port scan detection along with a way to construct a "whitelist" of scanners to ignore. You will probably need this because the port scan logic can get fooled by lots of legitimate traffic (for example, a series of rapid DNS lookups can be mistaken for a port scan).
Try it, but be ready to experiment with the sensitivity and port scan type settings to tune it for your environment.
To get a better handle on the relationship of preprocessors to rule options, Google for "snort preprocessor rule options". You can also download the Snort manual from Snort.org and look in there. Notice that many of the preprocessors support what are called "rule options". These are special keywords that are inserted into the text rules that instruct Snort to look for specific triggers in order to match that rule and fire an alert. These rule options require the various preprocessors that provide the underlying software code to "decode" the rule options be enabled. If a text rule contains a rule option that Snort does not recognize because the required preprocessor is disabled, then Snort will die on startup with an "unrecognized rule option" error (I don't recall the exact wording of the error message, but that's the general idea).
Bill
-
Thanks Bill
