Anti-DDoS XMLRPC Tweak Breaks Jetpack's Site Management

  • Posted on: 5 January 2015
  • By: davis

I've written before about using a special XMLRPC access rule to stop Wordpress DDoS attacks.

Quick summary: My server was being bombarded with hundreds of thousands of requests from foreign hosts (mostly Chinese). It took about a week before finding a fix - during which time my servers were slow, prone to crashing, and generally unusable. I found a helpful tip here. I simply added the following code to the bottom of my .htaccess file.

# END WORDPRESS
RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]

Following the implementation, my servers stabilized and the attacks rapidly dropped off. All was well.. until recently.

Jetpack released their nifty Site Management tool at the end of 2014. The tool is a hesitant step towards banishing multisite to the depths of hell. In theory, the tool will allow a server admin to quickly log in to a central location, see an overview of sites/plugins/data, and manage his network quickly and efficiently.

Sounds pretty great - in fact, this is something I have wanted for quite some time. The only problem is that after diligently setting up my sites, I couldn't get them to work.

Your website needs to be publicly accessible to use Jetpack: site_inaccessible

Error Details: The Jetpack server was unable to communicate with your site [HTTP 405].

Ask your web host if they allow connections from WordPress.com.

If you need further assistance, contact Jetpack Support: http://jetpack.me/support/

Except one. One site worked.

There was nothing exceptional about this site. It generally used the same plugins as the rest of my network. I checked and re-checked Jetpack's JSON API settings, disconnected my non-functioning sites from Wordpress, and reconnected them. Nothing.

I set the issue to the side as I became quite sick over the holidays.

I came back to it today, and after poking around, I noticed that people with XMLRPC rule modifications were having the same problems I did.

So - here's the problem. The fix for Jetpack is easy. Remove the RewriteRule from your .htaccess, and Jetpack's Site Management will function just fine. 

But as Jetpack requires access to your XMLRPC, so do hundreds of thousands of malicious scanning instances across the Internet. Until I find a solution that protects me from XMLRPC exploitation, I have disabled Jetpack's Site Management. It's simply not worth the increased security exposure, and I never miss an opportunity to lower my attack surface. I've since re-enabled my XMLRPC rule for all sites.

Sorry Jetpack, but I (and most other server admins) require XMLRPC rules due to malicious actors. We'll have to find a clever workaround to enable this service.