Are Web Application Firewalls Vulnerable?

Anyone else remember Gauntlet or Firewall-1? They were two of the most popular firewall products back in the early 1990’s when Firewalls were just beginning to reach the market. Even on those friendlier times, there was a realization that to truly secure yourself from bad actors on the Public Internet, you either had to disconnect yourself from the Net and have an “air gap”, or have a gatekeeper that sits between you and everyone on the outside in the form of a firewall.

Firewalls have evolved from being routers with a handful of layer 3 rules that filter traffic at the IP address level to performing stateful inspection and have since evolved to perform deep application level traffic analysis as CPU, memory and network capacity has increased.

Then came The Cloud. Oracle Chairman Larry Ellison expressed contempt for the Cloud concept in a now famous interview at the Churchill Club.

But the “Cloud” has been a marketing success and continues to be and even Larry and Oracle have come around and today you can visit cloud.oracle.com to find out all about Oracle’s Cloud services. Even Wordfence occasionally talks about the scanning servers that form the backbone of Wordfence Security for WordPress as “Cloud” servers. It’s a useful metaphor now that most people have a handle on the concept.

So what is a Cloud Firewall (or Cloud Web Application Firewall as it’s sometimes called) and what does it protect you against?

This is a diagram of a traditional Firewall configuration created by Cisco. This configuration is what all Fortune 500’s and organizations like the NSA, CIA and FBI use to protect their private networks from the public Internet. [Note: Many, especially the three letter agencies go further and implement an air gap.]

Here is another configuration, courtesy of Cisco:

You’ll notice that there is a firewall that creates a physical barrier between the private network and the public Internet. There is no way to access the internal network without having your traffic go via the firewall and if it does go via the firewall, that piece of network hardware gets to inspect your traffic and make sure it’s authorized.

Consider the configuration below:

Every component has been moved to the public Internet including good and bad actors accessing your server and the server itself. The server that should be protected has a public IP address that is accessible by anyone on the Net. The Firewall also exists on the Public Internet as a cloud firewall or Cloud Web Application Firewall.

You are looking at the typical configuration of a “Cloud Web Application Firewall”. The configuration is as follows:

• Point your server’s domain name to the WAF or Cloud Web Application Firewall IP address or address range.
• Configure a few items on the WAF website to let their systems know to expect traffic destined for your website and where to forward that traffic. Usually they’ll need your server’s public IP address.
• Install something on your website either in your web application like WordPress or a module on the web server itself called mod_something-or-other that prevents the web server from accepting requests from anyone but the firewall provider’s servers.

This configuration protects you against attacks that must fulfill certain conditions:

1. The hacker has found your website by doing a DNS lookup of your domain name to determine what your IP address is. They get the response that it is the Cloud Web Application Firewall’s (WAF) IP address.
2. The request then goes via the WAF which filters the request and it is then forwarded to your server, or not, depending on whether the WAF approves the request.

This configuration does not protect you against attacks that target other ports on your server. These include ports like:

• SSH (port 22)
• FTP (port 21)
• CPanel or any other admin service running on ports like 2083
• POP (port 110)
• IMAP (port 993)
• SMTP (port 25)
• Any other service listening on the machine that hosts your website.

If a hacker can find out your public IP address, they can simply access your web server directly. Remember though that if your server is correctly configured, it should only allow requests from the WAF. But the code that decides wether or not to accept those requests is your web server core code. If that is vulnerable, as was the case with HeartBleed, then you are vulnerable.

So this raises the question: Once you have a WAF in place, is it possible to find out what your web server public IP address is? Sure. Here are a few ways:

Doing a DNS scan for other subdomains on your domain often yields a large number of results:

nmap --script dns-brute -sn example.com

Running this from a Linux command line will yield a large number of subdomains on many websites that point to the actual IP address of the server behind the cloud web application firewall. This is common knowledge, so don’t consider this a disclosure of any kind.

An easier less technical method is to simply look up the hosting history for a site on Netcraft:

http://toolbar.netcraft.com/site_report?url=example.com

Yields:

Netcraft includes the server OS and dates hosting changed. If you’ve recently moved to a WAF, check if your public IP address is listed here.

To be clear: Cloud Web Application Firewalls or WAFs will block many unsophisticated attacks that simply do a DNS lookup to find your site IP address before launching an attack. However they won’t get between your server and attacks that access your site directly using your site IP address.

WAF’s will also not block attacks that target your server directly and, as you can see from the illustration above, it’s trivial in many cases to find out what the public IP address of a target site is and simply “go around” the Cloud Web Application Firewall.

Unfortunately we live in a World where there is a time delay between when vulnerabilities are discovered and when they are fixed. That delay is sometimes a matter of hours, and other times it may be several years. That gap is the time during which a hacker can gain access to your website using that vulnerability and you don’t have the ability to fix the security hole because the vendor isn’t even aware of the problem. This is known as a “zero day vulnerability”.

Because of this unfortunate reality, it’s likely that your website will get hacked at some point during your tenure as a website owner.

At Wordfence we realize this and we try to give you a reasonable level of protection from getting hacked, but much of our energy goes to early detection in the form of robust website scanning. We try to give you a way to catch any problems early before you drop in the search engine rankings and lose customers as they notice your hacked website.

We recommend that you take steps to give yourself the best shot at not getting hacked in the first place and we also want you to be able to catch a hack early, be able to clean it up effectively and recover from it as quickly as possible while minimizing the damage.

To do this you need to have a solid understanding of what tools are available and how they protect you or help you recover from a disaster scenario and I hope this post has helped you gain a greater understanding of what cloud web application firewalls are and how they work.