What is a WAF?

WAF stands for Web Application Firewall. From Wikipedia (https://en.wikipedia.org/wiki/Web_application_firewall):

A web application firewall (WAF) is a specific form of application firewall that filters, monitors, and blocks HTTP traffic to and from a web service. By inspecting HTTP traffic, it can prevent attacks exploiting a web application’s known vulnerabilities, such as SQL injection, cross-site scripting (XSS), file inclusion, and improper system configuration.

If this all sounds far too techo, let’s talk about the specific use-case that led me to having a WAF set up for my WordPress (WP) sites.

Part 1 of the story is the background and use-case leading up to the decision to deploy a WAF, Part 2 talks about the specific configuration we’ve used and why.

Background to a WAF use-case

I look after a handful of WP sites; our own personal one and a few for not-for-profit organizations (mostly churches and para-church groups). They are all pretty low-key, with the target audiences measured in tens or (rarely) hundreds, not thousands. None of them have any transactional component, such as a shopfront or the like; neither do any of them have more than one or two registered users who would be looking to login to the site.

As a matter of good practice, one of the WP plugins I install on every site is a brute-force attack protection one (I use Limit Login Attempts Reloaded (LLAR), but that’s not particularly relevant, any of the well-respected ones available will likely do an adequate job). These plugins tend to work by detecting failed logins, then blocking the source IP address that has a set number of failed logins for a specified time. Default settings are usually something like 3 fails leads to a 20 minute block; then 3 blocks lead to a 24 hour lockout, etc. I tend to leave the defaults in place most of the time. LLAR has the rather nice function that it can email the site administrator when this escalation occurs. I seldom see one of these emails.

Imagine my surprise and concern, then, when I started receiving two emails a day, then four, then ten, and continuing to ramp up to more than twenty a day relating to a single one of my sites (the peak was 33 in one day!). Bear in mind that each email is the product of something like nine or ten login attempts. I knew full-well that the site in question, a smallish suburban Church, would have no legitimate need for such volume of attempted connections.

Time for some investigation! None of the login attempts had actually been successful and the site had not been compromised, although that was likely only a matter of time. There was, however, a noticeable increase in server processing load as it dealt with all of the login attempts. This flowed on to seeing increased delays (i.e. slower system response) during administrative tasks, although thankfully there was no particualry noticeable change to the front-end usability. Digging around a bit more showed that the vast majority of these—by now believed to be spurious—login requests were originating from China, Korea, Russia and eastern European countries. As a site with a very localised focus, there was absolutely no legitimate reason for this whatsoever; especially as there were only three user accounts active and I knew where each of those people were (broadly, at least to a State level!).

Decision points

So, armed with some facts supporting our gut-level feeling that “something bad was going on”, we went looking for answers.

Having been in the network game for a little while now, it was pretty obvious that what was needed here was some form of firewall. After all, managing traffic in the general sense is what firewalls do; so that bit was a no-brainer. It also didn’t take long to get from there to the “web application firewall (WAF)” point either; they have been around for a fair while now and are reasonably well understood with lots of supporting literature (of which this paper is just one simple example!).

The questions left then were:

• Can a WAF readily block/allow by geolocation (specifically country in our case), and if so how “granular” is this if we need extra flexibility? and
• How does WP work with a WAF; does it need any specific customisation or tuning or perhaps reconfiguration? and
• Should we be looking at a our own WAF (i.e. on our own hosted WP server) or some sort of “cloud” service?

The geolocation question is still, in my mind, a little bit open. We cannot claim to have done anything like a comprehensive survey of the market, but some general reading suggests that this is an area of functionality that is very commonly provided as either standard or an optional extra. [To be honest, we kinda looked at this question and the third one in tandem, and basically stopped looking when we found the product we wanted!] We’ll brush on this more a little later as we discuss details of configuring the WAF.

The question of WAFs and WP came out in the wash pretty quickly—when we look at how WP is constructed there is a well-defined set of login and administrative files (which translate to URLs), so blocking access to them was pretty darn straightforward. Your specific use case may vary, but for us, blocking any logins or administrative access (from specified countries as above) was the desired outcome.

Finally, to host or not to host; that is the question! Again, for us it was pretty much a no-brainer. We were already using a respected network services provider (Cloudflare, more about this later on) for proxy, DNS, etc so when we found that their offering included basic WAF, why look any further? A significant advantage of this approach is keeping any of this “doubtful” traffic totally away from our own server; reducing both our risk profile and server bandwidth/processing loads. We did briefly consider the WAF built into the cPanel-equivalent on our servers, but the points above made this really only a “tick-the-boxes” exercise.

Product of choice

We determined to set-up and deploy Cloudflare’s WAF (see https://developers.cloudflare.com/waf/ ) in front of all WP instances across our servers.

Stay tuned for Part 2: setting up and some discussion on early results