It’s no secret that XMLRPC is one of the most interesting aspects of WordPress. It allows services like JetPack to login to your site to act as a sort of management software. It allows apps to connect to the site as a means for users to login and more.
However, there is a little known fact, that many of you might not know. That is XMLRPC is one of the most commonly attacked WordPress endpoints. This is because XMLRPC allows for user authentication. Meaning XMLRPC becomes an insanely easy means for potential hackers to get into the WordPress site. Furthermore, you might not even realize you have the service enabled on your site.
You can use the following plugin to disable XMLRPC all together. However, bots are still going to try and hit this URL. Instead of blocking the functionality of XMLRPC, we are going to block access to it at the Cloudflare edge. This allows you to cut out any potential resource drainage and prevent attacks from that point.
The cool thing is that if you are using Jetpack, you can whitelist only their IP addresses. This allows the service to remain active, but blocks access to it for everyone else.
Setting Up The Firewall Rule
To begin this process, you need to sign into your CloudFlare account and select the Firewall tab. From there, select the Firewall Rules button in the sub-navigation that appears.
Now, we are going to create a new firewall rule. I named mine XMLRPC Protection because it’s super easy to know what it does in case I ever have an issue.
Now, here comes the logic. If you are looking to just block access, it’s simple.
This will now block access to XMLRPC.php on your site. The good part is if you start appending a query string, it will still block the request.
But What About JetPack?
Ah yes. JetPack users, here comes the part where you need to care about the rule. This is a bit more complicated because we need logic to check for JetPack’s IP addresses. We also need to make sure if Jetpack’s IP address is detected, that we only let it pass.
The cool thing about JetPack is their IP addresses don’t tend to change much. When they do change, the Jetpack team is awesome at updating them in the Jetpack documentation.
So, I am going to name this rule XMLRPC Protection (JetPack Whitelisted), and the logic is a bit longer.
I am copying the current list as of 6/2/2019 in this blog post of IPAddresses to save you time.
- 220.127.116.11-18.104.22.168 (in CIDR notation 22.214.171.124/20)
- 126.96.36.199-188.8.131.52 (in CIDR notation 184.108.40.206/20)
- 220.127.116.11-18.104.22.168 (in CIDR notation 22.214.171.124/20)
- 126.96.36.199-188.8.131.52 (in CIDR notation 184.108.40.206/22)
Now, when writing the rule make sure that you’re using the following.
Field 1: IP Address
Operator 1: Is Not In
Value: Copy the above IP addresses, you must use the CIDR notation for the ranges.
Now, select the and on the far right because, like in the first part, we are going to block the XMLRPC URL.
What Is The Logic For The JetPack Whitelist?
The logic works basically like this. When the incoming request is not in the IP Address range above and the URL contains xmlrpc.php, we are to block the request. The block only runs on pages attempting to run xmlrpc.php and the URL is not in the above Jetpack whitelist.
The advantage of blocking it at the edge is, you can save a lot of server work because the .php file is never actually running. The request gets stopped at the edge by checking this rule set first. So, if your site is under a DDOS attack or is getting a large amount of spam blocking access to xmlrpc.php, it’s a great way of protecting the site. 9 times out of 10 this will not have any affect on the functionality of the website.