[wp-hackers] Detecting the present botnet attacks

[Brian Layman]

No black list is going to be perfect, but you might try:
http://www.projecthoneypot.org/httpbl_implementations.php

I've had some success with it recently shutting down attacks Joomla 
sites.  Plus it is an Apache module, so no plugin and it works 
automatically for all sites on the server.  Plus projecthoneypot has 
been around for a long time and has a fairly large database.

I've seen no speed or resource issues on the server I've installed it 
on.  That particular server hosts about 100 business sites each with a 
typical traffic level for a non-interactive informational site.

Brian Layman

On 7/10/2013 8:14 AM, David Anderson wrote:
> 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
>