More on WordPress xmlrpc denial of service attacks

The attacks on WordPress using xmlrpc.php service are rather common. I already mentioned that you could filter out unwanted user-agents using the redirect capability of Apache. That would, however, take care only of obvious cases, where you see that this particular user-agent could not possibly be your reader. What do we do if the user-agent looks normal?

Well, if you do not need your xmlrpc services, you could block it off completely with mod_rewrite for all access:

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{REQUEST_URI} ^/xmlrpc.php.*$
 RewriteRule .* - [F,L]
 </IfModule>

This will return a 403 for all requests. It is basically equivalent to what you did with “files” directive where you specify “Deny all” for a file path. This will block all access to xmlrpc completely though, for all purposes, so you will not be able to use the service at all. Which is not always acceptable.

But the good news is that the set of rules is extensible with other conditions and you could block only the requests with particular user-agent again now. For example:

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /
 RewriteCond %{REQUEST_URI} ^/xmlrpc.php.*$
 RewriteCond %{HTTP_USER_AGENT} ^.*NET CLR.*$ [OR]
 RewriteCond %{HTTP_USER_AGENT} ^.*Mozilla/5.0.*Windows.*NT.*6.*$
 RewriteRule .* - [F,L]
 </IfModule>

And so this becomes an extensible list of rules. You check your logs, see suspicious requests and add them to the list of rules. Stack the additional rules with [OR] flag at the end of the condition line.

Now we have a set of rules that blocks some of the accesses to the xmlrpc based on the user-agent reported by the attacker. We could also add filtering by referrer or IP ranges and so on. The arms race, you get the picture.