Chapter in this post:
I just got an email from my provider, according to which massive automated calls to the xmlrpc.php file in my blog had caused the entire server to reach its performance limit. Since the blog runs on shared hosting from All-Inkl, quick action was of course required. For this reason, the support guys initially made the script no longer accessible by changing the rights of the file from 744 to 300. So the calls from the joker who wants to hack into it run nowhere.
In the meantime I have had this type of attack on other WordPress sites and with other hosters. An excerpt from the log data shows the recurring attempts to crack WordPress via a POST call to xmlrpc.php. The whole thing looks like this:
 '0-3 "-" 0/0/2867 "." 171.83 "2228" 121334 "0.0" 0.00 "45.59" 5.199.XXX.XXX "POST" www.kindskopp.com "/xmlrpc.php'
 '0-3 "-" 0/0/3058 "." 171.77 "2228" 128420 "0.0" 0.00 "97.27" 5.199.XXX.XXX "POST" www.kindskopp.com "/xmlrpc.php'
 '0-3 "-" 0/0/2878 "." 171.40 "2228" 2765 "0.0" 0.00 "43.40" 5.199.XXX.XXX "POST" www.kindskopp.com "/xmlrpc.php'
 '0-3 "-" 0/0/2844 "." 171.66 "2228" 23121 "0.0" 0.00 "38.72" 5.199.XXX.XXX "POST" www.kindskopp.com "/xmlrpc.php'
 '0-3 "-" 0/0/3038 "." 171.80 "2228" 78254 "0.0" 0.00 "44.41" 5.199.XXX.XXX "POST" www.kindskopp.com "/xmlrpc.php'
 '0-3 "-" 0/0/3018 "." 171.65 "2228" 118321 "0.0" 0.00 "41.81" 5.199.XXX.XXX "POST" www.kindskopp.com "/xmlrpc.php'
Also with this other hoster I was informed that these attacks can bring the whole server into distress, even if my WordPress only runs on one [shared hosting-> shared hosting].
I then looked at what else can be done to protect this file and found the following options:
The xmlrpc.php file is completely protected by an entry in the .htaccess file. This means that no one can access this file from the outside any more. The protection is 100% and safe, but it has the disadvantage that you can no longer access it yourself with programs such as WordPress for iOS or Windows Live Writer. Even pingbacks or trackbacks can no longer "penetrate" from external blogs to your own blog. If you don't have a problem with that because you always work in the WordPress admin and don't want any trackbacks from other blogs, this solution is good for you.
Here is the corresponding code that you have to set up in the .htaccess file in the root folder of the WordPress installation:
<Files xmlrpc.php> Order Deny,Allow Deny from all </Files>
Inset - more interesting posts on the blog:
Anyone with the Windows Live Writer, Poster or even the iOS App WordPress for iOS works, you will certainly not want to do without it completely. For this reason, the following variant of the above-mentioned addition for the .htaccess file, which keeps the XMP-RPC interface free for common third-party software, is ideal for these bloggers. However, the trackbacks from other blogs are still blocked.
This is what the customized code looks like:
<IfModule mod_setenvif.c> <Files xmlrpc.php> BrowserMatch "Poster" allowed BrowserMatch "WordPress" allowed BrowserMatch "Windows Live Writer" allowed BrowserMatch "wp-iphone" allowed BrowserMatch "wp-android" allowed Order Deny,Allow Deny from All Allow from env=allowed </Files> </IfModule>
The lines with "BrowserMatch" can of course be adjusted as required if you use a certain program that was not considered in the above script. It is important that the Apache module "mod_setenvif" has to be installed for the protection to work. However, this module is already installed in many web servers. It is also important to know that the user agent is very easy to forge. So it is not a waterproof protection that you take here!
In the current case, I have opted for the rigorous variant and simply block everything that wants to access the file. I hardly get any trackbacks and I don't use any third-party software but only the WordPress admin to write blog posts. This is what my WordPress htaccess file looks like:
Update: Since the WordPress update to version 3.9.2 it is no longer possible to run DDoS attacks on the xmp-rpc.php. The WordPress team responded and changed the code accordingly. With this you can save the modification as described above from this version.
Jens has been running the blog since 2012. He appears as Sir Apfelot for his readers and helps them with problems of a technical nature. In his free time he drives electric unicycles, takes photos (preferably with his iPhone, of course), climbs around in the Hessian mountains or hikes with the family. His articles deal with Apple products, news from the world of drones or solutions for current bugs.