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.
So, now it’s been over 3 hours since activating the plugin. And the attack has (for now) been blocked.
Lessons learned:
- Do not (ever) use actual words in passwords. Ever. Generate something secure, and use a tool to store/retrieve them.
- 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.
- Install Limit Login Attempts to stop single-IP-address attacks.
- Install Botnet Attack Blocker to stop distributed botnet attacks.
- using an old version of the WPMUDev Blog Activity plugin [↩]