One of the most basic considerations when deploying a network intrusion detection system is where to place the sensor or sensors. The intuitive decision is to place a sensor at a point where it will see all traffic in and out of the network. This is often between the edge router and the firewall. Typically, the sensor will analyze all the traffic in and out of the network. My observation is that this approach results in one of the largest problems of intrusion detection, alert overload.
My first attempt at using a network intrusion detection system followed this typical pattern. The sensor host was placed where it could see all traffic to and from the router that connected the network to the Internet. The network intrusion detection system was Snort. After tweaking the configuration file so that Snort would know what our "home" network was, the IP addresses of the servers providing legitimate services, etc., I started Snort.
Logging began in earnest. A few minutes were enough to produce logs it would take hours to analyze. Alert overload. This would be the major problem of using a network intrusion detection system at the edge of the network where it would see unfiltered traffic from the Internet.
I use the phrase "alert overload" because the alerts being generated were not, strictly speaking, false positives. The network intrusion detection system alerted only about network traffic its rule set was intended to describe. There were three main reasons I was not interested in the vast majority of these alerts.
The first was that some matched traffic which might be suspicious entering or exiting some networks but was not suspicious in the specific case of this network. The second reason was that the NIDS was detecting a huge number of actual, doubtlessly automated, attacks targeting vulnerabilities we did not have. The third reason was that there were some attacks that I might have been interested in if there were five per day and I thought there was a human directing them, but when there were 500 or 5,000, and they almost assuredly were automated attacks from compromised systems, there was no realistic way to address those alerts.
What I had was a needle-in-the-haystack problem. It was possible that there were alerts in the logs that indicated a problem I should address. Finding these alerts was not feasible. Snort provided mechanisms for addressing this problem, and I assume other network intrusion detection systems do, as well. The two main mechanisms Snort provided for limiting extraneous alerts are identifying servers that provide standard services, such as DNS or SMTP, and choosing the rules that you use. In this way, the network intrusion detection system knows, for example, if a certain host should receive large amounts of traffic to port 53. Also, you can choose not to use rules that match DNS traffic, if those rules generate excessive alerts. These mechanisms were not sufficient to address the alert overload problem.
Another popular strategy is to address alert overload not on the traffic analysis side, but on the log analysis side. These strategies usually involve logging to a relational database and using some frontend to construct queries to the database and display the results in a meaningful way. For example, I had Snort log to a MySQL database and used ACID to analyze the logs. This was most useful by helping identify what rules were being matched most often, and so could be removed. This helped, but not enough.
My analysis is that there are so many automated scans and attacks pouring in from the Internet, and so many different vulnerability profiles for different networks, that the signal-to-noise ratio on the perimeter of the network is too low to effectively analyze incoming traffic.
There is an alternative model for doing network intrusion detection at the edge of the WAN. The solution is to move the network intrusion detection system inside the firewall. The firewall will block much of the "noise", hopefully reducing the network intrusion detection system logs to a useful volume.
If, however, you have a more complicated network, with multiple layers of filtering, or a DMZ that needs monitored, consider doing network intrusion detection at the edge of the network, analyzing only outbound traffic.
When Code Red took the Internet by storm, one of the network administrators I worked with started Snort with a single rule. It matched Code Red attacks leaving our network. This was successful at determining who on our network was infected. In discussions with our administrators, I found that many of them have used similar strategies in the battle against worms. It is a case of network intrusion detection unambiguously providing value by delivering limited, actionable information.
This strategy can be expanded. If you restrict your network intrusion detection system to examining traffic leaving your network, you do not need to dramatically restrict the ruleset it is checking against. You ignore the constant probing from the Internet for vulnerabilities you are mostly immune to, and catch the instances where you have been compromised. This is an alternative to having so many alerts that you miss a successful intrusion.
Another reason for this approach is that you can do something about what you find. When you detect an intrusion attempt from the Internet, it is often difficult to do anything about it. If you focus your attention on your outbound traffic, you focus on a problem you have the ability and the responsibility to address. If the majority of network operators could prevent attacks from leaving their network, we would see a dramatic decline in attacks entering our networks.
This strategy does not preclude doing intrusion detection on incoming traffic deeper inside the network, where much of the flotsam and jetsam of the Internet has been blocked. If you have firewalls in your network, you might place one sensor just inside your border router that only inspects outbound traffic. You might also have a snort inside the firewall or firewalls that inspects both inbound and outbound traffic. This would keep you informed of what does make it through the firewall, and traffic is hopefully filtered enough that alerts will not be overwhelming.
To facilitate this strategy, network intrusion detections systems should provide an easy way to monitor only outgoing traffic. They could provide alternative rule sets that contained rules that matched:
In a case like Snort, where the rules are contained in text files, a Perl script that commented out rules that matched incoming traffic could be distributed with the network intrusion detection system. In a product configured by a GUI, a checkbox option that read "Analyze outbound traffic only" would be appropriate.
Every approach has flaws. The main problem with this strategy is encountered after you have detected a compromise and you want to analyze how the compromise was achieved. If you are doing no analysis of incoming traffic at the perimeter, you will likely be missing pieces of the puzzle when you analyze how the network was compromised.
The best solution I can find is to run a separate sensor which does analyze incoming traffic on the perimeter, and sends its logs to a separate destination. Once you have detected an intrusion with the outbound analysis, you will have clues, such as IP addresses, to help comb the copious logs of inbound traffic for evidence. This sensor could be another instance of the same network intrusion detection system that analyzes outbound traffic, or a different network intrusion detection system altogether. For example, SHADOW was suggested as particularly good for this role by a peer who read an earlier draft of this article.
This is an imperfect solution. The administrative burden of maintaining two separate intrusion detection systems will be prohibitive for many network operators. Still, the value of ignoring garbage in and catching garbage out is real.
Thank you, in alphabetical order, to Charlie Winckless, Chester Smith, and Drew Einhorn for feedback on an earlier draft. Also, thank you to my wife, Jae, for reading it and assuring me that the concepts are clear to a non-geek.