Back several years ago when XML-RPC attacks on WordPress were prevalent, I shared some techniques here for selectively countering such attacks. Most users, however, just want to shut XML-RPC off completely. They often land on the widely installed Disable XML-RPC plugin. This plugin unfortunately does not fully work. Let me show you why, share some better solutions, and update my unit testing code for Python 3 in the process.
WordPress
Securing the WordPress web application framework and content management system.
One More Check In on WordPress XML-RPC Fail2ban Traps
Just putting out an updated chart showing how this has performed through several additional months of operation. I’ve previously covered what’s happening here in detail when I began to sustain a high volume of attacks, when I implemented the fail2ban based countermeasures, and when I checked in on how the traps were performing four months ago.
Checking in on the Performance of WordPress XML-RPC Attack Countermeasures
Following up on my deployment of WordPress XML-RPC attack countermeasures a few months ago, let’s have a look at how effectively the traps have performed in live operation in the intervening time.
Countering WordPress XML-RPC Attacks with fail2ban
In my last post I began inquiring into the WordPress XML-RPC attacks I’ve been sustaining here on the site. Since then I’ve been further studying the threat and experimenting with responses, and I have now developed working countermeasures and cast them into live operation. These countermeasures involve forwarding telemetry out of WordPress for pickup by the fail2ban facility, allowing for the detection and banning of attackers trying to exploit xmlrpc.php. Where other recommendations call for disabling affected methods or the whole XML-RPC subsystem, my more refined techniques control attacks while maintaining the full service set in operation for valid procedure calls.
