xmlrpc.php, Pingbacks, and WordPress Denial of Service Attacks Explained

xmlrpc.php and Pingbacks and Denial of Service Attacks, Oh My!

Did you know your website could be used to attack other websites?

Or, has your website displayed this message:

"Resource Limit Is Reached. The website is temporarily

unable to service your request as it exceeded

resource limit. Please try again later"

Or, worst:

"500 Internal Server Error"

If so, XML-RPC Support or, specifically, your WordPress xmlrpc.php file may very well have been the reason why.

My goal in writing this article is to clarify what XML-RPC protocol is about, share a bit of history, and provide some quick tips for enabling or disabling XML-RPC Support.

Update, August 2014:

The WordPress 3.9.2 security update was intended to minimize the impact of excessive connections to the xmlrpc.php script.

Here's the rub, XML-RPC Support, a.k.a., remote publishing, was "OFF" by default in versions of WordPress prior to 3.5. In December 2012, the WordPress folks, believing they had fixed the XML-RPC security issues from earlier that year, forced the default XML-RPC protocol setting to "ON." And, for good measure then removed the option to turn it off within the WordPress dashboard. Zoinks!

Then, later in 2013, distributed denial of service attacks using the XML-RPC mechanism was confirmed again by Incapsula, WordPress Default Leaves Millions of Sites Exploitable for DDoS Attacks.

Without going into a long treatise on how or why the XML-RPC protocol can be used and abused, let's talk about whether you need to leave it "ON" (or OFF!). It is also a favorite route for brute-force login attacks, so closing it is one piece of locking down your login.

Do you use any of the applications listed on this WordPress Codex page, use Jetpack, or do you care about pingbacks and trackbacks?

If you are not sure what pingbacks or trackbacks are about, there are a lot of great articles written on this subject. I recommend trying a Google search for the phrase, "Why should I care about pingbacks."

I couldn't care less about XML-RPC protocol or pingbacks or trackbacks, or Jetpack

Then install the Disable XML-RPC plugin. If your site runs behind a firewall service such as Cloudflare, you can also block requests to xmlrpc.php there.

If you would prefer to not use plugins and wish to kill the loading of the xmlrpc.php file completely, just add this snippet of text to your .htaccess file:

RewriteRule ^xmlrpc.php$ "http://0.0.0.0/" [R=301,L]

This null routing method will use fewer server resources than removing or denying access to the script, which would result in a 404 "file not found" request and additional resources, respectively.

I loves my XML-RPC protocol, pingbacks, and trackbacks, or Jetpack

For those of us who find Jetpack indispensable, and fully disabling xmlrpc.php is not an option, try one of these two options:

Disable XML-RPC Pingback plugin. It removes only the pingback methods and leaves the rest of XML-RPC running, so Jetpack and the WordPress mobile apps keep working. (The plain Disable XML-RPC plugin above turns the whole XML-RPC API off.)

Remove XMLRPC Pingback Ping should likewise allow JetPack and WordPress Mobile Applications to operate without error.

Alternatively, disable only pingbacks and trackbacks, while leaving the XML-RPC protocol operational:

Delete the wp-trackback.php file:

/public_html/wp-trackback.php

Then disallow notifications by going to

http://your_site.com/wp-admin/options-discussion.php

And uncheck "Allow link notifications from other blogs (pingbacks and trackbacks)"

That should give you back much of the XML-RPC system flavor, without the bad pingback taste.

Alternatively, if Jetpack is your friend (today), instead of denying all access to xmlrpc.php, you can allow only the Jetpack IP addresses while denying the rest. This way you retain your Jetpack mojo, while serving up a dead page to beggar bots. Jetpack's server addresses change over time, so use the current list published at jetpack.com/ips-v4.txt instead of relying on the single range shown here, and check it now and then.

# Apache 2.4
<Files xmlrpc.php>
Require ip 192.0.64.0/18
ErrorDocument 403 http://127.0.0.1/
</Files>

On an older Apache 2.2 server, use this instead:

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
Allow from 192.0.64.0/18
Satisfy All
ErrorDocument 403 http://127.0.0.1/
</Files>

*If, for example, you are publishing updates from your iPhone using your local WiFi connection, add your local Internet connection IP address as another allowed address (another Require ip line, or Allow from on Apache 2.2). Hint: Google "What is my IP"

And Enjoy!

I've posted a few basic article links below. Likewise, if you have questions just pick up the phone and call anytime, Jim Walker, The Hack Repair Guy, (619) 479-6637

How to Block Bots from Seeing your Website, Bad Bots and Drive-by Hacks Explained

Protecting WordPress Against Brute Force and Denial of Service Attacks

WordPress Security Plugins Revealed

Frequently asked questions

Written and reviewed by Jim Walker, The Hack Repair Guy™

Jim Walker has protected and repaired WordPress websites since 1998. Want Jim to handle your WordPress security, weekly updates, and 60-day offsite cloud backups for 50 cents a day?

Protect My Site ($14.95/mo) Call Jim: (619) 479-6637