Jon Schwenn and Tammy Fox
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.
For this guide, you need the following:
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:
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.
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.
The two main ways to recognize an XML-RPC attack are as follows:
"POST /xmlrpc.php HTTP/1.0”
in your web server logsThe 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.
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%.
Note: A WordPress.com account is required to activate the Jetpack plugin.
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.
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.
Note: This method is only available on a DigitalOcean One-Click WordPress Install created in December 2015 and later.
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
Warning: This method will stop anything that utilizes XML-RPC from functioning, including Jetpack or the WordPress mobile app.
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
Warning: This method will stop anything that utilizes XML-RPC from functioning, including Jetpack or the WordPress mobile app.
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)"
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.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Method 3 worked great for me, thanks! I am not too linux savvy but the one additional step I had to do to get it to work was restart MySQL altogether…“service mysql stop” then “service mysql start”.
Thank god for this tutorial, I was losing a bunch of money with my web site down.
An easy temporary fix is to IP ban all the offenders.
First get their IPs:
159.122.224.173 185.103.252.170 185.130.4.120 185.130.4.197 185.82.202.52 5.196.199.230
Then ban them:
etc
I was hit by the same issue a few days ago and my site was not working but thanks to your step by step tutorial. It helped me a bundle.
For me it does not work without the
=
sign!Please update the article.
Here is the correct code:
My site constantly being attacked using xmlrpc.phpI want block it, but does this will affect site function ? site is : dealslama.com
I have been receiving unwanted traffic from RSS FEED , I tried disabling it from the functions.php but with no luck. My site shows 504 and 502 Gateway Error.
I followed your tutorial and it still has no effect, my CPU Graph shows 100 % resource usage…
My access.log files gives this :
1.186.37.141 - - [26/Jan/2017:17:39:17 +0545] “GET /feed/?post_type=job_listing HTTP/1.1” 502 568 “-” “Mozilla/5.0 (Linux; Android 4.4.2; Aqua Y4 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36” 115.164.222.149 - - [26/Jan/2017:17:39:17 +0545] “GET /feed/?post_type=job_listing HTTP/1.1” 502 568 “-” “Mozilla/5.0 (Linux; Android 5.1.1; SM-J120G Build/LMY47X; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36” 37.37.65.168 - - [26/Jan/2017:17:39:17 +0545] “GET /feed/?post_type=job_listing HTTP/1.1” 502 568 “-” “Mozilla/5.0 (Linux; Android 5.1; Lenovo A2010-a Build/LMY47D; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/46.0.2490.76 Mobile Safari/537.36” 1.186.37.141 - - [26/Jan/2017:17:39:17 +0545] “GET /feed/?post_type=job_listing HTTP/1.1” 499 0 “-” “Mozilla/5.0 (Linux; Android 4.4.2; Aqua Y4 Build/KOT49H) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/30.0.0.0 Mobile Safari/537.36”
I would like to block " /feed/?post_type=job_listing" How do I do it ?
Please Help…
Thank You.
I really wanted to send a small word to say thanks to you for the fantastic points you are writing on this site. flip diving
I did " block-xmlrpc with a2enconf " following method 2. but I want to unblock it. What should I put?
I used Putty when I did.
am blocked my xml-rpc in last days i think now pinging service is not indexing mee … is it possible bcz in past days i got a index in seconds after posting … how to enabled again blocked xmlrpc …
Thanks for the info. Editing my apache2.conf as noted in Method 3 worked well for me. The hardest part was just realizing what the issue was in the first place, but I guess I should’ve suspected malicious activity when my server started getting slow/inaccessible without a traffic increase or a configuration change.