[wp-hackers] Detecting the present botnet attacks

[Sam Hotchkiss]

Hey David-- thanks for the BruteProtect plug!  On that front, we're hard at
work on improving our algorithms-- we've tripled our installed base over
the past 10 days as we've gotten some press, and so we're working on
improving our attack recognition, banning real attackers for longer and
allowing legitimate users to get back in sooner.  You won't need to do
anything, as the updates will happen on our end, but you should see those
numbers improve over the next week.

Best,
Sam

-- 
Sam Hotchkiss :: Principal :: Hotchkiss Consulting Group
122 Front Street, Second Floor, Bath, Maine 04530
P: 207.200.4314 :: F: 207.209.1365
eMail: sam at hotchkissconsulting.com :: Skype: hotchkiss.consulting


On Wed, Jul 10, 2013 at 8:14 AM, David Anderson <david at wordshell.net> 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
>
> --
> WordShell - WordPress fast from the CLI - www.wordshell.net
>
> ______________________________**_________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.**com <wp-hackers at lists.automattic.com>
> http://lists.automattic.com/**mailman/listinfo/wp-hackers<http://lists.automattic.com/mailman/listinfo/wp-hackers>
>