IPS. You need it.

Today, most networks are protected by firewalls. Even home users get the idea. There are numerous types of firewall, but they all work in the same way: allow in the authorised traffic, filter the rest. The majority of pure bred firewalls do not apply any further filtering on the traffic beyond IP and service port values. In the beginning it was as simple as blocking IP addresses and filtering ports. The first firewalls didn't even understand ports.

However, complex modern attacks utilise any number of attack vectors. Attacks make use of otherwise legitimate connections through firewalls. Traffic that looks to be normal may actually part of a nasty attack. Attacks can utilise protocol implementation flaws, buffer overflows, application development errors, and even social engineering techniques such as phishing. To protect against these attacks it is necessary to look deeper into the traffic streams to gain application awareness. Protecting against distributed denial of service (DDOS) attacks launched from one of the many botnets which are available for hire is also far beyond a traditional packet filtering firewall. These attacks are also beyond some of the more common and very expensive stateful inspection firewalls too.

Trusted network? Yeah right.
As you probably already know a large percentage of attacks originate from inside the network perimeter. Figures between 70 and 95% have been quoted over recent years. It's a difficult figure to pin down as attack patterns shift to regularly. The precise value doesn't matter; most security breaches originate from an internal machine. The "Best Practise" networks designs that many consulting firms still have as their mantra are often out of date. They pretty much dictate a well protected exterior shell (read: firewalls) with an open interior. This actually means that the majority of network traffic does not pass across a firewall; even advanced ‘deep packet inspection’ and ‘application aware’ firewalls cannot check traffic which does not go through them. So we need 'deep packet' firewalls everywhere. Great.

The first breed of application aware systems known as Intrusion Detection Systems (IDS) appeared in the mid 1990s. The majority were based on signatures which aimed to match specific malicious traffic patterns. This is how antivirus works. When a specific pattern was found, the network administrator could be alerted to the presence of malicious traffic on their networks. Initially, these systems did not perform any blocking of traffic, but only reported the fact.

Many argued that there was little point and likened the technology to “shutting the door once the horse has bolted.” Despite these claims, the technology served to increase awareness of complex network security issues amongst the network management community. Like the microscope had done for bacteria, IDS showed the characteristics of network attacks as never before.

Stop thief!
The main limitation of IDS was soon removed. In about 1998, detection became prevention and proper products started to emerge that were able to both block attacks. In some cases, existing products were enhanced with blocking capability. Whole new offerings also appeared to take advantage of this new market of paranoia where IDS had shown network admins what they were up against. Or not. Lots of people were too scared to turn it on. This has more to do with the unwillingness to allow an automated tool to drop network traffic than anything else. What if, shock horror, it blocked something by mistake? It just doesn't seem political to risk dropping the CEO's download of bigjugs.mov.

Various blocking strategies were employed depending on whether the device was designed to sit ‘in line’ or stand alone on the network. Intrusion prevention systems which sit ‘in line’ are placed so that all network traffic must pass through them. When the IPS decides to stop traffic, this has the advantage that blocking actions will be completely effective. The network design must force traffic through the device in order to maximise coverage. That gets tricky in complex networks. How do you deal with asymmetric routing and avoid putting bandwidth bottlenecks in place? So placement of the IPS becomes crucial to its effectiveness. What if the IPS device fails? Many include a ‘fail open’ relay which turns the device into a piece of wire once power is removed. That's great, but what if an attacker able to trigger this feature by crashing the IPS? (Hint: the military tend to fail closed.)

Stand alone systems are arranged so that they gain access to traffic streams from a switch span port or by utilising a network tap. Span ports tend to be a bit poor for the performance of the switch. In case you don;t know, a tap is a piece of hardware which allows the diversion and duplication of traffic at wire speed. This is a good, but disproportionally expensive option. There are two strategies employed to give the IPS blocking powers in this layout The IPS itself can send TCP RST (reset) messages which cause open connections to end suddenly. Or credentials can be supplied which empower the IPS to control firewalls and modify router or switch ACLs in order to dynamically block traffic. Even I'm not that brave...

