Protecting WordPress Xmlrpc With Incapsula

So after suffering from a string of performance issues since January it seems pretty evident they were tied to scans and attempted manipulations of my xmlrpc.php file in WordPress, this is a default file that allows for trackbacks, pingbacks and remote posting to your WordPress blog from external clients like Live Writer and others.  The xmlrpc is one of the most vulnerable area’s of your WordPress site and it is something that should be secured.  There are several ways you can secure your xmlrpc.php file and here are some ideas to help protect your WordPress site.

First, I decided to keep all blocks with Incapsula Cloud Security, this allows me to never let the actual attempts even hit my web host, and keep blocks in the cloud.  At first my hosting provider had static IP deny statements for the IP’s that were detected as spamming my xmlrpc.php but I am moving this protection into the cloud to help reduce the server having to serve the 403 pages itself.  But, I if you want to stop the xmlrpc vulnerabilities at your web server layer you can go about it two ways.

Remove xmlrpc.php altogether

If you don’t use xmlrpc.php to remote publish articles and you don’t care about pingbacks or trackbacks, then simply remove the file, rename it and make sure it has 400 permissions (unix file permissions set via FTP) this will prevent the file from being executable. You can use your web hosting FTP service to simply change the file name and/or remove all executable permissions from the file. Remember you can’t get pingback, trackback, remote publish and Jetpack won’t work if you completely block your xmlrpc.php file.

Add a Deny Statement to .htaccess

This will simply deny all access to your xmlrpc.php file, but remember you can’t get pingback, trackback, remote publish and Jetpack won’t work if you completely block your xmlrpc.php file.

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

Add a Deny Statement with Allow Statements

This will deny attempts to your xmlrpc.php from anywhere except the specific IP addresses that you specify, like your own public ISP IP or other IP’s where you know will need access to your xmlrpc.php.

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from xxx.xxx.xxx.xxx
</Files>

Finally, I use Incapsula to accomplish the same thing, in the Incapsula menu you can complete block WordPress pingbacks/trackbacks by going into your Incapsula settings, and looking under Bot Access Control.

 

Here you can select “also block” and you can type “WordPress” in the popup list to block all WordPress bot accesses to your xmlrpc.php.

This will stop any WordPress site from accessing, and may or may not be comprehensive enough.  I haven’t tested to see if this breaks Jetpack or not, so this would need to be tested, but this won’t block Live Writer or any xmlrpc blog client and this I did test and confirm.

Finally you can simply just put a deny /xmlrpc.php statement into your rules for Incapsula and then allow specific IP addresses as needed, just as you would with your .htaccess file, but these blocks are now in the cloud instead of served by your web hosting web server.

Bottom Line is I spent quite a bit of time troubleshooting performance issues on Dragon Blogger to find out most of my problems were caused by vulnerabilities in the xmlrpc, and that the xmlrpc is often exploited to turn your WordPress site into an attack point for other sites.

Read this article for more information and protect your xmlrpc.php

http://arstechnica.com/security/2014/03/more-than-162000-legit-wordpress-sites-abused-in-powerful-ddos-attack/

Note:  There are several WordPress Security Plugins that also have the added feature to block/disable access to xmlrpc as well, generally though I offload my WP security to the cloud to reduce the overhead of WordPress running a plugin to handle security.  Some security plugins come with a risk that you can disable and lock down features to cause performance issues with your site too, but if you do use a security plugin for WordPress, make sure it is one that can close the xmlrpc vulnerability or you still should do a manual deny statement in .htaccess to secure your xmlrpc.php file.