D&C GLug - Home Page

[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]

[LUG] An observation on wordpress and scripted attacks

 

Not really a linux issue, but wordpress was discussed in here at
length before and I noticed something tonight. Apologies if I'm
rambling, been at the port. :)

I recently moved a very low use website that runs wordpress from one
server to another, updated the dns and job done. The site's been round
a few years and probably shows up on a header search on google for
wordpress.  I forgot to transfer some .htaccess rules I had that
blocked access to wp-login.php apart from two static IPs genuine users
would be coming from.

Some time later, I idly noticed a lot of 200's on wp-login.php in
apache's logs so I installed a plugin I've used before; Limit Login
Attempts.

24 hours later I checked the logs for that site and saw quite a list.
In that time it had blocked 127 ips. Each of those IPs had failed to
guess the admin password 3 times in five minutes. Whilst I've been
writing this, another three notifications have come through. They are
of course from scripted attacks, but the tools used are very well
coordinated; the ips used are geographically diverse so probably
compromised machines.

As before, WP is not insecure, just popular - that they're trying to
bruteforce the admin account just shows it's the easiest way in rather
than another exploit, and it would be good to make some basic
precautions if you, like me, use wordpress (or any other common
platform that has a predictable username login). Some that occur are;

Limit ip to wp-login.php by a .htaccess rule. Anyone not from your
static ip gets a denied message.

Move webroot/wp-login.php elsewhere and update the links. (may need
doing inside).

And the easiest one; change the admin's username to something else.
Every single one of these attempts is on that username.

Maybe more ways?


I've found similar results when playing with Kippo (a honeypot shell)
and exposing port 22 to the internet. Automated ssh probes happened
immediately and were occuring once every few minutes. Again, easiest
solution against these scripted attacks is to move SSH away from Port
22. (And maybe run fail2ban if you can't do that, or restrict ip's if
that's possible)

Maybe one day more effort will be made to isolate traffic from
compromised or malicious computers, but I fear it won't be any time
soon.

-- 
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/listfaq