Application IPS - The missing layer
As we saw in A brief history of firewalls and the rise of UTM, many layers have been added to the humble firewall in the last 15 years. Where today’s UTMs and Next Generation Firewalls tend to differ, is in their handling of intrusion prevention and application control.
HTTP is the new IP
With corporate applications and data increasingly delivered via web technology, HTTP has become the new IP. Consequently, attacks such as XSS (Cross site scripting) and SQL injection, which exploit vulnerabilities in web browsers or servers, now represent the most significant menace for many corporates.
In protecting against such threats, there are two main considerations - how to detect the attack - and what to do, once it has been detected.
How to detect an attack
The easiest and fastest method of detection is to use attack signatures (patterns of data corresponding to known attacks). The biggest problem with relying solely on these is that simple variations in the code can prevent them from being matched, thus allowing an attack to go unnoticed until updated signatures containing the new varied code pattern have been released. Also, by definition, they are totally ineffective against completely new forms of attack.
Deep analysis
A better approach is to apply deeper, more intelligent analysis, in which not only the application’s name but also the API, protocol, context and behaviour of each traffic flow is examined in detail. Given all these extra data-points, the right engine can make a far more accurate assessment of risk, which in turn can lead to a higher probability of detection and a correspondingly lower chance of false positives. A possible downside is that unless the attack prevention engine has been designed to handle such detailed analysis from the ground up, the impact on throughput can be prohibitive.
What to do, once an attack has been detected
This second consideration seems at first an obvious one. Surely we must block it? But what if you cannot identify a threat early enough to avoid losing the session? Since many firewalls try to identify the flow just by looking at the first packet, they can easily be fooled by tactics as simple as padding – for example using a much longer URL than necessary, though not so long that it triggers a buffer overflow. In order to avoid exceeding the TCP window (the number of packets which can be sent to the server before receiving an acknowledgement) such devices have to make a choice: Do I let this pass - even though it might turn out to be an attack - or do I block it and potentially interrupt a valid user session? Surprisingly, many firewalls take the naively optimistic approach that it’s probably OK, and just let it pass.
Blocking is clearly the safer option, but for the reason above is far from ideal. Some firewalls get around this by handing sessions off to an intermediary – typically software running on another server, acting as a “proxy” for the original interaction. This is a safer alternative than simply passing the traffic, but since it involves the creation of additional connections, the impact on performance can be severe. For this reason, the proxy approach is not really compatible with environments where high throughput is required.
Why not just block all non-business apps such as facebook?
Basic “Application Firewalls” try to address the problem by applying rudimentary packet filtering to control which applications can pass and which should be blocked. And with many of today’s attacks exploiting the popularity of apps such as facebook, this may seem like a valid strategy, but it ignores any legitimate business benefits of such applications and will likely lead to creative circumventions of your security policy.
Application IPS
So, blocking all suspect traffic, while clearly a safe approach, will invariably lead to connections being dropped and an impaired user experience. However, letting unidentified traffic flows pass in the hope that they will prove benign, is manifestly risky.
Luckily, there is an ingenious way to avoid the above compromise. If the firewall is able to hold judgment on traffic identification until the full string of packets has been received, it can then apply its pass or block policy in total confidence that known malicious code will always be intercepted, while legitimate sessions pass uninterrupted.
So what about that TCP window? Well, this is where it gets ingenious. Making use of the “deep analysis”, of which we spoke earlier, it is possible for a suitably endowed firewall to “understand” the session protocol and provide the required acknowledgements on behalf of the server.
NETASQ calls this patented technology Application IPS, and includes it as standard across the full range of its UTM and Next Generation Firewall products.