Blocking /xmlrpc.php Scans in the Apache .htaccess File
Someone out there on the internet is repeatedly hitting this blog's /xmlrpc.php service, probably looking to enumerate the user accounts on the blog as a precursor to a password scan (as described in Huge increase in WordPress xmlrpc.php POST requests at Sysadmins of the North). My access logs look like this:
1 2 3 4 5 6 7 8 |
|
By itself, this is just annoying -- but the real problem is that the PHP stack is getting invoked each time to deal with the request, and at several requests per second from different hosts this was putting quite a load on the server. I decided to fix the problem with a slight variation from what is suggested in the Sysadmins of the North blog post. This addition to the .htaccess file at the root level of my WordPress instance rejects the connection attempt at the Apache level rather than the PHP level:
1 2 3 |
|
Which means:
- If the requested path is /xmlrpc.php, and
- you are sending this particular agent string, then
- send back a 403 error message and don't bother processing any more Apache rewrite rules.
If you need to use this yourself, you might find that the HTTP_USER_AGENT string has changed. You can copy the user string from your Apache access logs, but remember to preface each space or each parenthesis with a backslash.