11 Aug
2013
11 Aug
'13
8:08 p.m.
On one server, Fail2ban has banned over 150 IP addresses so far today
for attempting to hack into WordPress sites. (If you run WordPress and
you don't have protection against this, you need it!) The volume is such
that it managed to crash the MySQL server on one VPS today.
One suggestion I have seen is to use Apache's authorisation to limit
access to wp-login.php, but that a) involves telling a bunch of real
people a password and some of them could forget their own name and b)
increases the size of the apache process by about 20% over the slimmed
down version with as few modules enabled as possible that I have been
running.
Anyone have any other suggestions?
Ian
11 Aug
11 Aug
8:26 p.m.
On 11/08/13 21:08, Ian wrote:
On one server, Fail2ban has banned over 150 IP
addresses so far today
for attempting to hack into WordPress sites.
What sort of 'hack' are they attempting? Trying to register as a user,
or something more technical?
If it's the former, then I've found that adding a hidden (by CSS) field
to the registration form, and denying access to bots that stupidly
fill-in the hidden field, blocks nearly all such attacks.
cheers
Chris
--
Chris Dennis cgdennis(a)btinternet.com
Fordingbridge, Hampshire, UK
8:55 p.m.
Chris Dennis asked:
What sort of 'hack' are they attempting?
Trying to register as a user, or
something more technical?
No, this is a brute force attempt to login, typically as 'admin' (the
shamefully still default user name for a new WordPress install). Even
if you sensibly don't have a user called that, it still involves
loading PHP and doing some MySQL accesses to check.
If it's the former, then I've found that
adding a hidden (by CSS) field to
the registration form, and denying access to bots that stupidly fill-in the
hidden field, blocks nearly all such attacks.
Hmm, I've used 'do they give an ICQ user ID?' as a bot test
successfully in the past, but I'd be surprised if it worked this time.
I'm also reluctant to start playing with WP core files, because it can
mess up the upgrade process.
Ian
9:04 p.m.
Hi Ian,
If I remember rightly, you can make the wordpress script die before it
loads much at all if the username "admin" is entered (as long as it's not
your username!) It would involve playing with the script, but it's a
relatively simple addition and it can be removed before an upgrade.
12 Aug
12 Aug
10:50 a.m.
Daniel Case said:
If I remember rightly, you can make the wordpress
script die before it
loads much at all if the username "admin" is entered (as long as it's
not your username!) It would involve playing with the script, but it's a
relatively simple addition and it can be removed before an upgrade.
I have found at least one wp-login.php patch that does the 'are they
accessing this properly?' testing, but not this one.
After about another hundred IP addresses were banned between midnight
and 1am, eighty more in the following hour, and another sixty after
that... I gave up and went down the Apache authorisation route on the
basis that the sooner in the process that they're stopped, the better.
I did put the login details in the authorisation's popup message, and
no-one's complained yet :)
Ian
3:50 p.m.
I said:
After about another hundred IP addresses were banned
between midnight
and 1am, eighty more in the following hour, and another sixty after
that... I gave up and went down the Apache authorisation route on the
basis that the sooner in the process that they're stopped, the better.
Another two hundred and sixty banned in the hour after lunch (which
translates as over 1,300 naughty attempts to login), but Apache seems to
have coped OK.
Ian
3920
days inactive
3921
days old
5 comments
3 participants
participants (3)
-
Chris Dennis -
Daniel Case -
Ian