8.2 IPS Deployment Risks

The promise of intrusion protection is very attractive, but there are some risks that are not obvious at first glance. These risks should be considered when planning to deploy an IPS—including Snort operating in one of the IPS modes. There is, without question, a place for IPS in most environments. Most often, its value can be best utilized as another layer in a robust defense-in-depth strategy. Some of the risks associated with IPS are:

Session interception IPS identification

When a Snort sensor detects an attack and terminates the TCP session with a RST packet, the characteristics of the packet may allow the attacker to determine not only that an IPS was responsible for the terminated session, but the type of system the IPS software is running on. There are a number of passive operating system identification tools that analyze how different operating systems craft and transmit packets and are then able to make a guess at the underlying operating system. One such tool is p0f (Passive OS Fingerprinting Tool). By simply listening to the packets on the network, p0f can determine what type of machine sent the RST packet, allowing the attacker to make a guess at just what IPS solution is causing the difficulty. Knowing what he is up against allows him to craft his attacks to escape the notice of the IPS, or to find a way to crash or crack the IPS itself.

Exploit beating the attempted block

If there is a slight lag between the time the IPS detects the attack and when it orders a change in the access control lists of the border device, an attack might succeed in exploiting the target and establishing a "backdoor" connection to another system in the attacker's control. Even when everything works as planned with the IPS and the border device, it may be too late—another argument in favor of adopting a defense-in-depth strategy.

Self-inflicted denial-of-service

Altering the source IP address of a packet is a trivial thing. The packet still arrives at the destination and may still trigger an IPS to order an access control list change on a border router or firewall, thereby blocking the forged source address. If this forged source address is actually a system that the network needs, a denial-of-service condition results. Spoofing the address of DNS servers prevents name resolution. Spoofing a mail gateway address stops email from flowing. Forging routing peers for border devices (BGP neighbors) can stop all traffic from being routed to the Internet as routing protocols adjust. Most IPS solutions try to take this into account by utilizing an exclude list (sometimes called a white list), which contains addresses that should never be blocked, preventing a denial-of-service. The only problem is ensuring that the exclude list is complete.

Blocking legitimate traffic

If legitimate traffic is incorrectly identified as an attack and the traffic is blocked by the IPS, it can have serious consequences. Here's an example. A large ISP in the Midwest hosts a customer that sells clothing from a web-based catalog. A very popular daytime talk show host mentions how nice the web site is and the millions of viewers all sprint to their computers to buy sweaters and rugby shirts. At first, this looks like some kind of denial-of-service attack, flooding the network and potentially overwhelming the servers. If an IPS incorrectly identifies this unexpected activity as an attack and blocks the millions of inbound connections, the customer would have lost a great deal of money. Careful consideration should go into the kind of traffic that triggers an alert and the thresholds that represent something to be worried about.

There is no real rule of thumb to follow. You must understand how your network operates in its normal (and even extreme but normal) capacity. The best advice when considering an IPS is to run it in a test mode for an extended period of time, watching what it does during the course of business, and tuning the thresholds and alerts so that legitimate traffic is not blocked. A thorough analysis of blocking events should be performed over the course of the life of the IPS to ensure the accuracy of your testing and assumptions.

False positives can caues an IPS to block legitimate traffic. Extreme care must be taken to only enable blocking actions for alerts that almost never generate false positives. Such precautions may allow some attacks through, but they will stop those that are certainly trouble.