Why You Need A WAF – Part 1

At the time of writing of this blog, attacks against web servers are (by far) the most prevalent issue in cyber security.  The Verizon Data Breach Investigations report for 2014 showed that 35% of breaches were caused by web application attacks.  And by mid 2016, this number is only rising.

Hackers are getting control of web servers for different reasons, the main ones being the ability to control a server and spread malware.  Often, these two objectives go hand in hand.

Why do hackers want to control a web server? Because a server is often hundreds of times more powerful than a workstation, and that allows them to have a platform to launch attacks from a single point, rather than having to deal with multiple workstations.  Servers are often also connected to larger bandwidths, enabling these attacks to be increasingly efficient.  They are also online 24/7, users don’t turn them off at night as they tend to do with a personal computer.  And they are connected to public IP addresses on a public network, not in someone’s home or office.  A server can, and most times is, used as a command and control center to manage a network of zombies – a botnet.  Finally, a server can be used to ‘serve’ malware.   In this case, the web server may not even look compromised, and yet malware lurks in the background, ready to attack unaware browsers.

This should make one thing abundantly clear – protecting web servers is critical; not only does a company stand to lose data, the server can also be used as a bridge into the company’s network. Or to launch attacks against other companies; and although we have yet to see lawsuits in such cases, it is only a matter of time before someone gets sued over allowing their server to become a tool for conducting attacks against someone else.

But how exactly does one protect a web server?  Especially one that is running an application, which is, in turn, connected to a database?

Up until a few years ago, the practice was to put the web server itself into a DMZ, the database server on the LAN, and ‘hope’ that the firewall and IPS could stop malicious traffic between the two.  The idea being that if the web server were to become compromised, it is easy to rebuild and data is not lost.  Unfortunately, this method of protection is insufficient; it never really was to begin with, but today, it is clear how and why.

First of all, too many people misinterpret the meaning of DMZ and allow all traffic, rendering the very idea of DMZ pointless.  Second, the ports needed for the web server to run queries against the database are the very ports hackers are trying to attack.  This does not in any way prevent a SQL injection or a database DDoS attack, as both methods use database ports that are open from DMZ to LAN to allow the web server to run queries.

The next idea was to set up IPS in line with firewall, to intercept malicious traffic.  Though not a bad idea, it is, unfortunately, very limiting.  An IPS is a layer 3 protection.  Think of it as an AV at the packet layer.  It reads the content of a single packet, inspects it against known vulnerabilities and exploits, using a mix of signatures and heuristics (behavior analysis).  And that is all it does.  You might be wondering what the issue is.  IPS is used for many different reasons.  The problem is that IPS is a layer 3 protection, whereas HTTP is a layer 7 – it is an application layer protocol.   And web servers run applications.  This means that attacks can be carried on using transactions that span across several packets; and each packet can appear to be perfectly clean.  An IPS can protect against some low level SQL injections and XSS attacks; it can protect against things like the Slammer worm, on which more information can be found here.

SQL Slammer is a computer worm that caused a denial of service on some Internet hosts and dramatically slowed down general Internet traffic, starting at 05:30 UTC on January 25, 2003. It spread rapidly, infecting most of its 75,000 victims within ten minutes.  The reason why that is possible is because the Slammer was less than 400 bytes in size, so the entire malware fit into one a single packet.

But a web server attack of recent times is almost never just a single packet of malware.  More often than not, such attacks try to work around the HTTP protocol, injecting commands that are not part of a normal sequence, to gain access to resources on the server or cause the application to react in a way it wasn’t designed for.  In other words, an IPS cannot understand web application protocol logic, and cannot fully distinguish if a request is normal or malformed at the application layer.

In the second part of this article, we will explain (at length) why an IPS is ineffective when it comes to providing a safeguard against application vulnerabilities.