Damn, but that was a long-winded process. I’ve just spent the better part of 4 hours reading and researching why I get (got, its fixed now)  404 errors from wp-admin when I enabled .htaccess Authentication (htpasswd) for the wp-admin directory. It only happened with WordPress MU / Network config.

googling for this error ends up with a mountain of irrelevant threads, inconclusive discussion, and unanswered questions.

WordPress single user 3.1 is not affected by this as there are no ReWrite rules required for the wp-admin. The issue only occurs with MU or Network as it is now called in WP 3.0+ as there is a set of ReWrite rules in the .htaccess file that look like this:

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ – [L]
RewriteRule ^[_0-9a-zA-Z-]+/(wp-(content|admin|includes).*) $1 [L]
RewriteRule ^[_0-9a-zA-Z-]+/(.*.php)$ $1 [L]
RewriteRule . index.php [L]

The issue is that the prompt for the username and password that should happen automagically cannot occur due to the rewrite rules.

The rewrite rules are to look for a valid directory or file and if it is not a valid directory or file then redirect to the index.php which is what happens as the htpasswd AuthConfig process is not a valid file or directory (apparently – umm, so what is it? like is there another rewrite rule that would avoid this? obscure Apache voodoo)

The fix is to create a valid file as an ErrorDocument directive for a 401 or 403 error (Authorisation errors) and have this at the top of the .htaccess file so that Apache will return a valid file flag and therefore allow the AuthConfig prompt to occur.

Edit your top level .htaccess above the section for #Rewrite for WordPress

ErrorDocument 401 /myerror.html
ErrorDocument 403 /myerror.html

if you dont want to put this dummy file in your site root then add the path to the filename

ErrorDocument 401 /[path_to_file]/myerror.html
ErrorDocument 403 /[path_to_file]/myerror.html

Then just create an empty file with that name in the appropriate path.

The references that I used were:
http://www.scratch99.com/2008/10/password-protecting-the-wp-admin-folder/
Which is where I finally found a decent reference that was related to the issue and that blog referenced this one,

http://developedtraffic.com/2007/05/27/wordpress-admin-password-protection-404/
Which pointed me at TextPattern http://textpattern.com/faq/173/password-protected-directories-with-htaccess

and for good measure, this site helped to complete my understanding of why this process works.
http://www.ju-ju.com/2006/03/17/wordpress-404-error

Thanks to the authors of each of those sites.

Ok, so I was hacked. I am paying more attention now!

My WordPress is the latest update, I’ve done some permissions changes, some new passwords, and it is working. Next up is to check the available security options that should save me time.

This Hardening WordPress codex page at WordPress is a good start.

The first is Secure WordPress. Install this to address some of the simple things. I suggest ticking all the options and checking that it does not interfere with anything. Uncheck the options only if something breaks.

The second one is WordPress Security Scan.  This one checks a lot of settings and options that are addressed by the above and will give a confirmation that it’s working.

With the scanner I found that my hosted server did not have permissions to alter the table prefixes which is recommended. For an existing site this can be daunting but its not really. You will find good support at the authors site Semper Fi Web Design. There is a WordPress forum post on this topic that covers the main process for doing this manually.

There is another issue that one of the recommendations is that you should change the admin user account name to something a bit more random. This will break WP 3.1 Network Admin (the new version of MU). This may have changed check the forums post on this topic.

I also configured .htaccess for my admin directory but that created 404 errors on my MU / Network site. Since first writing this I have spent some time on why .htaccess did not work. It works now and the details can be read in a post on WordPress Admin pages and htaccess password protection.

As a result of this I found that I could use the AskApache plug-in (v4.6). The install was easy enough and I recommend it for single site WP installs. It breaks in MU or Network configuration due to the rewrite rules. Now I have to admit I have also reviewed the AskApache admin area since my ordeal of sorting this out and the author does make mention of the 404 error issue, unfortunately it is inside the admin panels which are inaccessible when the error occurs. The author also suggests checking his blog but there is no link, so I am a little vague as to where to contact or report issues. One other issue with the plug-in is that it breaks the css in FF. IE seems ok? But it is a minor issue.

There are other plug-ins but the 3 mentioned here should be sufficient to bolt it down pretty well.

Wow!  It’s been a week of WordPress hacking MySQL backups and google trawling.

Late last week I was working on oscMax and getting along quite well when I went to write a blog entry and discovered that my blog pages had been converted to some islamic protest site.

Now just to make one point clear I am indifferent to religion, whatever works for you is fine, just dont try to force me to follow you because you must be right!

That said, this entry is about the crippling effect of a hack and links to what I read and used to rectify it.

Things I did wrong:

1. WordPress was out of date an older 2.8.6 mu install (multi user because at one time I was going to host other blogs, but that has not happened)
2. MySQL backup had been failing for some weeks after I did a password change (I knew what it was but let it go as a minor concern that I would get to, eventually)

Things I had done right:

1. The area of the site that could be accessed was a sub-directory and the uploaded rubbish was contained within one directory
2. I have rsync backups of the application directory running on a schedule

So I firstly closed up the site, renamed the compromised directory and contacted my ISP support to check logs. Their logs rotate to quickly and one of the security team was over-zealous and ‘helpfully’ removed all the files that were compromised….  without noting the date/time stamps on the files for me to be sure of when the hack occurred. I had noted that the files I saw were consistent with only being in place within the previous 24 hours but as he did not keep a list I dont know what else(if any) he found and deleted.

I’ll write up some separate blogs on the various topics I encountered on this week long journey elsewhere, for the moment these are the references that I have used this week that I found helpful. Most from WordPress codex:

Have a read of this first (dont do anything, read & think first): WordPress FAQ My Site Was Hacked

Download the latest version of WP from WordPress Download

For multi-user equivalent do this after installing WP: Create A Network

When it does not work: Debugging a WordPress Network

Noting that I updated this section with one of my issues: Debugging a WordPress Network « Other Lesser Known Issues

Have a read through this for ideas: Hardening WordPress « WordPress Codex

There are others that I am still reviewing, in particular the security oriented plug-ins, filter for the WordPress category for my latest posts on this topic.

My site is still not working the way I want and I found that the latest version for MU (or Network as it is now called) is apparently very dependent on Apache or other server settings. On SME Server it will not work (yet) while on my hosted site it works first time. Lost around 3 days on that issue alone.

Trying to reinstate the WordPress 2.8.6 mu from the WordPress Archives fails because the mu archive is the same as the WP archive. I’ve manually extracted the database tables/entries that I needed.

And of course I have changed lots of passwords and done lots of chmod’ing to tighten up the access.