Tag: ucalgaryblogs

blocking distributed botnet attacks against WordPress (multisite)

I checked the Activity Monitor page1 for UCalgaryBlogs this morning, and noticed that there had been several thousand attempts by people (or “people”) to login using the usernames “admin” (the default WordPress admin account, which isn’t what’s used on UCalgaryBlogs) and “siteadmin” (which is the username for our server – scripts must have sniffed it from blog posts on the main site…)

Curious. I’d installed the fantastic Limit Login Attempts plugin to prevent people from brute-forcing logins, but that plugin only kicks in if the same IP address hits the login form repeatedly. This botnet attack was different – each request had a different IP address, and a different user-agent string. So Limit Login Attempts wasn’t blocking them, and my htaccess user-agent filter wasn’t catching them because they were either valid user-agents, or close enough to get through.

Looks like they were using a dictionary attack, starting at aardvark and working through zyzzyva. Thankfully, I don’t use actual words for passwords, but I decided to change the password to use something stronger than I’d been using. Thanks to 1Password for making that trivial. I don’t actually know the password now. And it has nothing to do with any word found in a dictionary (except that it might use some of the same ascii characters).

Some quick googling for “wordpress distributed botnet protect” turned up a new (to me) plugin called Botnet Attack Blocker. Sounds interesting. It was written in response to some recent distributed botnet attacks, and handles logins spread across different IP addresses.

Installed. Activated on the main blog site. And the attack stopped instantly. I can still login from the campus network even if the plugin kicks in and blocks admin logins. But the botnets can’t continue to brute-force passwords.

Screen Shot 2013 10 16 at 11 48 40 AM

So, now it’s been over 3 hours since activating the plugin. And the attack has (for now) been blocked.

Lessons learned:

  1. Do not (ever) use actual words in passwords. Ever. Generate something secure, and use a tool to store/retrieve them.
  2. Keep up to date on the security environment for the tools – including WordPress. I hadn’t been aware of a distributed botnet attack problem recently, nor of a plugin developed specifically to block that.
  3. Install Limit Login Attempts to stop single-IP-address attacks.
  4. Install Botnet Attack Blocker to stop distributed botnet attacks.
  1. using an old version of the WPMUDev Blog Activity plugin [↩]

UCalgaryBlogs.ca is 4 years old

The latest iteration of the campus blogging platform, UCalgaryBlogs.ca, is 4 years old today. It had run previously as a Drupal community (started way back in 2005!), before migrating it to WordPress Multiuser, and now just plain old WordPress. For its first year, it basically sat idle. Then, starting in the fall semester of 2008, things kind of took off. Slowly, at first, and then in bursts at each new semester.

Screen Shot 2011 10 03 at 11 08 46 AM

I’ve been managing the service on my own the entire time, on server space scrounged from surplus equipment, on a budget of essentially $0. Sometimes, it seems totally worth it, and it’s rewarding to see the awesome stuff that faculty and students are doing with the platform. And then the spammers hit, and I wonder why I bother. Hoping to find a happy medium in there somewhere, and get it moved onto an Officially Managed Server Environment™ as soon as possible, so we can let things scale a little more…

stopping splogs – the nuclear option

I’ve been battling sploggers on UCalgaryBlogs continually. I just finished marking about 50 users/blogs as spam – that’s since yesterday afternoon. I could easily stop the problem outright by requiring people to use an @ucalgary.ca email address to create a site, but that goes against the possibility of anonymity, and many (most!) students don’t use their campus email addresses.

I currently run [Bad Behavior](http://www.bad-behavior.ioerror.us/), as well as [ReCaptcha](http://www.google.com/recaptcha). They stop the automated splog creation scripts, but there seem to be a LOT of people employed around the world to manually enter forms in order to get around captcha and anti-spam/splog techniques.

In looking through the WordPress.org forum on multisite (nee WPMU) issues, I found a new post called “[Splog Spammer Final Solution?](http://wordpress.org/support/topic/splog-spammer-final-solution)” It sounded a little like overkill, but when I thought about it, almost all splogs created on UCalgaryBlogs have come from a handful of countries. Countries where it’s not very likely that students and faculty will be creating new sites from. So I decided to try it out.

The forum post [links to a page containing lists of IP addresses and blocks](http://www.countryipblocks.net/networking/top-10-global-spammers-1q-2010/) belonging to countries where splog/spam activity is off the charts. All you do is copy some text, drop it into your .htaccess file, and hey presto. No more sites created from those countries.

Initially, I just banned all access from those countries. But that felt like a pretty slimy thing to do. So I stepped back and am now only blocking access to the site creation form wp-signup.php from those countries. If anyone affiliated with the university needs to blog while traveling the world, they’re free to do so, but they’ll need to have created the blog site from outside the Spam Zones. They should be able to access their sites, post content, etc… from anywhere.

I just tested the new splog-blocking technique, and it appears to be working. I’m really curious to see if it makes a dent on new splog creation.

The wp-signup.php script is [blocked](http://www.websitepulse.com/help/testtools.china-test.html) in Spam Zones:

Screen shot 2010-10-05 at 10.50.54 AM.png

But the rest of the service is available as usual:

Screen shot 2010-10-05 at 11.33.37 AM.png

The .htaccess file for UCalgaryBlogs now contains this at the bottom (after the WordPress stuff):

# block the fracking evil splog spammers

order allow,deny

(the contents of the various country block files go here)

#
allow from all

**Update:** Duh. Instead of trying to blacklist IP addresses and blocks of suspected spammers, it makes more sense to whitelist IP addresses and blocks that are likely to be used by valid users trying to create sites. I’ve modified the .htaccess file to deny access to wp-signup.php to everyone but those accessing from IP addresses that don’t smell suspicious…