How to Use Cloudflare to Secure Your WordPress Site

Cloudflare Firewall Rules for Securing WordPress 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.

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.

*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.

source