Updates on WordPress security, Wordfence and what we're cooking in the lab today.

Wordfence Blog

Are Web Application Firewalls Vulnerable?

This entry was posted in WordPress Security on November 3, 2014 by Mark Maunder   5 Replies

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:

Cloud firewalls

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:



Screen Shot 2014-10-28 at 5.12.15 PM

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.

Did you enjoy this post? Share it!

5 Comments on "Are Web Application Firewalls Vulnerable?"

terry November 3, 2014 at 1:05 pm

This was a great article and as someone who has used and continues to use WordFence we have found that it does no protect your site from all attacks but it does do a damn good job of helping to reduce the threats and allow you to fix the simple attacks.

Without WordFence - a number of the attacks that we had to stop would have taken us 10 times longer to detect and fix.

We are not being paid nor were we asked to provide this comment. We provide it freely.

Dave Austin November 3, 2014 at 3:36 pm

I too have found Wordfence invaluable especially the logging of attempted logins where people are trying to login as admin. I use Wordfence to ban their ip addresses permanently.
Cheers Dave

Nikolas Branis November 3, 2014 at 5:13 pm

I use WordFence a lot. Lately, it has become a must have plugin for my WordPress installations.

Thank you for sharing your knowledge with us!

Mark Mercer November 3, 2014 at 5:18 pm

Good info as always from Wordfence. However, a bit of ambiguity as to what exactly you mean by "web application firewalls", and also whether or not you are saying that they are good but insufficient, or are false security?

Are you referring by that term to something like CloudFlare, which sometimes calls itself a Web Application Firewall? (and looks very much like your third diagram? To Sucuri, which is a WordPress security service that's still better-known than Wordfence, and does act in some ways like that? Or at least as something outside of the server, unlike Wordfence which is inside the protected server?

Are you suggesting that Wordfence be used instead of those types of WAF and external services, or as another part of layered security?

For my part, I use Wordfence on all sites I own or manage, but also have CloudFlare in front of several of them. Given you have specific code and options to work with CloudFlare, I'm guessing you are in the "useful but not sufficient" viewpoint about them. Would love to hear more perspective on layering WordPress security including Wordfence.

mark November 3, 2014 at 6:19 pm

Hi Mark,

Sucuri and CloudFlare are both Web Application Firewalls or WAFs, so yes they fall into this category.

The goal of the article is to simply increase your understanding of what a WAF does and how it fits into your site architecture. I see vendors use terms to describe your site as being "behind" their firewall and that bothers me because that's not the case. It's simply that web traffic is being proxied via their servers to your site provided that web traffic follows normal web rules. In other words, traffic that traffic does a DNS lookup, connects to the server the domain name points and so on.

Most bot attacks that are relatively unsophisticated ALSO follow the pattern of a standard request which is to look up your IP in DNS and target that IP, so that's why WAFs will block those attacks. But a WAF is not a firewall in the traditional sense because it's incredibly easy to get past it.

The point I'm trying to make here is that a hardware firewall, which is the way most people think about firewalls, is very difficult (near impossible) to pass or get behind. ALL traffic has to go via a firewall. A cloud firewall or WAF is trivially easy to get past if you want direct access to the server IP to launch an attack. And in fact the only thing that a WAF protects you against is web based attacks and not attacks on the vast array of others services that servers run.


Follow Us


Protect your websites with the #1 WordPress Security Plugin

Get Premium
Over 150 million downloads

Wordfence Newsletter

Get WordPress Security Alerts and Product Updates