Stopping xmlrpc.php spammers
A simple solution to an emergency situation on a wordpress blog
I take care of all technical structure from my girlfriend’s blog. Her blog has a good number of visits per day and the server (a 500mb Digital Ocean droplet) can handle the 200.000~ accesses per month easily.
The emergence of the problem
I received an email from **New Relic **warning me that the CPU usage was around 80 % and that something was wrong.
1.1 — New Relic alert telling me that the server is really busy
After that the first thing that i did was checking the google analytics to understand what’s going on by analysing the number of real-time visits (Some days it’s normal to have 250 visits in real-time for her blog)
1.2 — Google analytics Real Time overview panel
WTF? 20 people on the 1 Core 512m ram using 80% of the CPU? There is definitely something wrong.
The problem wasn’t on the “normal visits” traffic so i went to New Relic’s dashboard looking for the right answers.
1.3 — New Relic’s Transaction panel
On the Dashboard if you click APM on the top and click **Transactions **on the left sidebar you will see which transactions are consuming more time from your server.
As you can see on the 1.3 image the problem is clearly the xmlrpc.php file.
The top chart are showing the files that are consuming more time.
The server was receiving around 300 requests per minute and the google analytics was showing only 20 in real-time.
> Note 1: 300 requests per minute are around 5 seconds per second.
> Note 2: 20 real-time visits in google analytics are equal to **0.3 visits per second, **a much lower number compared to 5 visits per sec hitting the server.
Wordpress uses this file for his pingback feature and some other stuff like remote posting.
My girlfriend don’t really post remotely, she always use the wordpress platform itself, so the remote posting feature is not necessary.
The pingback feature in other hand can be useful for his network, i mean, it’s nice to know when someone mention your blog, right?
I do not know if this feature is really useful to her, but at that point I had to stop whatever was happening .
Solving the problem
The first thing that came in mind was deleting the **xmlrpc.php **but again, i didn’t knew if it was a good feature for her, so instead of deleting it i preferred to block it.
To solve the problem I added the following four lines in the .htaccess file which is located in the root folder of the apache server.
1.4 — htaccess code for preventing accessing the xmlrpc.php file
After restarting the Apache & Varnish services i checked the New Relic’s Transaction panel again:
1.5 — The xmlrpc.php file was not a problem anymore
So the problem was really the xmlrpc.php file.
The next step is to understand what’s really happened and decide if the pingback feature will be really necessary.
I hope it helps someone on the same situation i was!