I recently noticed a lot of requests to this and other WordPress sites’
xmlrpc.php file. By “a lot”, I mean about 10-20 every second. It wasn’t particularly breaking anything (there aren’t any currently vulnerabilities there that I’m aware of), but it was increasing the load on my server.
My first step was to set an
.htaccess rule to give a 403 response. That at least avoided hitting PHP with all those requests. But Apache still had to process them, so I wanted to take it a step further. I’m already using fail2ban, so I wanted to figure out how to stop these requests at that level instead of waiting until they reach Apache.
First, I needed to create a filter, telling fail2ban what kinds of requests I wanted to block. On my system (Ubuntu), I created a file at
/etc/fail2ban/filter.d/apache-xmlrpc.conf. The file is fairly simple:
[Definition] failregex = ^<HOST> .*POST .*xmlrpc\.php.* ignoreregex =
This tells fail2ban how to parse the log files to find requests for
xmlrpc.php, and where to find the IP address. You might need to adjust the regex if your log files are formatted differently.
Now that we’ve created the filter, we tell fail2ban to use it. We open
/etc/fail2ban/jail.conf and add this rule:
[apache-xmlrpc] enabled = true port = http,https filter = apache-xmlrpc logpath = /srv/www/*/logs/access.log maxretry = 6
logpath parameter to point to your Apache access logs, and adjust
maxretry to taste.
sudo service fail2ban restart
And you should soon find Apache handling far fewer requests. An added benefit to using fail2ban: legitimate requests to
xmlrpc.php (e.g., trackbacks) should still get through.
Update (2013-08-28): This is, of course, a rough first step, and serves me well on my fairly low traffic server. If you’re looking for something more robust, definitely check out Todd’s comment below and read his blog post about protecting your WordPress server.