|< Day Day Up >|
The Problem of NIDS False Positives
One of the main problems with intrusion detection systems is that they tend to generate a lot of false positives. A false positive occurs when the system generates an alert based on what it thinks is bad or suspicious activity but is actually normal traffic for that LAN. Generally, when you set up an NIDS with its default settings, it is going to look for anything and everything that is even slightly unusual. Most network intrusion detections systems have large default databases of thousands of signatures of possible suspicious activities. The IDS vendors have no way of knowing what your network traffic looks like, so they throw in everything to be on the safe side.
Common Causes of False Positives
Network Monitoring System Activity
Many companies use a Network Monitoring System (NMS) such as HP OpenView or WhatsUp Gold to keep track of the systems on their networks. They generate a lot of polling and discovery activity on your network. These systems usually use SNMP or some similar protocol to get the status, but they may also use pings and other more intrusive tests. By default, most detection systems see this activity as hostile or at least suspicious. An NMS on a large network can generate thousands of alerts per hour if the IDS is set to flag this kind of activity. You can avoid this by having your NIDS ignore activity to and from the IP of your NMS. You can also eliminate those NIDS alerts from the database if they are not something important for you to track.
Network Vulnerability Scanning/Port Scanners
If you are doing network vulnerability testing or port scanning using programs like Nessus and Nmap, then your NIDS is going to go nuts every time they run. These programs are designed to do exactly what hackers do. In fact, there is probably an alert for most Nessus plug-ins. Once again, you could disable reporting of the IP address of your Nessus or Nmap server within your NIDS. A better way to handle this is to shut down your IDS during your regularly scheduled scans. This way, the scanner box is still protected from attack when it is not scanning and your alert database isn't skewed with a lot of data from your own scanning activity.
Most network intrusion detection systems are set up to flag various dangerous user activities, such as peer-to-peer file sharing, instant messaging, and so forth. However, if you allow this kind of activity either by formal policy or simply by not enforcing existing policies, then it will show up as alerts in your logs. This may make a good case for enforcing or creating policies against their use, because you can show how much bandwidth and time they are eating up, not to mention the security implications. However, if you intend to keep allowing this activity, you should comment out these rules so you won't fill up your logs with erroneous alerts.
Trojan Horse or Worm-Like Behavior
Modern viruses and virus-like software such as worms and Trojan horses are often network-aware. They attempt to perform various activities across the network, including infecting new machines and sending mass e-mails. These activities can be detected by an NIDS. However, these signatures can send alerts on normal activity as well. An example is the Nimda worm, which attempts to copy over numerous system files with certain extensions such as .eml. Unfortunately, Microsoft Exchange does the same thing when using its Web interface. So while being aware of Trojan-like activity on your network is valuable, you may want to turn off alerts that pick up known good activity on your LAN even when there is the potential for it to be bad traffic. This will help you to avoid being overwhelmed by false positives from your NIDS.
Long Basic Authentication Strings
This alert type looks for Web login strings that are overly long, because some exploits use this method to overflow a buffer and gain access. However, nowadays many Web sites cram a lot of information into this field and can trip off the NIDS unintentionally.
Database Authentication Activity
Some network intrusion detection systems look for administrative activity happening on a database. The theory here is that production databases should not have too much administrative activity going on, and this might be the sign of someone trying to tamper with a database. However, many databases are works-in-progress and have lots of administrative activity even while they are being used. This activity, though legitimate, will generate a lot of these types of alerts. If your databases are under constant development, then you should probably disable these alerts, at least until they are stabilized and put into production.
There are many other sources of false positives, depending on your network configuration and level of activity. An NIDS with default installations can generate hundreds of these false positive alerts in a single day. This can lead to a sense of despair for the system administrator; the resulting reaction is often that the alerts from these systems are soon ignored because of all the noise they generate. However, with a little work and using the techniques described in this chapter, an IDS can quickly become a helpful tool rather than the electronic version of the boy who cried wolf.
|< Day Day Up >|