Cloudflare Firewall Rules for Securing WordPress - TurboFuture - Technology
Updated date:

Cloudflare Firewall Rules for Securing WordPress

Author:

I use Cloudflare for all my Wordpress websites - not just to make them faster, but more secure as well.

How to Use Cloudflare to Secure Your WordPress Site

This guide is aimed at security-minded webmasters who run a WordPress site or blog on a Cloudflare-enabled domain. On the free plan, Cloudflare grants five firewall rules that are empty by default.

By adding WordPress-specific rules I describe on this page, you can secure your site and block attacks before they even reach your web host's server.

Disclaimer: I'm not affiliated with Cloudflare in any way, but I've been a satisfied user of their services for several years.

Cloudflare's Web Application Firewall (WAF) provides an additional layer of security for your websites.

Cloudflare's Web Application Firewall (WAF) provides an additional layer of security for your websites.

Whitelist Your IP Address

Before you implement any firewall rules, you should first whitelist your own IP. This way you won't be affected should you decide to block your WordPress admin area from outsiders (which I will explain in a minute).

This can be done by accessing your Cloudflare dashboard and clicking Firewall, then Tools, entering your IP*, and choosing Whitelist in the drop-down menu.

Whitelisting an IP in CloudFlare Firewall.

Whitelisting an IP in CloudFlare Firewall.

*You have several choices here in the order of decreasing security:

  • Whitelist your exact IP address. Optimal choice if your ISP grants you a static IP. Note that if your IP changes, you will need to reenter it lest you get locked out of your WordPress admin area.
  • Whitelist your ISP's entire IP range. Good choice if you have a dynamic IP.
  • Whitelist your country. This won't protect you from attacks coming from inside your own country, but it can be a convenient option if you travel frequently and use Wi-Fi to connect to your WordPress site.

An IP address or a country whitelisted in this manner will be exempt from all firewall rules, so you won't need to add exceptions for each individual rule.

1. Block wp-login.php Attacks

If you peek at your server logs, you'll probably find numerous IPs from all over the world trying to access your wp-login.php file. This is by far the most common attack on WordPress installations. These are usually automated scans which do not pose a big threat, but you can still block them off for your peace of mind.

This of course assumes that you (the admin) are the only user on your site. If you have multiple users or use a membership plugin, you'll probably want to skip this rule.

In your Cloudflare dashboard, click Firewall once again, then press the blue Create a Firewall rule button. Name it whatever you like and enter the following:

  • Field: URI Path
  • Operator: contains
  • Value: /wp-login.php

[Action: Block]

If you did it right, you should see the following in the Expression Preview section:

(http.request.uri.path contains "/wp-login.php")

Save the rule, and it should be enabled automatically. Cloudflare will now block every attempt to connect to wp-login.php except from the IP you whitelisted.

These brute force attempts will vanish from your server logs, but you'll be able to track them on Cloudflare's Firewall Events section should you wish to verify that the protection is working.

2. Block xmlrpc.php Attacks

After wp-login.php, xmlrpc.php is the second most common attack target. XML-RPC has legitimate uses, such as blogging from a smartphone or posting content to multiple WordPress sites at once. If you don't do that, then it can be safely blocked. Follow the same procedure as previously and create the rule:

  • Field: URI Path
  • Operator: contains
  • Value: /xmlrpc.php

[Action: Block]

You should see the following in the Expression Preview section:

(http.request.uri.path contains "/xmlrpc.php")

3. Protect the wp-admin Area

Now let's make it so you and only you can access your admin area. This rule is slightly more complex because you need to make two exceptions.

First is /wp-admin/admin-ajax.php, which is used by certain plugins to display dynamic content on your website. As such, despite being located inside the /wp-admin/ folder, it needs to be accessible from the outside.

Second is /wp-admin/theme-editor.php, which runs an error check every time you edit your theme through the built-in editor by creating a loopback request to your homepage. If you don't add this exception, the check will fail with a message "Unable to communicate back with site to check for fatal errors" and your modifications won't be saved.

Go ahead and create the following rule:

  • Field: URI Path
  • Operator: contains
  • Value: /wp-admin/

[AND]

  • Field: URI Path
  • Operator: does not contain
  • Value: /wp-admin/admin-ajax.php

[AND]

  • Field: URI Path
  • Operator: does not contain
  • Value: /wp-admin/theme-editor.php

[Action: Block]

Or, just click Edit expression and paste in the following:

(http.request.uri.path contains "/wp-admin/" and not http.request.uri.path contains "/wp-admin/admin-ajax.php" and not http.request.uri.path contains "/wp-admin/theme-editor.php")

4. Block No-Referer Requests to Plugins

