Keyturns's picture

I think my TurnKey Wordpress instance is under some kind of XML-RPC attack as I see lines like this in my Apache2 access log every couple seconds for the past several days:

 ... [15/Dec/2017:06:27:30 +0000] "POST /xmlrpc.php HTTP/1.0" 200  ...

Are these all attempts to guess the Wordpress admin password or something?

What's the best way to block this (i'm running WP 4.9.1)?

Why is XML-RPC enabled on the Wordpress TurnKey appliance? 

Is XML-RPC required for Wordpress to work OK?

Will blocking XML-RPC requests break my site?

Jeremy Davis's picture

For starters, I'm not a WordPress user and aren't particularly familiar with it. AFAIK, XML-RPC more-or-less provides an API. This is used by mobile apps (among other things) to access your WP site. However, as you correctly note, it can be used maliciously. Also, my reading suggests that as of v4.7, WP implemented a "proper" RESTful API, so it could be argued that most modern apps should be relying on that, rather than XML-RPC

From my quick google, it seems that there are 3 main ways to block malicious access to XML-RPC. Directly block it via patching WP PHP files (not recommended), directly blocking it or filtering traffic via a plugin (a good option IMO) or blanket blocking access to the specific xmlrpc.php file using Apache. Using some sort of firewall to block specific XML-RPC traffic is another potential option.

So I'll exclude option 1 (because it's a bad idea IMO). Option 2 would require you to install a WordPress plugin that can allow you to disable, or adjust the access to XML-RPC. A quick google turned up a couple of possibilities. E.g. somewhat generic security plugins such as Jetpack or Wordfence. Or via specific plugins such as Disable XML-RPC or Limit Login Attempts Reloaded. I can't vouch for any of those, so if you decide to go that route, I suggest that you do your own research and decide on the one that will best fit with your site. Here is a WP plugin search that may be useful to get you started?!

Option 3 may be a perfect option if you are currently not using XML-RPC for anything. On TurnKey v14.x, something like this should do the trick:

cat > /etc/apache2/sites-avaialble/disable-xmlrpc.conf 

I hope that helps. Please post back and let us know which path you chose and how it all goes. Good luck.
Keyturns's picture

Thanks Jeremy, I tried this command:

a2enconf disable-xmlrpc

as I agree that a2enconf seems to be the easiest and most elegant way to block these malicious calls but when I rant that on 14.2 WP box I got   "Error: Conf disable-xmlrpc does not exist!", so that did not work for me.  I don't know  a2enconf , do I need to add features to it via apt-get or something? Why did it fail for me? 

What I did to block this XML-RPC Wordpress hack was at the end of "/etc/apache2/apache2.conf" I added the following:
# Block XML-RPC Attack
<Files xmlrpc.php>
Order Allow,Deny
Deny from all

so now those calls fail with a 403 so at least I have some protection from this particular hack vector. Not sure how/if this impacts WP overall or any other WP features but so far it appears to have no impact to the site.

But this hack is still chewing up resources on my server with constant calls which will ultimately cost me more money with my hosting vendor.

How can I block this IP at a higher level than my Wordpress site?

Jeremy Davis's picture

The website removed some of the "<" & ">" characters so it wasn't displaying everything I posted. I missed that when I posted it. Obviously you got the general idea though...

I've now fixed the code above. The first bit was supposed to create the file. Because some important bits weren't displayed, the file wasn't created, hence why you couldn't enable it!

What you've done does exactly the same thing, although not in as quite a nice way (IMO anyway). Having said that, I'm guessing you must be on an older version of TurnKey, because the code you've posted is legacy Apache 2.2 config. What I posted is the Apache 2.4+ (what is in v14.x) equivalent.

TurnKey appliances come with IPTables (Linux firewall) pre-installed and pre-configured, but disabled by default. You can enable that via Webmin and assuming that all the queries are coming from a single IP, you can explicitly drop all packets from that IP. As blocking access at the Apache level should not require too much overhead, I'm not sure that it will make much difference to your hosting costs. Regardless, it's still probably worth doing!

Keyturns's picture

Hi, understood on the a2enconf bits, yes the HTML was off in your post but it is clear now. 

As for my Apache version I ran this command:

root@wordpress ~# apache2 -v
Server version: Apache/2.4.10 (Debian)
Server built:   Sep 20 2017 04:37:43

