9.1 False Positives (False Alarms)

When examining alerts, remember that there will always be false positives. False positives are alerts that Snort classifies as intrusion attempts, but which are really benign and can safely be ignored. The sooner you learn to recognize these false positives and disable them accordingly, the better off your system (as well as your mental health) will be.

The best indicator of a false positive is that a rule generates a far greater number of alerts than usual. If you have thousands of alerts from a single signature and yet only a small sampling of other alerts, your IDS may be registering a false positive. Check the source and destination IP addresses. If both of the addresses are within your network, it may simply be a normal packet that Snort falsely identifies as malicious. Or it may be normal traffic coming from a server using some unique port or protocol. Or it may be a genuine intrusion attempt, and you'll need to correct the problem at its source.

The next step in recognizing a false positive is to check the Snort rule generating the alert. The rule may simply be too generic or broad and, as a result, detect peripheral traffic. In circumstances such as these, you may want to edit the rule and redefine its focus. Either disable the rule altogether or create exceptions to those machines generating the alerts. You can also narrow the focus of the rule. Sometimes user-created rules are not specific enough or use non-unique characteristics to trigger an alert. Careful analysis of the characteristics of captured attack traffic allows a more specific and accurate rule to be created.

Physically check the machines generating the alerts, if at all possible. If a machine generates alerts within your local network or WAN, log in securely to that machine and verify that no one else is causing the type of network traffic generating the alerts. Chances are the machines are not compromised but are sending valid network traffic that happens to trigger an alert. If the alerts are originating outside your network, check the machines being targeted. If they are high-profile, the alerts may in fact be valid. However, your machines may simply be issuing their own queries outside the network and the replies are being logged as an alert.

Be careful not to discount alerts and deem them false positives too quickly. Check the rule causing the alerts first. Portions of the signature that match the offending packet can be found within the rule. Make certain the machines affected by these alerts have not been actually compromised. Finally, check the alerts themselves to make certain they are truly benign and can be safely ignored. The importance of actually looking at the packet that generated the alert using an interface like ACID cannot be overemphasized.

Sometimes false positives indicate a non-security-related issue, such as faulty hardware, misconfigured network equipment, or poorly (or oddly) written network-aware software. While not a security issue, these can be important issues for a network or system administrator. Don't disable a rule or ignore a series of alerts without investigating the root cause.