Press "Enter" to skip to content

How To Put Your Shields Up To Protect Your WordPress Site

In case you haven’t heard, the popular open source website platform, WordPress, is under attack by black hat hackers. These attacks are being waged primarily against sites using the WordPress platform that are not being hosted on wordpress.com. According to KrebsonSecurity, a small botnet is being used to break into the back door of WordPress sites in an apparent attempt to build a super botnet:

“According to Web site security firm Incapsula, those responsible for this crime campaign are scanning the Internet for WordPress installations, and then attempting to log in to the administrative console at these sites using a custom list of approximately 1,000 of the most commonly-used username and password combinations.

“Incapsula co-founder Marc Gaffan told KrebsOnSecurity that infected sites will be seeded with a backdoor that lets the attackers control the site remotely (the backdoors persist regardless of whether the legitimate site owner subsequently changes his password). The infected sites then are conscripted into the attacking server botnet, and forced to launch password-guessing attacks against other sites running WordPress.”

Although the first official news we heard on this attack was in a report on PCWorld a little over a week ago, for several months we here at FOSS Force have been keeping a wary eye on our sites as we’ve witnessed increasing attempts to crack the security we have in place on our WordPress installations. Last week we were especially interested when a WordPress test site that’s not easily reachable by the public began to come under attack.

The type of brute force attack that’s being used in this case is fairly common and is relatively easy to defend against.

Upon installation, all WordPress installations default to an account with the username “admin.” In our case nearly 100% of the attempted attacks have tried to break into the “admin” account. The reason for this is simple. The black hats know that WordPress defaults to “admin” and that many website owners don’t bother to do away with the “admin” user, even though they are advised to do so by the WordPress folks in their installation instructions.

Although doing away with the default “admin” account used to be inexplicably difficult, that’s no longer the case. To do away with the “admin” account, simply create a new user account (under “Users” in the right hand column of the Dashboard) with a strong password containing both uppercase and lowercase letters, at least one number and at least one special symbol (more is better). After giving this new user full administrative privileges, log-out of the system and log back in using the new user name you’ve created. Then go back to “Users” and delete “admin.” When prompted, apply all of “admin’s” posts and links (if any) to the new user you’ve created and you’re done.

This step alone will make your site much more secure than it was, but there are other steps you need to take in order to protect yourself further from brute force attacks–as some attackers will invariably look for other user names than “admin.”

A brute force attack is based on the premise that a computer, or a botnet (which is a group of hijacked computers acting as one), can continue to attempt to guess at usernames and passwords in rapid succession, using such speed that eventually they’ll get in. This is especially true if the password is merely a word from the dictionary, no matter how obscure the word is. Security experts have demonstrated over and over again how quickly such a password can be cracked by using a brute force attack, which is why a “gibberish” password utilizing upper and lower case letters, numbers and symbols is recommended. Not so long ago, a password of eight characters was deemed sufficient length. Nowadays it’s recommended that your password be ten or more characters long.

The next move is to stop the “brute force” part of the attack–to stop the hacker’s ability to continue the attempt to pick your lock until successful. Remember, the brute force attack depends on the attacker being able to continue to try username and password combinations in rapid succession. That approach can be stopped by using a plug-in that only allows a particular IP address a limited number of attempts before locking that user out of the computer for a specified amount of time.

Christmas Mega Sale Stackable Discounts!

One of the best plugins for this purpose was called Login-lock, but it doesn’t seem to be under development or supported any longer. We’re currently evaluating another plugin, Apocalypse Meow, that essentially does the same thing. This plugin lets the site administrator decide how many login attempts are allowed before blocking that IP address from accessing the login page. The administrator also can configure the length of time, in seconds, to keep someone blocked after a failed login attempt. The default is 12 hours (43,200 seconds) which we have lowered to an hour (3,600 seconds) on our test site, because we think that’s sufficient. If an attacker can only make three attempts to guess a username and password each hour, odds are he’s not breaking into your site anytime soon.

Another nice feature of this plugin is that it let’s you set IP addresses to be exempt and ignored by the plugin. I’ve exempted my own IP address to make sure I don’t accidentally lock myself out of our test site.

Again, you can protect yourself from the brute force attack that’s currently being waged against WordPress sites by doing away with the “admin” account, using strong passwords and by limiting the number of attempts that can be made to login to an account. There are other things that you can do to make your WordPress site more secure as well–but we’ll save that for another article.

4 Comments

  1. Collin O'Reilly Collin O'Reilly April 23, 2013

    Nice in theory – but doesn’t work with my setup, ubuntu server 12.04 (all updates installed) and WP 3.5.1. Would be great if it did work – saw at dev’s site someone one else using ubuntu had same issue but problem miraculously “went away” for that user. Wish I could say the same for me, lol…

  2. Chris Hall Chris Hall Post author | April 23, 2013

    Colin, getting rid of a WordPress user has nothing to do with what server you’re using. Also, installing a WordPress plugin that limits the number of login attempts on your WordPress site has nothing to do with what server you’re using. This is all WordPress specific and has nothing to do with your server.

  3. Collin O'Reilly Collin O'Reilly April 24, 2013

    I was talking about WP plugin Apocalypse Meow. Its obvious as dirt to remove the admin user, of course. Sorry I did not clarify.

  4. Chris Hall Chris Hall Post author | April 24, 2013

    Are you referring to this page: http://wordpress.org/support/topic/no-log-in-history ?

    Are you having the same problem as on the developers help forum, with the log-in history problem and not being able to exempt your own IP? I’m assuming you’ve tried all of his suggestions to the other party.

    It actually reads to me like the other party might have had a conflict with another plug-in, which somehow got resolved when he changed the plug-in’s PHP file, as per the developer’s request.

    Have you tried disabling all of your other plugins to see if it works then? If so, you can activate your plugins one by one until you find the problem plugin. At that point, if it’s a plugin you need, you can contact the developers of both (Apocalypse Meow and the one in conflict) to see if you can find a work around. When you’re deactivating your plugins, don’t leave a couple running because you’re sure they can’t be the ones in conflict. I’ve once had a plugin I was absolutely sure couldn’t be the source of the problem turn out the be the problem – to my chagrin.

    My guess is, when you deactivate all of your plugins, Apocalypse Meow will work, and it will continue to work after you reactivate your plugins. I’ve seen that happen, and from the user’s experience on the support page, I wouldn’t be surprised if that doesn’t provide you with your own “miracle.”

    If all of this fails, however, you can always go to the developer’s forum. He seems to be willing to work closely with users.

Comments are closed.

Latest Articles