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