Most WordPress sites get hacked through insecure plugins. The best approach, of course, is not to install them in the first place, but you can also create a firewall rule blocking direct access to /wp-content/plugins/.

Legitimate requests which come through your website have something along the lines of "http://yoursite.com/page" as the HTTP referer and should be allowed. You may also want to allow known good bots (such as the Google crawler) just in case they try to index something - such as an image - inside your plugins folder.

Create the following rule:

  • Field: URI Path
  • Operator: contains
  • Value: /wp-content/plugins/

[AND]

  • Field: Referer
  • Operator: does not contain
  • Value: yoursite.com (replace with your real domain)

[AND]

  • Field: Known Bots
  • Operator: equals
  • Value: Off

[Action: Block]

Or, just paste this expression in directly (remember to replace yoursite.com with the actual address):

(http.request.uri.path contains "/wp-content/plugins/" and not http.referer contains "yoursite.com" and not cf.client.bot)

5. Reduce Spam by Blocking Direct Requests to wp-comments-post.php

I'll be honest: the effect of this rule will be minimal as spam bots these days are sophisticated enough to spoof the referrer. This will only block bots hammering the wp-comments-post.php file directly. Still, the same tip is described in WordPress Codex (except they use a .htaccess rule rather than Cloudflare), so if it's good enough for them, it's good enough for me.

The rule is as follows:

  • Field: URI Path
  • Operator: equals
  • Value: /wp-comments-post.php

[AND]

  • Field: Request Method
  • Operator: equals
  • POST

[AND]

  • Field: Referer
  • Operator: does not contain
  • Value: yoursite.com (replace with your real domain)

[Action: Block]

And here's the expression to save you the time:

(http.request.uri.path eq "/wp-comments-post.php" and http.request.method eq "POST" and not http.referer contains "yoursite.com")

Your Website Is Now Slightly More Secure!

These five rules should cover the most common WordPress attacks, but feel free to adjust and combine them according to your needs.

Most attacks you see in your logs come from automated bots just dumbly scanning websites for vulnerabilities, but should a person from outside your whitelisted IPs try to access your admin area, they will be greeted with an "Error 1020" page like this (you can confirm this by accessing it via a proxy or VPN):

This is the page a potential attacker will see after triggering one of your firewall rules.

This is the page a potential attacker will see after triggering one of your firewall rules.

Further Reading

Should you run into issues or want to learn more, I suggest you visit Cloudflare's knowledge base:

https://developers.cloudflare.com/firewall/cf-firewall-rules/

This article is accurate and true to the best of the author’s knowledge. Content is for informational or entertainment purposes only and does not substitute for personal counsel or professional advice in business, financial, legal, or technical matters.

Questions & Answers

Question: Can we combine all the above requests into one rule?

Answer: Sure. Put each individual rule into parentheses and join them with "or" (if your action is to block).

Question: About the rule to Block No-Referer Requests to Plugins. I noticed that your instructions to build the rule uses the URI path "/wp-content/plugins/" but the expression you supply uses the URI path "/plugins/". Can you please confirm which URI path value is correct?

Answer: Nice catch, I'll edit them to match. As to your question, unless you renamed your /wp-content/ folder, or have another non-Wordpress folder named /plugins/ for some reason, it doesn't really matter which one you use.

© 2018 Andrew Po

Comments

Dario Cedeno V. on August 31, 2020:

The wp-comments-post.php rules seems to have no impact on the spam generate, probably we should find a better block on comments.

Andrew Po (author) on August 10, 2020:

You could simply google "what is my IP".

daniel vilenchik on August 05, 2020:

How a m I supposed to now my IP adress and which kind is it ?

Andrew Po (author) on February 22, 2020:

It's just a matter of using parentheses to group expressions. I haven't tested it but this should work:

((http.request.uri.path contains "/wp-admin/" and not http.request.uri.path contains "/wp-admin/admin-ajax.php" and not http.request.uri.path contains " /wp-admin/theme-editor.php")) and (ip.geoip.country ne "FR" and ip.geoip.country ne "CA")

Andrew Po (author) on December 03, 2019:

On the end of wp-login.php? When using "contains" instead of "equals", sure, you can remove it.

But accessing /wp-login without the .php should return a 404, so there shouldn't be much reason to block that in the first place.

David Elstob on December 01, 2019:

I followed a tutorial elsewhere and started getting hits on /wp-login immediately.

However, the plugin rule caused me problems... because they missed the Known Bots off unlike you, thanks.

Only thing I suggest is - do you actually need the .php on the end because not everyone will type it in? So could miss some hits?

Julian on April 30, 2019:

Big thanks for an easy to follow guide on how to configure CloudFlare firewall rules to harden WordPress with greater security. These clear instructions enabled me to create firewall rules with confidence. Thank you!

Related Articles