David Anderson
2013-07-10 12:14:10 UTC
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
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
WordShell - WordPress fast from the CLI - www.wordshell.net