[wp-hackers] Detecting the present botnet attacks

[David Anderson]

Hi,

As most of us know, there are ongoing brute-force password attacks going 
on worldwide, that are distributed and hence can't be prevented with 
single-site "deny after X failed logins" heuristics. The individual IPs 
only connect to each site once or twice. We are protecting some of our 
websites with BruteProtect, but unfortunately not enough people are 
using that solution yet to make it effective - in our analysis of our 
logs, it catches about 10% of bad hosts. That's better than none, 
especially if a site gets broken into, so we'll persevere with it - and 
mention it so that others may perhaps take a look at it and help boost 
that figure for all the users!

But regardless of that, the multiple attacks on various websites on the 
same box are causing significant resource usage - perhaps around 25% of 
all resource usage on the server in question. We'd like to kill the 
attacks at an earlier stage - before the full WordPress load completes. 
We're thinking of adding a single line of code using PHP's 
auto_prepend_file feature (in php.ini) that will immediately die if an 
attack pattern is detected. This solution has the beauty of being 
something we can centrally manage fairly easily (our webserver's 
configuration file is written on-the-fly by a shell script, including 
per-site PHP-options). (Adding plugins to every site would be much more 
cumbersome).

This line would detect that the URL being visited is wp-login.php, and 
then apply some other tests. Looking at the logs we've collected from 
the attackers, we see these two patterns:
1) The POST payload does not include [wp-submit] => 'Log In', which you 
would have if logging in from the normal wp-login.php page.
2) The usernames are all one of:
* admin
* administrator
* the domain name of teh website being attacked
* {domain} (literally - presumably a bug in an earlier of the attacker's 
code)

So, we're considering banning all those usernames from the hosted sites. 
But, it looks like we could get a quicker result by blocking based on 1) 
instead. Question: Does anyone know if that's reliable? i.e. are there 
scenarios in which a likely user POST to /wp-login.php does not include 
that field? (Note that the popular Theme My Login plugin doesn't POST to 
/wp-login.php, so differences on its login form aren't important). (Of 
course too, if someone's built some legitimate automated WP tools that 
don't include that field, then this'll break them too - but we can deal 
with that if it ever happens. I'm just interested in normal Joe User WP 
usage).

Of course we could also combine 1) and 2) to reduce the risk. But I'm 
still interested in the answer to the question.

Many thanks,
David

-- 
WordShell - WordPress fast from the CLI - www.wordshell.net