I had written a basic securing wordpress article back in February of this year. Since then I’ve done a bit more research and came upon the idea of using Apache to help secure the administration directory and scripts, making it more difficult for intrusions to take place.
It’s always a good idea to try and protect your sites as best you can. When dealing with open source software, the code is visible to the world, so any exploits that have been found can travel fast. Issues and security flaws get fixed on well known open source projects like WordPress, but it also leaves an un-upgraded system easily open to attack. One option to add a second layer of protection by using Apache server’s built-in directory password functionality. Thankfully, Askapache made a decent plug-in to save a good deal of time playing around with Apache .htaccess settings and researching the necessary code. While the plugin needs work, it functions with a bit finesse on your part.
Download the Askapache Password Protect plug-in and upload the unzipped directory into your plug-ins directory on the website.
http://wordpress.org/extend/plugins/askapache-password-protect/
If you use clean URLS, you will probably need to do the steps below as I did:
Create an empty error.html file and upload it into your domain’s main directory.
Download and then add these two lines to your .htaccess file in the domain’s main directory (eg. site.com directory where WordPress’s index.php resides):
ErrorDocument 401 /error.htmlErrorDocument 403 /error.html
To the top of your .htaccess file and upload the file back to the server.
Check out these two sites for more information why this might be necessary:
http://developedtraffic.com/2007/05/27/wordpress-admin-password-protection-404/
http://textpattern.com/faq/173/password-protected-directories-with-htaccess
In my case I needed to do that. It took me quite a while to figure out why, once I set up the apache plugin, I was getting a 404 or 403 error when I tried loggin in to administer the site. It has something to do with how requests are routed. In the my case where I have clean URLS (mod_rewrite), the requests were getting routed to WordPress and not directly handled by Apache. So some type of conflict would not allow the Apache password dialog to popup or really even let anything but WordPress handle the request (returning that 404 error because WordPress had no dynamic page for the request).
Once you have the plug-in uploaded, login into your site admin and activate the plug-in. Visit the configuration screen…
Perform the test to make sure your server has all of the necessary components enabled. In this step I had one warning message about the main script file not being found, but it didn’t seem to cause any issues.
It’s best to select digest authentication if possible and then fill in the password and username of your choice.
In the security module screen, the primary items to enable are the “password protect wp-login.php” and “password protect wp-admin” directory. These are the primary pieces of code in WordPress that could be open to attack by users.
Enable the password protect the wp-admin directory first, and then continue with the wp-login.php file. You might need to close your browser at this point as the protection is enabled at that moment, blocking you until the apache username and password are enabled.
If you have issues logging in, you need to FTP into your hosting and download/edit your .htaccess files in your main site directory (root) and the wp-admin directories. Remove all of the text the plugin added. After that text is gone you should be able to login into the site as normal.
Another issue with the current plugin is that it doesn’t perform the server tests properly if your wp-content directory is in another folder (as specified in your wp-config.php file). So for the time being, your content directory should stay /wp-content/ for the plugin to function as intended.
I noticed when I tried to login through the wp-login.php file, clicking cancel still brings the user to the login page (minus graphics and css files).
I don’t like that solution, so in addition to Askapache’s plugin I think it’s a good idea to add this to the .htaccess file as well:
# protect wpconfig.php# do not allow login access from this script (use /wp-admin/ instead)
NOTE: I’m pretty sure you can only add the wp-login.php .htaccess deny item until after Askapache Password Protect has been installed and configured. Otherwise you won’t be able to login.
Completely deny all access to the wp-login script file. This keeps that second layer fully in effect for the admin area. Otherwise a person could hit that page to find out the wordpress password.
While you are at it, deny access to the wp configuration file.
While I don’t know if order of items in the htaccess file matters, I have things ordered like this:
# error document items