Of bot armies, brute force, admin and WordPress

Hello,

I put in some work this weekend looking at WordPress and reports around the bot army attacking WordPress installations.  Our WordPress install is a complicated beast and that in itself, largely, may protect us from the more simple attacks.  I knew about the possible threat late Friday but family commitments prevented me from looking earlier than 5.30pm on Sunday.  In theory, I shouldn’t be working then and should be spending time with my family but this is important.  Later, we’ll have practices in place to limit the amount of time we spend working on emergencies out of hours.

Initially, I panicked.  I thought I should shut off access to the service.  There was no one to talk to about the issues of leaving the service up or taking it down.  With my partner away for the weekend I didn’t have time to do something rash.  If I switched off the service I would be doing the hackers work.  If I didn’t I risked having to re-install the service.

So, on Sunday I started reading around the problem.  The first few blogs I read around the problem talked about third party pay-for WordPress security modules.   This blog lists some things we can do to protect the service.  Cloud Flare are, effectively, selling a service around WordPress security.  That lead me to look at mod_security for Apache which allows us to ‘patch’ an application without changing the application’s code.  Web application code changes take time.  Then I came across  blogs, e.g. codex.wordpresss.org that explains the current attacks.  The account this attack goes after is ‘admin’.  Big phew!  When WordPress is installed it lets us change the the admin user to anything at all.  Good practice.

With that known and the pressure off I decided to look at black listing functionality for WordPress.  I happened across Better WP Security which has a lot of features and 5 stars from 1300 WP admins.  It looks good but not the sort of thing you can install on a Sunday on a WordPress install as complicated as ours without going through the university’s change advisory board CAB.

With the idea of keeping things simple I started looking at the access_log.  I could see repeated attempts by some IPs to URLs including wp-login.php, /register/, wp-admin, site.  I checked those IPs against Google to see if any security web sites reported them as suspicious and active.  What I didn’t want to do was blacklist IPs from genuine users.  I added this to the root .htaccess:

<FilesMatch ".*$">
order allow,deny
allow from all
deny from x.x.x.x
deny from y.y.y.y
deny from z.z.z.z
</FilesMatch>

This code tails the access_log looking for those URLs:

tail  -f access_log|egrep '404|/register/|wp-login'

today an email popped up talking about an attempt to create a new site using wp-signup.  We have site registration switched off.  This could be important in protecting our service.

This discovery lead me to change my script to rank accesses and discover the major bots knocking on the door:

 cat access_log|egrep '404|/register/|wp-login|site|wp-signup'| \
   awk '{ ips[$1]++ }END{for(i in ips){print ips[i] " " i;}}'| \
   sort -n

One bot has had 52696 attempts.  That this went unnoticed says something about how we work with WordPress (and other web applications.) Popular software will be targeted and we need generic tools to discover the attacks.

Well, that’s it.  I hope it helps.

About c3iq

Opensource, Linux, Unix, Fish, Family
This entry was posted in CELT, Library, Linux SysAdmin, The Commons, The Commons and tagged , , , . Bookmark the permalink.