Feature

Is intrusion prevention better than cure?

Bob Walder, director of independent network security testing specialist the NSS Group, assesses the benefits and limitations of network intrusion prevention systems.

While most intrusion detection systems tend to be reactive rather than proactive - they have to wait until something has happened before they can raise the alarm - intrusion prevention systems attempt to be proactive.

An IPS is designed to stop intrusions dead in their tracks, blocking the offending traffic before it does any damage, rather than simply raising an alert after the malicious payload has been delivered. It achieves this by sitting directly in line with the network traffic - one network port accepts traffic from the external system, and another port transmits it to the internal system after it has been checked for anomalies or suspicious content. Problem packets, and all subsequent packets from the same data flow, can simply be discarded within the IPS appliance.

As with IDS systems, IPS products tend to fall into two categories: host IPS (HIPS) and network IPS (NIPS).

HIPS products rely on agents installed directly on the host system being protected. They interact closely with the underlying operating system and resident services in order to detect and prevent rogue system calls.

NIPS (sometimes known as in-line IDS or gateway IDS) could be thought of as a hybrid system, combining features of a standard IDS and a firewall. Like a firewall, the IPS appliance will sport at least two network interfaces: one designated as external and one as internal. Some appliances may have more that two interfaces in order to monitor multiple network paths, but the basic requirement is for two interfaces for data and one for management.

Placed in-line in a critical data path, the IPS detection engine examines packets as they pass through the device and processes them in a similar manner to an IDS in order to determine which packets are suspicious in nature. If a suspicious packet is detected, that packet can be dropped immediately, and all subsequent packets from that particular data stream can be discarded without further processing.

Naturally, an IPS will also raise an alert in the same manner as an IDS, and this allows the IPS to operate in traditional "IDS mode" as well. This is useful because it enables the administrator to tune the system before placing it in full-blown "prevention mode".

Legitimate packets are passed straight through to the internal interface and on to their intended destination. A useful side effect of some NIPS products is that, as part of the initial detection process, they will provide "packet scrubbing" functionality to remove protocol inconsistencies resulting from varying interpretations of the TCP/IP specification (or intentional packet manipulation). Any fragmented packets or packets containing obfuscated URLs will be "cleaned up" before being passed to the destination host.

There are a number of challenges in implementing an IPS device that do not have to be faced when deploying passive-mode IDS products. These stem from the fact that the IPS device is designed to work in-line, presenting a potential choke point and single point of failure.

If a passive IDS fails, the worst that can happen is that some attempted attacks may go undetected. If an in-line device fails, it can seriously affect the performance of the network. Perhaps latency rises to unacceptable values, or perhaps the device fails closed, in which case you have a self-inflicted denial of service condition on your hands. On the bright side, there will be no attacks getting through, but that is small consolation if none of your customers can reach your e-commerce site.

Bottleneck

Even if the IPS device does not fail altogether, it still has the potential to act as a bottleneck, increasing latency and reducing throughput as it struggles to keep up with up to a gigabit or more of network traffic.

Devices using off-the-shelf hardware will certainly struggle to keep up with a heavily loaded gigabit network, especially if there is a substantial signature set loaded. This could be a major concern for both the network administrator, who could see his carefully crafted network response times go through the roof when a poorly designed IPS device is placed in-line, and the security administrator, who will have to fight tooth and nail to get the network administrator to allow them to place this unknown quantity among his high-performance routers and switches.

Dropped packets are also an issue, since if even one of those dropped packets is used in the exploit data stream, it is possible that the entire exploit could be missed. Some IPS suppliers get around this problem by using custom hardware - indeed, it may be necessary to design the product to operate as much as a switch as an intrusion detection and prevention device in very heavily loaded networks.

It is difficult for any security administrator to be able to characterise the traffic on the network with a high degree of accuracy. What is the average bandwidth? What are the peaks? Is the traffic mainly one protocol or a mix? What is the average packet size and level of new connections established every second?

If your IPS hardware is operating "on the edge", all of these are questions that need to be answered as accurately as possible in order to prevent performance degradation. However, if the IPS device is rated at wire speed (either 100mbps or 1gbps) it becomes a lot easier to simply drop the device in-line, safe in the knowledge that all normal traffic will pass through transparently. Determining which devices are capable of operating at such high speeds without introducing bottlenecks is not straightforward for the end-user, however, which is where independent third-party testing comes in.

Another potential problem is the false positive. The bane of the security administrator's life, the false positive rears its ugly head when an exploit signature is not crafted carefully enough, such that legitimate traffic can cause it to fire accidentally. While merely annoying in a passive IDS device, consuming time and effort on the part of the security administrator, the results can be far more serious and far-reaching in an in-line IPS appliance. Once again, the result is a self-inflicted denial of service condition, as the IPS device first drops the offending packet, and then blocks the entire data flow from the suspected hacker.

Lost business

If the traffic that triggered the false positive alert was part of a customer order, you can bet that the customer will not wait around as their entire session is torn down and all subsequent attempts to reconnect to your e-commerce site are blocked by the well-meaning IPS.

In some respects, performance and detection capabilities are the least of the problems facing the administrator tasked with deploying these devices. The problem with any gigabit IPS/IDS product is, by its very nature, the amount of alert data it is likely to generate. On a busy network, how many alerts will be generated in one working day? Or even in one hour?

