Introduction

WordPress is a popular and powerful CMS (content management system) platform. Its popularity can bring unwanted attention in the form of malicious traffic specially targeted at a WordPress site.

There are many instances where a server that has not been protected or optimized could experience issues or errors after receiving a small amount of malicious traffic. These attacks result in exhaustion of system resources causing services like MySQL to be unresponsive. The most common visual cue of this would be an Error connecting to database message. The web console may also display Out of Memory errors.

This guide will show you how to protect WordPress from XML-RPC attacks on an Ubuntu 14.04 system.

Prerequisites

For this guide, you need the following:

• Ubuntu 14.04 Droplet
• A non-root user with sudo privileges (Initial Server Setup with Ubuntu 14.04 explains how to set this up.)

We assume you already have WordPress installed on an Ubuntu 14.04 Droplet. There are many ways to install WordPress, but here are two common methods:

• How To Install Wordpress on Ubuntu 14.04
• One-Click Install WordPress on Ubuntu 14.04 with DigitalOcean

All the commands in this tutorial should be run as a non-root user. If root access is required for the command, it will be preceded by sudo. Initial Server Setup with Ubuntu 14.04 explains how to add users and give them sudo access.

What is XML-RPC?

WordPress utilizes XML-RPC to remotely execute functions. The popular plugin JetPack and the WordPress mobile application are two great examples of how WordPress uses XML-RPC. This same functionality also can be exploited to send thousands of requests to WordPress in a short amount of time. This scenario is effectively a brute force attack.

Recognizing an XML-RPC Attack

The two main ways to recognize an XML-RPC attack are as follows:

1. Seeing the “Error connecting to database” message when your WordPress site is down
2. Finding many entries similar to "POST /xmlrpc.php HTTP/1.0” in your web server logs

The location of your web server log files depends on what Linux distribution you are running and what web server you are running.

For Apache on Ubuntu 14.04, use this command to search for XML-RPC attacks:

grep xmlrpc /var/log/apache2/access.log

For Nginx on Ubuntu 14.04, use this command to search for XML-RPC attacks:

grep xmlrpc /var/log/nginx/access.log

Your WordPress site is receiving XML-RPC attacks if the commands above result in many lines of output, similar to this example:

111.222.333.444:80 555.666.777.888 - - [01/Jan/2016:16:33:50 -0500] "POST /xmlrpc.php HTTP/1.0" 200 674 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

The rest of this article focuses on three different methods for preventing further XML-RPC attacks.

Method 1: Installing the Jetpack Plugin

Ideally, you want to prevent XML-RPC attacks before they happen. The Jetpack plugin for WordPress can block the XML-RPC multicall method requests with its Protect function. You will still see XML-RPC entries in your web server logs with Jetpack enabled. However, Jetpack will reduce the load on the database from these malicious log in attempts by nearly 90%.

Jetpack installs easily from the WordPress backend. First, log into your WordPress control panel and select Plugins->Add New in the left menu.

Jetpack should be automatically listed on the featured Plugins section of the Add New page. If you do not see it, you can search for Jetpack using the search box.

Click the Install Now button to download, unpack, and install Jetpack. Once it is successfully installed, there will be an Activate Plugin link on the page. Click that Activate Plugin link. You will be returned to the Plugins page and a green header will be at the top that states Your Jetpack is almost ready!. Click the Connect to Wordpress.com button to complete the activation of Jetpack.

Now, log in with a WordPress.com account. You can also create an account if needed.

After you log into your WordPress.com account, Jetpack will be activated. You will be presented with an option to run Jump Start which will automatically enable common features of Jetpack. Click the Skip link at this step.

.

The Protect function is automatically enabled, even if you skip the Jump Start process. You can now see a Jetpack dashboard which also displays the Protect function as being Active. White list IP addresses from potentially being blocked by Protect by clicking the gear next to the Protect name.

Enter the IPv4 or IPv6 addresses that you want to white list and click the Save button to update the Protect white list.

Method 2: Enabling block-xmlrpc with a2enconf

The a2enconf block-xmlrpc feature was added to the DigitalOcean WordPress one-click image in December of 2015. With it, you can block all XML-RPC requests at the web server level.

To enable the XML-RPC block script, run the following command on your Droplet with the DO WordPress one-click image installed:

sudo a2enconf block-xmlrpc

Restart Apache to enable the change:

sudo service apache2 restart

Method 3: Manually Blocking All XML-RPC Traffic

Alternatively, the XML-RPC block can manually be applied to your Apache or Nginx configuration.

For Apache on Ubuntu 14.04, edit the configuration file with the following command:

sudo nano /etc/apache2/sites-available/000-default.conf

Add the highlighted lines below between the <VirtualHost> tags.

<VirtualHost>
…    
    <files xmlrpc.php>
      order allow,deny
      deny from all
    </files>
