What appears to be a botnet (or at least an uncountable numbers of different IPs) are sending POSTs to Wordpress's xmlrpc.php. e.g:
Code: Select all
197.202.32.133 - - [31/Jul/2014:12:43:41 +0100] "POST /xmlrpc.php HTTP/1.1" 403 1234 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
79.178.9.178 - - [31/Jul/2014:12:43:44 +0100] "POST /xmlrpc.php HTTP/1.1" 403 1234 "-" "Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)"
2.50.55.13 - - [31/Jul/2014:12:43:45 +0100] "POST /xmlrpc.php HTTP/1.1" 403 1234 "-" "-"
220.255.2.122 - - [31/Jul/2014:12:43:48 +0100] "POST /xmlrpc.php HTTP/1.1" 403 1234 "-" "-"
I'm seeing this on two systems - one has ASL, one does not.
On the system NOT running ASL, this attack causes load levels to increase to 15 while the attack is in progress.
I can reduce the load back to normal and prevent further issues on the site being attacked by adding something like this to the site's .htaccess :
Code: Select all
RewriteRule ^xmlrpc\.php$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]
Obviously this rule prevents legitimate use of xmlrpc but I don't particularly care as none of the sites use it in any way.
On the system protected by ASL, things are different.
mod_sec intercepts and blocks the POSTs and returns a 403. The rule being triggered is
392301: Request Containing Content, but Missing Content-Type header
This is fine and great and exactly what we want.
However, things go wrong as a result of the Active Response.
Because of the nature of the attack, large numbers of IPs are added to the firewall. Periodically, these IPs get deleted after the shun time expires:
Code: Select all
/bin/sh /var/ossec/active-response/bin/asl-shun.pl delete [stuff]
The main issue appears to be memory - during the shun deletes, lots and lots of memory appears to being consumed, and I can't figure out why this might be so.
On one occasion, when I made a configuration change to ASL in the middle of one of these attacks, load hit 500+ while ASL tried to restart as it was trying to delete scores of entries at a time and the system (VMware) kept killing the shun delete processes due to oom conditions.
I suppose I could avoid the load issue by turning active response off for this particular rule. Problem is then solved, I guess, and since mod_sec is returning a 403 everything is happening exactly as I'd want it and all is well.
Nevertheless, I would like to figure out if there might be a better solution. This apparently huge memory use during the shun deletes bothers me. The system in question has a whopping 16Gb of RAM and plenty of processing power - this is not a lightweight VPS.
Has anyone else encountered something similar?