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.
As a baseline measure of how much traffic should normally occur in the absence of attack activity, metrics dating from before waves of attacks of this type first appeared consistently recorded xmlrpc.php request incidence down around less than 0.3% of what my stats package considers viewed site traffic. Then, during the several months when attacks were going unmet with any kind of response, attack traffic grew significantly to anywhere from around 25% to as much as over 40% of all page views – equating to tens of thousands of unchecked attacks per month.
I instituted the new countermeasures described in my last article in late September, and they’ve been running without further modification ever since. For October, the new traps curtailed XML-RPC request incidence to 0.5%, comparing very favorably with the prior baseline. For November, XML-RPC request incidence amounted to 2.9% of viewed traffic, higher than I would like, but still much lower than when attacks were going uncontrolled.
Considering that I (perhaps unwisely) disclosed the exact method of operation of my countermeasures including all the relevant timing parameters here on the site to be freely had by prospective hackers, I am very satisfied with this performance.
The fail2ban jail operates very effectively against attacks emanating from individual IP addresses, cutting them off, in the case of my configuration, for 24 hours after three offending attempts. Attacks trapped this way contribute only a few xmlrpc.php requests to the logs, since the attacking IPs spend most of their time blacklisted. Most of the attack traffic I originally set out to address with the new countermeasures fell into this category.
However, fail2ban is ill designed to counter distributed attacks from botnets, in which requests tracing back to essentially a single command server systematically arrive from hundreds of different worker IPs. November owes its figure of 2.9% XML-RPC request incidence to such an attack near the start of the month, in which I suffered a steady stream of hundreds of xmlrpc.php requests over the course of several days.
Slow distributed attacks were leaving such diffuse traces in the logs before, compared to the first type, that I believed them to be insignificant in amount. So it’s difficult to say whether this episode was really something new. In any event, it was a known limitation. The new traps were never expected to be effective against botnets, a mode of attack unsuited to countering from iptables.
So, I believe I’ve mitigated this exposure on my site to my satisfaction. That’s one down, tens of millions of still exposed self-hosted WordPress sites. I’ll be keeping my eyes peeled for any new unusual activity.