A third alternative is to put IPS software on each host to be protected. This is like a software host firewall but performing IPS functions too. This means that the host can block malicious traffic directly. The disadvantage is implementation. The software must be deployed to multiple hosts, will use up resources when running, may not be compatible with all operating systems, and will require maintenance and upgrades. Oh, and it blocks poorly implemented application traffic sometimes. This means you have to employ better application coders.

Signatures rule, KO?
Whichever way you get nasty traffic to your IPS, there are a number of ways in which it can detect unwanted network traffic. There are three main categories: Signatures, traffic rates and anomaly detection. Signatures are the most common way to proceed. The majority, although not all, of IPS products include signatures of some kind. These are almost exactly akin to the antivirus signatures familiar to network administrators. A pattern within the network traffic is matched against the shape of a known attack. There are two subdivisions of the term: Signatures and Rules. These are alike, but fundamentally control the effectiveness of the deployment.

A signature is a pattern which identifies a specific known attack. A rule identifies the use of a known vulnerability. There is a subtle difference which can be understood using this analogy. Consider a glass window. This can be broken in any number of ways, including: a hammer, a thrown brick or a bullet. A corresponding signature based IPS for the window would match: “A person with a hammer”, “a brick in flight” and “an inbound high velocity round”. The IPS would recognise and block each of these attacks when presented exactly. An attack which uses a fire extinguisher would not be recognised – and would consequently succeed.

A rule based IPS, however, would have rules to block against the vulnerability itself. In this case, the vulnerability relates to the fragility of the window to percussive attack. This means that the rule would match “any massive inbound object which has sufficient momentum to produce a fracture of the glass”. In other words, “anything heavy or speedy which is about to hit the window” would be blocked.

In a computer network, the signature scenario might relate to the ability of the IPS to block worm variants A and B, but allow variant C straight through. A rule based on the vulnerability rather than the exploit would look for the behaviour that all possible variants of the worm would need to exhibit in order to compromise a system.

Zero Day Blocked?
Most tier one IPS vendors claim to block the vulnerability not the variant. Confusingly, they mostly discuss ‘signatures’ not rules but this is just semantics. In reality, when a major new attack evolves, initial signature updates are often issued which fix a single variant, while vendor labs are frantically working on a cure to the vulnerability itself. This is released as a replacement to the original update. Interestingly, many vendors produce a specific signature for each variant anyway, allowing network administrators the luxury of a report showing exactly which variant of the attack class has been foiled.

Sometimes, these claims are taken further and vendors offer the ability to stop a “zero day” attack. This is somewhat of a Holy Grail in the IPS world, because if this were true, there would be no need for further signature (or rule) updates. What is meant by these claims is that once a suitable rule is downloaded, any possible future attacks using a specific vulnerability will not succeed – in some senses avoiding zero day attacks, although not all future zero day attacks!

Signatures can also be provided to match any other interesting traffic rather than just attacks. For example, administrators might be interested to be alerted whenever a specific type of traffic is seen on a network: perhaps UNIX portmapper traffic (port 111) on a truly homogenous Windows network. This might not signify an attack – there may be nothing ‘wrong’ or malicious in the portmapper traffic itself - but may signify mis-configuration or the installation of unauthorised software.

Connection Rate Limiting
Another way to protect the network which does not rely on signatures is to apply connection rate limits. Slow it all down and the damage is much less. This method is particularly effective against denial of service (DoS) attacks. This class of attack often uses otherwise perfectly legitimate traffic to flood a network, using all available bandwidth and server resources. Of course, legitimate looking traffic will not be picked up by signatures or rules.

Limiting the number of connections requests allowed into a network will protect against flood attacks by keeping traffic volumes below bandwidth and server resource thresholds. If a host is generating superfluous volumes of traffic, this will be noticed and dropped once it reaches a defined level. However, this simplistic approach may also deny any new legitimate connections too.

This is particularly noticeable in the case of a distributed denial of service attack (DDoS), where the network flood originates from potentially tens of thousands of IP addresses. In a simple algorithm, there is no mechanism to determine which of these IP addresses is flooding the system and which are producing legitimate traffic. In the worst case, the IPS could actually assist in the denial of service!