Even with relatively low alert rates of 10 per second, you are talking about 36,000 alerts every hour. That is 864,000 alerts every day. The ability to tune the signature set accurately is essential in order to keep the number of alerts to an absolute minimum. Once the alerts have been raised, however, it then becomes essential to be able to process them effectively. Advanced alert handling and forensic analysis capabilities - including detailed exploit information and the ability to examine packet contents and data streams - can make or break a gigabit IDS/IPS product.

There are a number of features that are essential in a true IPS product. Probably the most important is the ability to operate in in-line mode. This may seem like a superfluous requirement given the nature of the product, but since some IDS suppliers are claiming "intrusion prevention capability" in their marketing campaigns - which usually turns out to be nothing more than sending TCP reset commands across the wire or reconfiguring a perimeter firewall - it is an important distinction to make up-front.

Unless a device is placed in-line, it is extremely difficult to perform any kind of guaranteed prevention. In most cases, sending TCP resets or reconfiguring firewalls are ineffective prevention mechanisms - by the time the response has been completed, the payload has probably been delivered. The only way to stop a packet (and the rest of the data flow to which it belongs) dead in its tracks is to operate in-line.

The problem with working in-line, of course, is that there is always the potential to affect performance and the reliability of the rest of the network. If the IPS device fails open, the worst that can happen is that you miss an exploit. If it fails closed, you could cut off all external access to and from your network completely. Reliability is therefore essential.

The IPS appliance must offer the maximum up-time possible, and should not require a reboot to apply signature updates. Given that it can represent a single point of failure, it would be nice if it offered some form of failover mechanism for those sites that require guaranteed 100% availability.

As far as performance is concerned, the wish list would have "zero packet loss" and "zero latency" at the top. Zero packet loss under all normal loads is essential, of course, if the device is not to run the risk of missing exploit packets. Unfortunately, given the amount of processing that these devices have to perform for the majority of the packets passing through them, increased latency is something we will have to live with - but it should be kept to a minimum.

Signature coverage

Broad and accurate signature coverage is also essential. Bear in mind that if you are going to place your IPS device in-line and turn on the blocking mechanism, you had better be confident that the signatures you have deployed are not prone to false positives. If you do not want to run in blocking mode, or if you want to block only a selected subset of signatures, then you still require a signature set that is comprehensive enough to allow the device to operate as an effective IDS.

There are other key requirements that are common to both IPS and IDS devices: a good alert handling and reporting mechanism; centralised management and configuration; flexible policy definition and deployment; and regularly updated signature sets, to name but a few.

This is a very interesting market and things are moving very quickly indeed. No sooner have we started to notice a broader adoption of IDS than we are already seeing them referred to as "legacy" systems.

IDS suppliers are fighting back by claiming intrusion prevention capabilities of their own, and the resulting marketing spin put on by both parties can only serve to muddy the waters for security administrators tasked with determining which is the best product for their environment. It is important to remember, however, that IDS devices were never designed with IPS in mind - they are detection mechanisms, not prevention devices. It is a little harsh to beat them up over an inability to prevent attacks - that is like buying a pair of Wellington boots and then moaning that they don't stop your head getting wet in the rain.

So called "legacy" IDS systems are likely to be around for a long time yet, and in many organisations there is probably a place for both technologies, at least for the time being.

Testing IPS systems   

The NSS Group spends a lot of time creating the methodologies for its tests, and in-line IPS devices have proved the most challenging to date. First, the performance as a pure network device is measured: how quickly it can process packets and how many it drops under various loads.  

Then its effectiveness as both a detection and prevention device is tested. Replay tools that provide a quick and easy means of testing passive-mode IDS products are no use for in-line devices, since testers need the stateful traffic to pass through the device in order to test detection capabilities - real exploits are the only way to go. 

Finally, detection performance is measured under real-world traffic loads. NSS has invested in multiple Layer 7 traffic generation devices from Caw Networks which allow it to model real-world user behaviour and generate realistic session-based web, FTP, DNS and video/audio streaming traffic from up to two million users at up to 2gbps and 20,000 connections per second. Against this background traffic, testers launch numerous real exploits and monitor how effectively the device detects, alerts and blocks the exploit traffic. 

The results of NSS' IPS research will be seen in its next big group test report - IPS Edition 1 - which will be published later this year.

Bob Walder, a leading authority on network security, is one of the founders of the NSS Group and author of the NSS report, Gigabit IDS Group Test (Edition 1), which is available from the NSS website.  

The NSS Group is Europe's foremost independent security testing facility. Based in the UK with separate security and network infrastructure testing facilities in the South of France, the NSS Group offers a range of specialist IT, networking and security-related services to suppliers and end-user organisations throughout Europe and the US.   

Output from the labs, including detailed research reports, articles and white papers on the latest network and security technologies, are made available on the NSS website. 

A new report providing a detailed examination and extensive benchmarking of all the major players in the intrusion prevention systems market is currently in the testing phase, with publication due in the autumn of 2003.  www.nss.co.uk/gigabitids


Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

This was first published in April 2003

 

COMMENTS powered by Disqus  //  Commenting policy