Rate-based IPSs detect detailed changes in traffic flow.
By Joel Snyder, David Newman and Rodney Thayer
Network World Global Test Alliance, Network World, 02/16/04
Original Article on Network World Web Site
We deployed four rate-limiting intrusion-prevention system products on our live, three-site network. Those products were Captus IPS 4100 from Captus Networks, Sleuth9 from DeepNines Technologies, Attack Mitigator IPS from Top Layer Networks and NetProtect LG100 from Vsecure Technologies.
Our criteria for testing these products followed the requirements of any network professional using one:
• How does the product let you define what traffic to control and set the limits?
• How can you define policy on the IPS regarding what it should do when limits are exceeded? How well does it execute that policy?
• What does it offer in terms of tuning and discovery tools?
• What does it offer by way of management
wares?
• Are there content-based IPS or basic firewalling included?
Attack Mitigator IPS quickly moved to the top of the heap because of its comprehensive tools for managing multiple kinds of distributed denial-of-service (DoS) attacks.
Identifying the bad guys
Rate-based IPS devices must provide detailed control of traffic flow. Tuning the IPS means telling it which traffic to look at and what the limits are on that traffic. We discovered wide variation in product capabilities and in how much you must know about your network to use them.
All four products let you define what applications and servers you want to protect, usually by identifying a combination of source and destination IP addresses, along with source and destination port and protocol. In most cases, either the source or destination address will be a wildcard (indicating "the Internet"). For example, you might limit queries to your DNS server to 1,000 per second. Simple rules covering bandwidth and connection limiting (often called SYN flood protection) are something you can do in any rate-based IPS.
In terms of providing sophisticated rate controls, Attack Mitigator IPS maintains knowledge of connection state for traffic flowing through it. While other products can detect floods of traffic or connection requests, Attack Mitigator can tell whether connections are being built up slowly on a protected server. That intrusion technique, common in DoS attacks, could slip by the other products.
A similar, but not as powerful, feature is in NetProtect LG100. You can define a connection flood protection for a service on a particular system, but you can't say how many connections that service can support. You have to pick one of four values for "sensitivity": minor, low, medium or high. Neither Vsecure's GUI nor its documentation gave sufficient meaning to what those values are. NetProtect detects idle connections building up from a single source, but not more sophisticated attacks that slowly keep sending small bits of data or are distributed across a large number of systems.
Other types of limiting technologies these products offer might be useful in environments where the traffic mix and parameters are known. For example, Captus lets you make decisions based on average packet size, while Vsecure detects the mix of protocols (TCP vs. User Datagram Protocol [UDP] vs. Internet Control Messaging Protocol) and can shut things down if the mix doesn't fit within your parameters. That's an interesting idea, but gathering the data to apply these controls is a difficult exercise.
We ran into design issues with some of these products. The most severe was in Sleuth9's adaptive filtering feature called "spike protection." DeepNines engineers could not tell us exactly what the algorithm for spike protection is but did say that it limits traffic automatically whenever a system's load exceeds historical levels. So if you have a back-up server that kicks in every night, the Sleuth9 could start dropping packets. Worse, you can't tune or disable that feature.
Once an IPS identifies that reconnaissance activity or an attack is happening, the bigger question is: What are you going to do about it? For certain kinds of attacks, such as a port scan or a Code Red worm, the obvious answer is drop those packets. When you get into rate-based IPS, the options get more complex, and the issues at hand, more subtle.
The IPS 4000 offered the most sophisticated set of reaction options. You could identify an overload on an FTP server, for example, and initially start throttling traffic for a minute. If the overload continued, you could cut off access from the client overloading the server. If things went on for several minutes, you could send an alert. In all, Captus gives you four responses to bad traffic: send an alert, limit traffic levels, drop traffic entirely and reroute traffic.
NetProtect and Sleuth9 offer the ability to block or limit traffic, but Top
Layer adds a third option: connection proxying. This lets the Attack Mitigator
protect systems before they are overwhelmed. In addition to limiting the number
of connections, you can set thresholds for incomplete TCP connections that indicate
suspicious behavior. Once these limits are surpassed, new connections will be
proxied by the Attack Mitigator. If the connection completes, then Attack Mitigator
passes the connection to the actual server. If things get worse, Attack Mitigator
will start blocking all connections from malicious attackers.
Setting expectations
The biggest problem with deploying rate-based IPS products is deciding what constitutes an overload. For any rate-based IPS to work properly, you not only need to know what "normal" traffic levels are (on a host-by-host and port-by-port basis) but also other network details such as how many connections your Web servers can handle.
We expected help from these products in terms of network infrastructure discovery and network traffic patterning. Except for Top Layer, we were disappointed. Top Layer offers a documented methodology for putting its product into a network, including built-in tools that let you monitor your traffic, determine peak and average loads, and then use that to build your protection rules.
Some vendors insisted their basic installation includes a visit by a system engineer. When the DeepNines system engineer came to our lab, we asked how many weeks they'd have to baseline their product in a real customer installation to set levels properly. The system engineer estimated an hour and suggested we get a protocol analyzer. Vsecure's NetProtect came with a network host and service discovery tool, but it didn't provide long-term statistics, thereby only giving us half the picture needed to properly configure it.
The methodology question was most troubling with Captus, which has a 12-step methodology program, but it's a one-time process assisted by a trained system engineer. The IPS 4000 itself doesn't provide good performance statistics, which is a shame because the product is the most labor intensive to configure. The problem with any rigorous methodology, including Captus', is that the cost to tune the product is high and thus discourages changes, even though traffic patterns change continually.
Management styles
IPS management was very inconsistent. Our litmus test was whether each device offered an alert-only mode where it watches for bad packets but does not block them. With Top Layer and Vsecure, it's trivial to flip the device into and out of alert-only mode. For DeepNines and Captus, changing mode means making bigger - not easily reversible - changes to the configuration.
Other management features varied from the simple to the Byzantine in scale and presentation. Top Layer, with its device-based Web configuration tool, was modest in its presentation. Top Layer let us configure a single IPS quickly and without confusion. The downside is that Top Layer's management tool is an element-based configuration utility and as such won't scale if you wanted to manage multiple devices. The vendor's optional SecureWatch tool aggregates and displays statistics from multiple devices, but that's as far as it goes.
Captus, DeepNines and Vsecure brought in more elaborate tools to handle multiple IPS devices. Although central management was an enterprise-oriented feature with these three products, none let us manage the configuration on more than one device at a time. We found bugs in DeepNines' and Vsecure's systems. The Vsecure's GUI was happy to let us change configuration within the management system. However, to actually activate changes, you have to push them out to the device. At which point we found the GUI occasionally crashes.
Captus' overall management scheme puzzled us. It's massive, with graphical elements sitting all over the place, zooming in and out, and providing multiple views of network topology. But it only talks to the IPS devices. It seems that Captus started with an enormous concept of a carrier-class network management station and then seriously underutilized it in its enterprise IPS product. At the same time, the part of the GUI used to manage the parameters of the IPS was almost ignored. Defining a policy for the Captus product would be much easier from the command line - a nod to the Cisco-familiar workforce that likely would install and configure this product.
Beyond rate-based controls
The most common additional feature shipping with these products was a firewall, either stateful or simple packet filtering. All can block traffic and act as a basic firewall, limiting exposure to services that should not ever be accessible through the IPS device. All products also could identify and block port scanning.
Beyond that, DeepNines, Top Layer and Vsecure had some capability to block protocol-based attacks, such as illegal TCP flag combinations used by hackers during reconnaissance. DeepNines also was able to look for viruses, and Top Layer bridged into the content-based IPS world by also scanning for known problem URLs.
With a clear focus on the problem of DoS and distributed DoS attacks, Top Layer brings together all the tools needed to protect against the widest variety of intentional and unintentional problems. Captus' IPS4000 had an astonishing level of detail and control when it comes to managing packet flows. The Captus product fits better into a service provider or corporate Web hosting environment where you can get a precise measure of what it is you want to do in a static environment. DeepNines and Vsecure fit better into our model of a small network with light and constant loads.