I wrote previously on securing a fresh WordPress install. Today, I’ll cover several WordPress plugins that can be used with fresh or existing WordPress installations to enhance security. I’m not going to cover recovering a hacked site, or exploit scanning tools like Exploit Scanner or WordPress Antivirus in this tutorial.
As before, I’ll emphasize a few things:
1. Your WordPress security is only as good as the security on your local computer. If you’re not running good antivirus and anti-malware software or are using an insecure wireless connection, none of this will matter.
2. Likewise, if you’re not keeping your WordPress install updated, none of this will matter.
3. I should have at least mentioned this in my previous security article but didn’t: your WordPress security is also only as good as your web server’s security. Since the audience for these tutorials is beginners, I’m going to assume that you don’t have a lot of control over your host’s security settings. So I’m not going to say anything else about this other than to look for a reputable host with experience hosting WordPress.
4. Make sure you’re using a strong password. See step 2 of my previous tutorial.
5. I’m going to assume you already know how to install WordPress plugins.
NOTE: I’m writing this guide for WordPress 2.92, the current stable release. All of these plugins seem to work with WordPress 3.0, but I haven’t thoroughly tested them.
WP Security Scan
Let’s start by checking for the biggest security holes first, using the plugin WP Security Scan.
After you install you should see a new “Security” section on the left column of your dashboard:
Let’s click “Scanner” and check our file permissions, the most crucial of security settings in WordPress. Chances are everything will be shaded green, and everything’s ok. However, if anything’s not set correctly it will be highlighted in red. Changing file permissions is beyond the scope of this tutorial – contact your web host if you need to change anything.
Next, let’s change our database prefix. This is a “security through obscurity” technique. What we want to do is make your WordPress database harder to exploit by using a database prefix other than the default one – this way any sort of generic, automated attack on the database will likely fail because the hacker will be using the wrong database prefix.
BEFORE ATTEMPTING THIS MAKE SURE YOU BACKUP. I can’t stress this enough. I wrote a tutorial on backing up your WordPress tutorial. Even if you don’t use the plugin I describe there, make sure you’ve got a good backup before proceeding.
If you followed my last security tutorial and changed your database prefix during install, you can skip this step.
Otherwise, click “Database” on the Security section. You’ll see something like this:
If you see something other than “wp_” in the field labeled “Change the current” field, then you can skip the next step.
Change “wp_” to something else. It’s highly recommended that you still keep the _ for database readability in the future, however.
Click “Start Renaming”
If this fails, you’ll either have to change the database prefix manually or not at all. Manual changes of the prefix table are beyond the scope of this tutorial.
Secure WordPress
Next, let’s install Secure WordPress. After you install it click “Secure WP” in the settings column of the left column of the dashboard. Most of the defaults should be fine, except one: if you’re not planning on using Windows Live Writer, check the box next to that option and click “Save Changes.”
WordPress Firewall
The steps above will help prevent attacks by hiding information about your WordPress install from attackers, making sure the correct file permissions are set, and plugging a few potential security holes. Next we’ll install some plugins that actually stop attacks on your blog.
WordPress Firewall is a handy plugin for preventing a variety of attacks. This one is especially important if you weren’t able to change your database prefix. It’s quite simple – just install it. There should be no need to change the default settings. Important: WordPress Firewall has only been tested up to WordPress 2.8. It has not been tested with WordPress 2.92 or WordPress 3.0 beta 2.
Bad queries
Block Bad Queries, like Firewall, prevents hackers from performing certain common dangerous actions on your site. This one you just install and activate – there are no settings to change.
Chap Secure Login
If you’re not using SSL to login (once again, beyond the scope of this tutorial), you can use Chap Secure Login to encrypt your password. This is especially recommended if you use a lot of different computers to access WordPress, or frequently use public wireless Internet connections. Chap is another remarkably simple plugin – just install it and activate it and you’re ready to go. Note: you’ll get a warning the first time you login after installing. According the plugin developers, this is to be expected.
Login Lockdown
Finally, we’ll want to protect against brute force or dictionary attacks. In an out of the box WordPress installation, users can attempt and fail to login an infinite number of times. This means someone could try thousands of password combinations until they got the right one. Login Lockdown will ban users from IP addresses that have tried and failed to login too many times.
Install the plugin and click “Login Lockdown” in the “Settings” section. You should get an options menu that looks like this:
If you have a hard time typing your password correctly, you might want to set the “Max Login Retriess” a little higher.
I also recommend using the “Mask Login Errors” option. Normally, if a user types an incorrect username WordPress will return an invalid user name error. But if the user types a correct username but an incorrect password, WordPress will return an invalid password error. This gives someone trying to crack your password an extra hint as to whether they at least have the right username. If you use the “Mask Login Errors” option, WordPress will return a generic “username or password is incorrect” error instead.
Ask Apache
Many people swear by AskApache Password Protect. However, I have not been able to get it to work with my host. Your mileage may vary. If I understand it correctly, this plugin adds an additional password to the /wp-admin directory. If you allow open registrations and have lot of users logging in, you might not want to use this plugin.
Conclusion
There’s still much more you can do, such as using .htaccess to protect directories, moving core WordPress files, and monitoring for exploits. Those are things we’ll have to cover in the future. If you have need to harden things further now, please see the Hardening WordPress Codex entry. Remember no (usable) site will ever be completely secure, but if you’ve installed the plugins above your chances of getting hacked will be greatly reduced.
I’m using WP Security Scan some times.
I always thought WordPress was safe enough (I want to believe :P)
Regards
For the most part it is, if you keep it updated =)
Using the WP Security plugin, I ran the facility to change my Database prefix, and am locked out of my dashboard. It tells me my “admin” username no longer exists. I checked the database and discovered that the prefixes have all been changed as I instructed.
I am a medium level user. Must I now emppty the tables in my database and import my backup to get back in?
Sounds like something went wrong along the way it’s having trouble accessing the table w/ your username and password. So yes, it’s probably time to drop the tables and restore. Are you familiar with phpmyadmin?
I went through the MySQLAdmin drop and import procedure, but was greeted by a first table duplicate error no matter what backup I used.
Then I had my ISP restore my site to yesterday, and that restored my site, but I could not log in, as my login reuest brought up a fake link to what appeared to be WordPress.org, but using a weird URL that did not refer to it.
My ISP was able to fix that, and I have access to the dashboard now.
But it would appear that the plugin download has been hacked. I can’t see what else could have caused the problem since everything was okay until I activated the link in the plugin.
Any ideas?
It sounds like perhaps you had a virus already before you tried to clean all that up.
Look for an article about how to access WordPress when locked out. You’ll find instructions on how to use PHPMyAdmin to change the password in the database and restore access for you.
That’s really really weird. You should drop the plugin author a line. Like Texx says, there could have been something already going on. I don’t know. Here’s how to change the admin user account through phpmyadmin (or MySQL command line):
http://codex.wordpress.org/Resetting_Your_Password
Klint, I see you recommended the Login Lockdown plugin. I am currently using the Limit Login Attempts plugin, which looks to do the same job. Do you have a preference for one over the other? I’m just curious if I should change plugins. Thanks, and thanks for the great article!
I haven’t used Limit Login Attempts – if it works, it works. Does it also mask login errors?
It doesn’t mask login errors, and for that reason, I will be switching plugins. Thanks again for the guide.
I just noticed that the Login Lockdown plugin adds a link to the author’s site on my login page. This might break the WordPress Plugin Repository Guidelines. Restriction #4 is:
Now, I don’t know how anyone else views the login page (public site or not), but it is wise to advertise what security plugins I’m using on the site where hackers will visit? This to me seems like an inherent security risk.
Hm, good catch re: repository rules.
I thought about whether advertising the use of that plugin was a security issue, but I think considering what it specifically does, it doesn’t matter a lot of people know it’s there. I wouldn’t necessarily want WordPress Firewall advertising that it’s installed (of course, now everyone in the world knows I use it), but having ppl know there’s a login attempt limit doesn’t seem like a big deal.
Anyone else have thoughts on this?
Also, it probably wouldn’t be that hard to remove this part of the plugin.
yeah thats what I was thinking, about removing that part of the plugin. You could probably just remove a single line to keep it from doing that no big deal.
So here are the lines to remove the protected by link:
Lines 303 and 304, starting with “function ll_credit_link”
And line 316 which also references ll_credit_link
We need more of this in the core. Along with caching.
Im using wp firewall and success to block any sqli + directory traversal script.
I actually don’t use any secure plugin for my wordpress blog.
However, due to the high risk of attack, I’ve changed my mind and am gonna installed some plugins that you mentioned above. Thanks!!
This is really a very detailed article and because of this, it has become really useful. I am using all the other plugins mentioned, however, I am also interested in trying Bad Queries and WordPress Firewall.
Did your site ever get hacked as well? It is always interesting the stories of how they did and the consequences of the hack.
I probably have more exploit issues with plugins then wordpress itself, so I think securing wordpress is a very good idea. I use all these plugins myself, except the firewall plugin which doesn’t work on my setup either. The bad queries plugin is most definitely useful because its gotten rid of all those error_log files in my FTP directories about missing files when the files aren’t missing, I used to get that issue all the time, thinking my WSP was just being finiky or something, but bad queries fixed that problem immediately 🙂 which has also added to fixing most of the issues I’ve had with making my site as close to XHTML compliance as possible. The plugins still break XHTML compliance, which makes my blog still unreadable by people with disabilities not complying with accessibility guidelines, but WP itself has always been solid and stable as far as security is concerned. its always the plugins that cause more exploits then anything else it seems to me like.
Our developer used WordPress for a film review blog some time ago. The site was on an old server and got hacked. Since that episode we’ve steered clear of WordPress but having read more and more on security and security plugins (especially these blogs) we’re much more inclined to start using it again.
Well, if the server itself wasn’t patched and updated it could’ve been an issue with the server and not with WordPress itself.
We pretty much nailed it down to WordPress at the time, although it did prompt patching across the server.
Gotcha. Since you said “old server” I thought it might have been outdated.