If you run a WordPress blog you may have heard about the brute force password attacks that have been going on for a few months now. If you haven’t then there’s a pretty good chance that you’ve done nothing to protect your site and Russians control your site.
Up until today the attack has focused on the “admin” username and trying to guess the password over and over. In a sign that the attacks are continuing and evolving we noticed a slightly updated tactic of guessing the password for an accounts called “adminadmin” and “administrator.”
While the change may be subtle the attack is clearly getting slightly smarter having figured out that not so savvy WordPress administrators thought they would be smart and call their admin account adminadmin or administrator to evade detection. Think again not very crafty admins.
WordPress does not require an account called admin (or anything in particular) in order to operate and that account should be removed or never used to begin with. All accounts should have strong passwords that cannot be guessed with a dictionary attack.
Additionally plugins like Login Security Solution and fail2ban can be used to thwart or slow attacks and enforce password changes. While not helpful in this particular attack tools like CloudFlare can be leveraged for additional security for many of the other ongoing security threats. But what we have seen is that most of the attacks don’t come via a URL but instead target the IP of our serve directly which means those attacks never pass through the CloudFlare network.
Aside from the WordPress admin attacks an unknown and very stealthy Apache attack has been highjacking sites.
Update 1: The latest usernames to be tried are “adm”, “admin1”, “root” and “support”, “{domain}”, and the actual domain name minus the .com so for us they’re trying “crasstalk”.
Update 2: The attacks continue. One thing I considered doing was feeding the failed WordPress logins into fail2ban, but the problem is a lot of them come via our connection between CloudFlare and our hosting provider, or at least that’s the IP that shows in the logs. I want to avoid banning that IP so that’s not a workable solution. But for people who aren’t using such a setup taking the failed WP login IPs and dropping them in a log file that fail2ban monitors is a great solution.
What I’ve done instead is to implement a CAPTCHA on the wp-login page. This has really done the trick. Originally the failed logins were coming in such great numbers that they were essentially DDoS’ing the site and the Login Security Solution plugin was exacerbating the problem by holding onto an Apache connection. The bot-nets are unable to deal with a CAPTCHA and after five failed CAPTCHAs the IP gets banned for the day by the plugin. For good measure I then take those IPs and ban them permanently in the firewall.
