Security in WordPress: protect xlmrpc.php

Let’s talk abour a vulnerability specific to WordPress: one which, albeit very easy to overcome, can give us quite a headache. I’m talking about attacks directed to the xmlrpc.php file.

First off, what is the xmlrpc.php file? This file implements the XMLRPC protocol which allows data exchange via HTTP. In other words, it allows interaction between a WordPress installation and other external programms or services. This means we have a point of entry susceptible to external attacks. These can be intended to acquire passwords through brute force, scan the server’s internal web, deny services, etc. The consequences range from a loss of performance of our server due to excessive resource consumption, the server going down or stopping working; all the way to malware infection and usage of our machine for illegal purposes.

In WordPress versions prior to 3.5, this protocol was disabled by default and the administrator decided when to enable it. Nowadays this function comes active by default, which means many of us have an entrancewe might not have taken into consideration and as such, we don’t look after it.

Now then, is it really necessary to have xmlrpc enabled? Although the answer in most cases would be no, we need to consider the fact that xmlrpc.php is needed for some functions within the core of WordPress, like pingbacks and trackbacks, as well as some plugins like Jetpacks for WordPress which require this protocol to be enabled. So the final choice will depend on our installation (for example if we manage our blog from an app in our smartphone, we will most likely need this protocol to be active).

Attacls tp XMLRPC.PHP can consume a lot of resources since every petition must be processed, the usual symptoms of this type of attack come in the form of slow response times, server breakdowns, connection errors with the database, excessive resource consumption, etc; which is independent from our web being compromised. Frequently, the first reaction to these symptoms is to expand the resources, attempting to optimize our code to try and reduce resource consumption. However, we would be trying to cure the symptoms rather than the cause of the problem, and almost always we’ll find ourselves in the same situation.

How does one know if they are under an attack of this type? We need to check the server access registry and look for lines of this sort:

103.81.236.83 - - [13/Dec/2017:10:59:31 +0000] "POST /xmlrpc.php HTTP/1.1" 301 612 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"
103.81.236.83 - - [13/Dec/2017:10:59:32 +0000] "GET /xmlrpc.php HTTP/1.1" 405 3524 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1"

If this is the case we are under an xmlrpc attack.

How can we fix this situation?

• Method 1
  This method disables the XMLRPC protocol entirely. We simply delete the xmlrpc.php file and reconfigure our WordPress to avoid errors with the functions which might make use of it. We need to keep in mind that WordPress updates might copy the file again and could render us unable from using this method if some plugin we have installed requires it (although, WordPress likely has some other plugin which does the same things without needing XMLRPC).
  • Delete or rename xmlrpc.php
  • Add at the end of our wp-config.php the following line: add_filter('xmlrpc_enabled', '__return_false');
  • Add the functions.php file of our theme
    add_filter( ‘xmlrpc_methods’, function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );

    
• Method 2
  Block access to the xmlrpc.php file. The directory <Files> allows us, if needed, to authorize access from predefined IPs. It’s useful if we need to use the XMLRPC protocol and the first method does not work for us.
  
  • Add to our .htaccess
    # protect xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>
We could also respond with a 404 error
    <IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule /xmlrpc.php - [R=404,L]
</IfModule>
  • Should we need to, we could grant access to the IP we deem trustworthy. In this case, the modification will look like this:
    # protect xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Files>
Write in xxx.xxx.xxx.xxx the IP we’re granting access. We have to include a line for each IP.
• Method 3
  Since this is WordPress, some plugins which precisely do these functions do exist, for example
  • :XMLRPC Attacks Blocker, a free plugin which can be downloaded from the WordPress plugin repository. This plugin allows to select a user we can allow to access with the XMLRPC protocol, as well as blocking with .htaccess the IP addresses which try to use our xmlrpc.php file, once the protocol has been disabled.
  • Stop XML-RPC Attack, blocks all incoming traffic towards XMLRPC.PHP except traffic which comes from IP addresses belonging to Jetpack servers.

Now we simply implement the method which works best for us and we’ll be better protected, until the WordPress development team solves this vulnerability.