The effectiveness of this mechanism can be enhanced by performing in-depth analysis of the traffic. To protect against a DDoS attack, it is necessary to detect and correlate attack packets converging from a disparate array of source IP addresses. For example, if nine hundred out of a thousand incoming connections have the same packet length and TCP checksum, it is likely that these are part of an attack; normal packets don’t all look the same. These can be blocked, while allowing the other hundred connections through.

Anomaly Detection
Anomaly detection techniques start by first defining a baseline of the network. This is usually done by having the system enter a learning stage for a number of weeks. During this period, the IPS analyses the traffic streams and builds a picture of the ‘normal’ behaviour of the network. This mechanism works best for green field networks where there is no risk that the network has already been compromised. How to filter out network traffic that is included into the baseline by an already present worm, spyware or other malicious activity? This is done by applying signatures to the traffic being analysed and weeding out anything which will not be acceptable once protection is fully enabled.

Once the baseline has been defined, anomaly detection works by noting any deviation from the norm. As no network behaves exactly as expected at all times and yet nothing untoward is happening, it is important to be liberal about what is defined as deviation. Fuzzy logic is used to dynamically adjust the threshold beyond which activity is deemed anomalous. A traffic spike between two systems that is fairly short in duration is a very different prospect from a prolonged increase in traffic from one host destined to a large number of hosts on the Internet. Clever anomaly based systems know this and can cope with these variations.

Coverage is King
The effectiveness of the deployment of IPS is often compromised by several factors. It is vital that IPS ‘sees’ as much of the network traffic as possible. The location of the system in the network affects this coverage. Concentrating the IPS at network ingress points such as firewalls has some advantages – many attacks do come from the Internet - but coverage of LAN traffic may suffer. Likewise, placing IPS on a data centre switch would protect servers, but may not pick up attacks involving the Internet and workstations directly. It's tricky to place and IPS - I should know because I spent 18 months (on and off) on a massive IPS project; the trickiest part was deciding where to put the damned things.

There are a number of IPS vendors whose hardware which is capable of protecting multiple network segments at once. An eight port IPS appliance, for example, might provide protections for four segments running in inline mode. The resources of the IPS system are shared amongst these four segments however, meaning that it is essential to ensure that the total volume of traffic across them all will be less than the IPS is rated to handle.

When specifying an IPS for a network, it is necessary to estimate the total traffic volumes which will pass across the device. This is particularly important in inline mode. The throughput and latency of the network can be directly affected by a poorly performing inline IPS. Choosing an IPS which is rated above the current traffic volumes will ensure that future requirements will be easily met. Often, powerful appliances are costly, meaning that the mistake of under specification is very real.

It is best practise to aim to provide coverage for the entire network wherever possible. One neat way to work towards this is to utilise a black hole route. The majority of enterprise networks utilise RFC 1918 ‘private’ addressing schemes.4 Knowing that a network contains only a small subset of these IP addresses, it is possible to define a set of routes which pass all other private addresses towards the a packet sniffing device (usually an IPS). This is like a default route, but only specifies private addresses which are unknown within the network; any traffic seen on these addresses is therefore immediately suspicious.

IPS Bypass
Many IPS vendors include a monitor only or bypass mode. This allows the administrator to see what the IPS “would have done” if protection had been enabled. For the timid (or cynical?) administrator, this allows them to become comfortable that the device is not going to make the wrong decisions on their network, resulting in blocked legitimate traffic. From experience, this is the main worry that administrators have when deploying an IPS. They are often greatly concerned about false positives not, as you might expect, whether the IPS will detect all the malicious traffic on the network.

One problem with the bypass or monitor feature is that it can be used to return the system to a pre-deployment stage whenever a problem occurs. Quite often, problems with ‘legitimate’ traffic being blocked are due to poor coding in applications, leading to non-RFC compliance. Rather than the wayward code being fixed by the developers, the active protection provided by the offending signature is disabled on the IPS – all in the name of mission critical traffic. If it is mission critical, surely it is worth coding the application correctly?

