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.
…
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. …
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. …
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. …
I’ve been experiencing the same increased frequency of attacks against WordPress’ integrated XML-RPC service in recent months as reported by many other site operators. The attacks have been covered well elsewhere, but I wanted to chronicle what I’m seeing and share some remarks. …