</VirtualHost>

Save and close this file when you are finished.

Restart the web server to enable the changes:

sudo service apache2 restart

For Nginx on Ubuntu 14.04, edit the configuration file with the following command (change the path to reflect your configuration file):

sudo nano /etc/nginx/sites-available/example.com

Add the highlighted lines below within the server block:

server {
…
 location /xmlrpc.php {
      deny all;
    }
}

Save and close this file when you are finished.

Restart the web server to enable the changes:

sudo service nginx restart

Verifying Attack Mitigation Steps

Whatever method you chose to prevent attacks, you should verify that it is working.

If you enable the Jetpack Protect function, you will see XML-RPC requests continue in your web server logs. The frequency should be lower and Jetpack will reduce the load an attack can place on the database server process. Jetpack will also progressively block the attacking IP addresses.

If you manually block all XML-RPC traffic, your logs will still show attempts, but the resulting error code be something other than 200. For example entries in the Apache access.log file may look like:

111.222.333.444:80 555.666.777.888 - - [01/Jan/2016:16:33:50 -0500] "POST /xmlrpc.php HTTP/1.0" 500 674 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

Conclusion

By taking steps to mitigate malicious XML-RPC traffic, your WordPress site will consume less system resources. Exhausting system resources is the most common reason why a WordPress site would go offline on a VPS. The methods of preventing XML-RPC attacks mentioned in this article along with will ensure your WordPress site stays online.

To learn more about brute force attacks on WordPress XML-RPC, read Sucuri.net — Brute Force Amplification Attacks Against WordPress XMLRPC.

213.189.55.149 victim.com- [29/Jun/2015:12:50:35 +0700] "GET /index.php HTTP/1.0" 400 1905 "-" "WordPress/3.9.6; http://www.gamesbase24.com; verifying pingback from 54.169.67.213" 5.001
194.58.92.216 victim.com - [29/Jun/2015:13:11:51 +0700] "GET / HTTP/1.0" 400 1905 "-" "WordPress/3.5; http://mygoldpartners.ru" 5.001

SecAction "id:1,phase:1,t:none,pass,nolog,initcol:global=global,initcol:ip=%{remote_addr}"
SecRule REQUEST_HEADERS:User-Agent "(wordpress|pingback)" "id:12,phase:1,t:lowercase,exec:/etc/exec/pingback.sh,deny,status:400"

#!/bin/bash
/bin/echo +$REMOTE_ADDR >/proc/net/xt_recent/PINGBACK

if ($http_user_agent ~* (WorPress|pingback) ) {
        return 444;
}

location = /xmlrpc.php {
    deny all;
    }

[Definition]
failregex = ^<HOST> .*POST .*xmlrpc\.php.*
ignoreregex =

[xmlrpc]
enabled = true
filter = xmlrpc
action = iptables[name=xmlrpc, port=http, protocol=tcp]
logpath = /var/log/apache2/access.log
bantime = 600000
maxretry = 2
findtime = 6000

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Enabling conf block-xmlrpc.
To activate the new configuration, you need to run:
service apache2 reload

5.178.68.254 - - [10/Mar/2016:11:46:01 -0500] "POST /xmlrpc.php HTTP/1.1" 301 573 "http://bb.com/xmlrpc.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070502 Firefox/1.5.0.11 Flock/0.7.13.1"
5.178.68.254 - - [10/Mar/2016:11:46:42 -0500] "POST / HTTP/1.1" 200 6163 "http://bb.com/xmlrpc.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.11) Gecko/20070502 Firefox/1.5.0.11 Flock/0.7.13.1"
89.47.29.92 - - [10/Mar/2016:12:21:53 -0500] "POST /xmlrpc.php HTTP/1.0" 301 524 "http://www.hh.com/" "PHP/5.2.03"
75.103.70.22 - - [10/Mar/2016:15:20:45 -0500] "POST /xmlrpc.php HTTP/1.0" 301 512 "-" "-"
5.178.68.254 - - [10/Mar/2016:15:38:58 -0500] "POST /xmlrpc.php HTTP/1.1" 301 573 "http://bb.com/xmlrpc.php" "Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.1.8) Gecko/20100216 Fedora/3.5.8-1.fc11 Firefox/3.5.8"
5.178.68.254 - - [10/Mar/2016:15:39:44 -0500] "POST / HTTP/1.1" 200 6165 "http://bb.com/xmlrpc.php" "Mozilla/5.0 (X11; U; Linux x86_64; es-ES; rv:1.9.1.8) Gecko/20100216 Fedora/3.5.8-1.fc11 Firefox/3.5.8"

 fgrep '"POST /xmlrpc.php HTTP/1.0" 200 791 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"' /var/log/apache2/access.log | cut -d' ' -f1 | sort | uniq

iptables -I INPUT -s 159.122.224.173 -j DROP