Sometimes the availability of this feature means that the IPS becomes no more than a tick in an auditor’s box, never being turned on for real. Like the firewall installed but implemented with an open ‘any accept’ policy, an IPS in this mode will allow all traffic through malicious or otherwise. Unlike that firewall, at least the events will be logged and can be acted upon. Often, however, the actual improvement to network security is negligible; these are exactly the administrators who would not look at the output anyway!

Don’t cry wolf!
When deploying an IPS, it is usual to have to perform some tuning for the first few months. This is necessary to normalise the traffic which the IPS blocks. The amount of tuning depends on a number of factors including the complexity of the network, the quality of vendor signatures and the effectiveness of network base lining exercises for rate limiting and traffic anomaly based systems. The task of tuning is rarely ever wholly finished, as networks change topology, purpose and content organically. The IPS must be adjusted to understand what is acceptable and what is not as the network evolves.

During the initial post installation tuning phase, an IPS can generate a very large number of alerts. Unless a poor choice of default filters has been made by the by the vendor, it is not usual that it will block traffic unduly. However, it is usual to find signatures present which perform an auditing function as well as the discovery of malicious traffic. Examples might include detecting all HTTP ‘POST’ operations, noting the presence of Skype or Windows Live Messenger traffic, listing every Windows master browser election or any number of other common traffic patterns. All of these types of signatures could generate many hundreds or thousands of alerts per day.

As we teach children, it is not sensible to erroneously ‘cry wolf’ too often. (I wish my kids would actually learn this, though.) Unfortunately, in the tuning phase, the IPS may cry wolf many, many times, generating a huge array of alerts. These seem interesting at first, but poring over them constantly for a few days will eventually lead to apathy in even the most hardened security professional. False positives and over alerting mean that the job of the network administrator becomes more onerous. This is unfortunate as most IPS products can be tuned to perform valuable blocking operations almost silently, while reporting only the most relevant information to their masters – it just takes some initial effort to get there.

One effective approach to tuning is to perform it on paper first during planning, before even installing the IPS. Having some idea what traffic is expected on a given segment will allow the tuning to take place quickly post installation; knowing for example that there is no UNIX traffic on a segment, but that Windows NetBIOS files sharing is normal leads to some instant and sweeping tuning decisions. To make best efforts at tuning, it is necessary to understand the network fully and appreciate what kind of traffic is present.

The Future is Bright
The addition of a Security Information Management system (SIM) to the solution allows the correlation and management of the alerts generated. These alerts are taken from number of security sources including firewalls, content filters, anti virus and intrusion detection and prevention systems. The normalisation and correlation of these alerts means that, for example, a logon failure detected by a firewall and an IPS can be compared natively. This leads to reports which are more meaningful; they can include only the most important alerts.

Many large organisations now rely upon IPS to protect their networks alongside firewalls and content filtering solutions. A number of IPS vendors now market their products as providing ‘network patching’ as a stop gap until security patches are applied. Even the marketing of these systems is clear that administrators still need to apply updates to their servers eventually.

The future is always difficult to predict within the field of information security. Given that the challenge of patch management seems only to grow with time, it is likely that more focus will be given to specific network based patching technology. This will have to move beyond the remarketing of IPS and into new ground. The technology which will improve or may even overtake IPS already exists today: inline virtual patching. This works by editing network streams to make the traffic which hits the server work as if patched; the traffic is patched, the server is not. This differs from the IPS approach by ensuring that no traffic is ever stopped – suspicious traffic is cured not blocked.

In a modern organisation, IPS has won a strong place amongst the ubiquitous firewalls, content filters and anti virus platforms. Microscopic analysis of network traffic patterns combined with rules which detect probes against vulnerabilities mean that a mature system can give great benefit. After a planned implementation which aims to give greatest network coverage, careful tuning is usually necessary to ensure that alerts do not overwhelm administrators. Once implemented, IPS provides a value contribution to a strong network security stance.

(Note: I wrote this ages ago. Still seems fairly relevant.)