If you haven’t already read Part 1, you really should to fully understand how we got to this point; “this point” being that “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”.

The CloudFlare WAF

The CloudFlare doco linked above is pretty good and well worth a read.

As noted previously, we already use CloudFlare, so have accounts setup, etc.

When you login to CloudFlare, “WAF” is a prominent  menu item on the left-hand side, see Figure 1.

However, look to the right at the button also highlighted! Your milage may vary (i.e. you may well consider it worthwhile), but we DID NOT choose this option!

Instead, from the “Account Home” item on the left-hand side (as shown, but not highlighted) above choose the domain of your WP instance. Then form the resultant screen (see Figure 2) open out the “Security” item and choose “WAF”, as shown.

This will open onto the “Managed rules” tab, ignore this as it’s just another up-sell. The “Rate limiting rules” tab is accessible, but we’re not addressing it in this use-case. Rather, select the “Custom rules” tab (highlighted in Figure 2).

Now let’s look at what custom rules we’ve setup and/or implemented.

Our configuration (specifically for WP)

See Figure 3, below.

Things to note from Figure 3:

• There is an allowance of up to 5 custom rules per domain on the plan we’re on (Free), we’ve used 2;
• CloudFlare provides a number of canned configurations as templates for common use-cases, we’re not going to discuss these, but the doco around them seems fairly comprehensive;
• We’ve used quite descriptive names for our rules, this is really just common sense; and
• Of the two rules we’ve defined, this domain has only one actually activated( the second one, with the switch on the right-hand side showing green), the other is dormant for now.

Time to actually look at the rules in more detail.

Rule 1—Block outside of Australia

Figure 4 shows the configuration screen of this rule.

It is well worth noting up front that this particular rule is a VERY blunt instrument, and potentially quite contentious and/or damaging. As the name suggests, it is blocking ALL access to the site from any endpoint device that is not identified as being within Australia. This is, in general, not best practice!

As Figure 4 depicts, the rule definition has a number of fields for entry/editing:

• The rule name, as above it’s just good sense to use something that is descriptive;
• The rule expression builder, containing the fields:
  • “Field” (couldn’t they come up with a better name?), you can choose from things such as country, URI and hostname, as well as a some rather more esoteric options beyond the scope of this discourse!—see Figure 5 for the full listing; and
  • “Operator”—which varies depending upon the initial Field selection but typically has choices such as “equals”, “contains”, “matches” (a string), etc; and
  • “Value”, which provides the second half of the expression, usually by drop list or text entry (although this varies case-by-case); and finally
  • [And] and [Or] buttons to allow chaining expression elements to build a more complex rule (we’ll use this in Rule 2, below).
• A preview of the expression as built, compete with a direct edit capability, useful if you know what you’re doing, or need to cut/paste across a few different domains (also useful for backup of the rule “just in case”!); and
• A droplist for the action required for the rule, typically “block”, “skip” (i.e. allow) or “challenge” (a couple of variations of this). We’ve used “block” in both cases.

Rule 2—Zone lockdown [Admin]

Rule 2 is the one that we have activated on this domain, and is much more interesting and useful for our use-case (managing unwanted login attempts to WP, in case you’ve forgotten 😊)—see Figure 6 for how it looks.

While we’ve discussed most of the basics above, there are a couple of things worth noting: first, as hinted above we’ve chained together two simple expressions with “AND” to build a more complex one. The first of these is identical to Rule 1, but the “AND” modifies it; it is made dependant upon traffic attempting to access the three particular paths/files (which are all WP administrative or login ones). The net result is that the effect of this rule, in narrative form is:

Block access to all WP login/admin EXCEPT from within Australia;
OR (to say it another way)
Only allow login/admin access from within Australia.

The second point to note, and it really only comes into play with more than a single rule defined, is that we can define the order in which these rules are processed; shown in the “Place at” section of Figure 6. In this case we’ve used the “custom” choice (the others are “First” and “Last”) and told it to trigger after Rule 1. [Noting that Rule 1 is disabled, we could equally as well have said to run this one first, however that would require deeper consideration if and when we were to activate Rule 1.]

Other questions we considered

I think I noted previously that we had some question about the “logic” of these rules, particularly Rule 2, blocking login from anywhere but Australia. The question was around how CloudFlare, being a widely-distributed, global network, would deal with originating IP address location, i.e. would anything within the CloudFlare network (or even the internet in general) break this rule and thus prevent legitimate logins? While we don’t have a definitive answer to this, the empirical outcome appears to be “NO”; originating IP address (and location) appear to be preserved and passed through correctly.

We also discussed the rationale for the Rule 2 logic at some length. For our use-case(s), we knew our customers well enough to know that none of them required login from anywhere outside of Australia for the main, and that they would certainly contact us immediately if they did. This is made simpler by none of the WP sites in question providing an end-user login or comment or similar functionality. Again, a huge benefit of knowing our customer base well. For a more complex use-case, blocking logins from “high risk” countries (e.g. China, Russia, Korea, eastern Europe) may be as far as you can reasonably go.

Some results of the implementation

To say that we were ecstatic about the immediate outcomes of implementing the WAF would be no understatement—we saw an almost complete drop-off in login attempts hitting the (first) site within seconds of turning on the WAF.

Some weeks on, the site that was originally being hammered and that triggered our investigation and action is now seeing one or two attempts a month in lieu of hundreds per day (at the server). There still seem to be plenty of hits on the WAF, but that’s essentially what it’s for; it’s doing the job!

Conclusion

From this, the only conclusion I can draw is that if you are managing one or more WP sites, implementing a WAF is generally low-cost/effort, and provides significant advantages in threat risk mitigation. The state of the internet in 2025 is such that if your WP site is not currently being targeted by malicious actors, then it is only a matter of time until it is. Get a WAF in place sooner rather than later, as it may well save your site and sanity.