so this is pretty recent Apache version.

I got my TKL Wordpress appliance from the AWS Marketplace so expecting/hoping it is a recent one.   How do I figure out what version of the TKL Wordpress appliance I have? This command shows me I have 14.2:

root@wordpress ~# cat /etc/turnkey_version

and the MOTD too shows 14.2 with Debian 8.7:

root@wordpress ~# cat /etc/motd
Welcome to Wordpress, TurnKey GNU/Linux 14.2 / Debian 8.7 Jessie

but I am not sure if this is the most recent TKL Wordpress appliance.

Will the TKL Automatic security updates also update me to the latest TKL Wordpress appliance? Does it matter if I am running the latest TKL Wordpress appliance?  Is the latest TKL Wordpress appliance more secure for example than prior versions?  I see in my logs that I've gotten a few of the old shellshock bash bug attacks (my system seems OK so I am assuming such attacks are harmless on 14.2 based appliances) so making sure I have the latest updates and versions is pretty important for overall system security and reliability.

Jeremy Davis's picture

Sorry this is a long one...

v14.2 is based on Debian 8 aka "oldstable" aka "Jessie". We're a bit behind schedule but we are currently working on our v15.0 release which will be based on the current Debian stable (9/"Stretch").

Debian packages

If you weren't already aware, it's probably worth noting that on Debian stable, generally you will not get an updated version of any particular software. Instead the version that you start with, will be the version for the life of the distro, with any security issues addressed by a backported patch.

The package version will get an update bump, but the Apache version will stay the same. E.g. the current Jessie Apache package version is 2.4.10-10+deb8u11; that means Apache 2.4.10, I'm not 100% sure on the '-10' but IIRC that is incremented when patches are applied during the testing phase. Then reading from the plus sign, it's a Debian 8 ('deb8') package, update number 11 ('u11'). After the next sec update it should be 2.4.10-10+deb8u12 (i.e. update 12). You can check the current Apache package version and see if any updates are available with the following:

apt-get update
apt-cache policy apache2

Security Updates

As we only auto install security updates, there may be times when the version installed is not the latest package version. Generally these are safe to update, but they aren't as well tested as security updates, so we don't auto install them.

The automatic security updates will automatically install any Debian security updates, but will not automatically upgrade non-security updates. And it won't upgrade to the latest Debian stable. Ever since Squeeze (Debian 6, the basis of TurnKey v12.x) every Debian release is LTS (Long Term Support). Debian Jessie will be supported with security updates until April 2020. It's also worth noting, that although kernel security updates will be auto installed, you will need to reboot to load a patched kernel.

Please note that that the auto security updates generally only apply to Debian packages. They do not include WordPress itself. That is installed direct from WordPress. We do enable WordPress minor version auto security updates, but it will not necessarily auto update to the latest WordPress version. Generally WordPress updates are very straight forward and work smoothly, but we erred on the side of caution and didn't enable auto major version updates. You may wish to do that, although there is a risk that something may break if it's done unattended.


Re shellshock specifically, Debian Jessie has bash v4.3 (4.3-11+deb8u1). That was the version released to address all of the shellshock variations. So unless new shellshock variations are discovered, you're safe. Even if they are, backported patches will be created and released to the security updates repo (which will then be auto installed by TurnKey).

Upgrading TurnKey

Once we have v15.0 ready for release, you could upgrade to a Debian "Stretch" base (just like you would upgrade vanilla Debian Jessie to Stretch). Although, as we don't package all of our tweaks, we generally recommend using TKLBAM to migrate data from an old server to a new one. We have a doc page that provides a suggested workflow for migrating to v14.x. We'll do a similar one for the upgrade to v15.0, although we anticipate that the transition from v14.x to v15.0, will generally be much smoother than the v13.x to v14.x was.

Our minor releases (e.g. v14.1, v14.2, etc) are generally more useful for new users than they are for existing users. Depending on the particular appliance, there may still be advantages to migrating to the latest minor release, but usually not for an appliance such as WordPress.

Apache config

The Apache config you have used is in legacy Apache =here). Obviously it still works, but it's probably worth updating to the new format, i.e. swap this:

Order Allow,Deny
Deny from all
For this:
Require all denied

Add new comment