Why You Need A WAF – Part 2

Previously, we touched on the critical value of protecting one’s web server, and the various way to do just that such as the setting up of a DMZ or the creation of an IPS.  We also introduced the fact that while a good idea, establishing an IPS in line with firewall as a means to intercept malicious traffic, was limiting.

As explained, an IPS cannot be effective against all potential application vulnerabilities.  Typically, an IPS ends up producing too many false positives, which in turn yield two possible reactions – either (1) it delays application response time and incorrectly interferes with the application; or (2)  it allows attacks as normal behavior in an attempt to reduce false positives.

An IPS looks at signatures and anomalies; a WAF looks at behavior and logic, analyzes traffic in both directions, looks at what is being requested, and what is being returned.

A Web Application Firewall’s main task is to protect web applications by inspecting the semantics of the flowing traffic and also inspecting HTTP/HTTPS for typical attacks at layer 7 such as SQL Injections, Buffer Overflow, Cross Site Scripting (XSS), File Inclusion, Cookie Poisoning, Schema Poisoning, Defacements, etc. To obtain a better understanding of the topic, a good source of information is found at this link.

OWASP is an open software security community collecting, among other things, the list of top attacks against web servers.  Any WAF on the market today will have to at least protect web applications and servers from the OWASP top 10.

Another aspect of using a WAF is called SSL offloading.  The internet is headed towards complete encryption. Increasingly, websites are using HTTPS, even when there is no confidential data to be protected.  If the website runs an application that requires confidential data to be entered, such as your online banking portal, the choice of HTTPS is obvious.  But there are plenty of examples of sites that are using HTTPS even though in principal they wouldn’t need to, because there is no private data to be protected.

Soon after the NSA scandal of 2014, Google.com chose to use HTTPS for all their pages.  Yahoo! has done the same.  And the examples are countless.  Encryption is adopted not just to hide searches, but to also guarantee the authenticity of a website.  Too many attacks are conducted by spoofing the looks of other websites, and the mechanism of private/public key/cert inherent to the HTTPS protocol is likely the last bastion against a widespread diffusion of such attacks.

For instance, when you go to https://www.networkboxusa.com/, the certificate on that website (published and guaranteed by a certificate authority) tells your browser that you have indeed reached the intended site, and not some hacked, spoofed site that might try to collect information to, in turn, conduct an attack against you.

What does this really mean for one’s webserver?

If the server capacity was designed for HTTP and suddenly every single transaction is encrypted, the CPU load can become such that the server itself may not be able to handle it.  One feature where a WAF can help is HTTPS offloading – the certificates are placed on the WAF, the encrypted connection is terminated on the WAF.  Between this and your servers, the traffic does not necessarily need to be encrypted, thus “offloading” the function to the WAF.  This allows control over which version of TLS to use.  That said, given that every version of SSL has now been compromised, so in reality, no one should really be using that for their HTTPS protocol.  Yet we still see many websites that have not been updated and corrected, likely because the software version cannot be updated (for the reasons explained earlier).  The WAF can easily enforce use of the appropriate TLS version, without the need to touch anything at all on the web server.

Because the WAF decouples the traffic between web server and internet, and the browsers are no longer connecting directly to the webserver, a WAF is an inbound proxy. Once we consider this, we see how it is possible to deploy other technologies commonly applied to outbound proxies to a WAF, such as AV and access control.  Applying AV rules to an inbound proxy may sound like a stretch because of possible performance limitations, and there are certainly issues with this; but it is vital to remember that in this case, we are not protecting a workstation.

We are protecting a very specific technology; so the applied AV can be limited to only signatures and heuristics that are relevant to a web server; there is really no need to run 11 million signatures to protect a web server.  And this can make running an AV more plausible.

At this juncture, it is also worth mentioning what WAFs do not do.

A WAF will not enforce access control in the traditional meaning of the term. Do not be confused by the term “firewall” present in the name of this technology.  A WAF only protects the server farm behind it, adopting signature based or anomaly detection algorithms but, unlike a network IPS, it will focus only on the HTTP and HTTPS protocols.  A WAF is a layer 7 technology, not layer 3.

Some Web Application Firewalls will also provide layer 7 protection against DDoS attacks, although most vendors separate the 2 types of protection, offering specific DDoS protection as a different service or appliance.  However, since this whitepaper pertains to WAF, we will not dwell on the details of DDoS attacks against web servers and why protection against such attacks is equally necessary.

Gartner’s magic quadrant for WAFs for 2014 says:

•   Protect web applications against hackers’ attacks, to monitor access to the web applications, and to collect access logs for compliance/auditing and analytics
•   Primary WAF benefit: providing protection for custom web applications that would otherwise go unprotected by other technologies that guard only against known exploits and prevent vulnerabilities in off-the-shelf web application software
•   WAF technology
  •   Maximizes the detection and catch rate for known and unknown threats
  •   Minimizes false alerts (false positives) and adapts to continually evolving web applications
  •   Ensures broader adoption through ease of use and minimal performance impact

There is another aspect to WAF technology that must not be underestimated.   A web server runs 2 ‘applications’ – the web server itself (be it Apache or IIS or something else) and the user application (what you see when you go to that website).  And in between, there are the tools used to develop the user application itself.  These could be PHP, wordpress templates, java, ASP, you name it.

Each of these layers can have vulnerabilities.  Apache has its own and plenty of them; IIS does as well.  But these are often known, announced, patched and therefore, made irrelevant after a while.  Aside from that, once they are known, it is often possible to create IPS signatures that can protect the web server itself.

The real issues, the ones that can cost an organization its entire database, are those caused by the user level application and tools used to develop it.  Whether it is an off-the-shelf product or one developed in-house (which is most often the case), software invariably has errors, which leads to vulnerabilities.  It is not a matter of if, but how many, and how exploitable.

For example, PHP and Java have vulnerabilities.  But these aren’t tools you can always update as this (act) could break the actual application.  As such, these tools are often not updated, vulnerabilities are not patched, and they cause the application to be, well, laid bare and open to attacks.

Stay tuned for our third and final installment wherein we discuss the inherent security pitfalls in the applications we use.