Before discussing Snort rules specifically, I need to briefly mention the concept of false positives. In common security language, a false positive is considered to be an alert that does not represent a real security concern. For example, one or more of the following could be considered false positives:
- An IDS reports an attack that targets Microsoft IIS Web servers, but the attack is directed against an Apache Web server.
- An IDS reports seeing an event that shows syntax used in an attack, but the syntax is used in a benign manner by an authorized user.
- An IDS reports seeing a security event, but the traffic it believes it saw never actually occurred on the wire.
By my standards, only scenario three represents an actual false positive. The IDS was told to provide an alert when detecting a certain traffic pattern. Although that pattern did not pass on the wire, the IDS reported an alert. That is a significant problem and can be justified as a false positive.
I don't consider scenarios one and two to be false positives. If an operator tells an IDS to detect an event that matches certain characteristics, and the IDS performs that role properly, there is no false positive. I would blame the rule writer, IDS operator, and/or the IDS developer for setting the rule that resulted in the undesirable alert. There is little point blaming the tool for doing what it was told to do.
Snort Report -- IDS Snort rules
Introduction
False positives
Sourcefire rules
Bleeding Edge Threats rules
Acquiring Snort rules
Activating Snort rules
Loading rules
About the author
Richard Bejtlich is founder of TaoSecurity, author of several books on network security monitoring, including Extrusion Detection: Security Monitoring for Internal Intrusions, and operator of the TaoSecurity blog.
