Blog |Follow Nick on Twitter| About

I've been following the activity over at blogsecurity, their activities are very interesting and quite commendable. After some shameless delay I decided to read though their WP Security White Paper and apply some of the steps... yes I did say some, harden security folk will insist that you should follow all of the whitepaper to be security, which is probably true, but one should never forget that security is about risk... and in basic terms accessibility vs security, for example I won't ever lock my wp-admin down to a single IP as I've been know to blog at work, home, around my parents place and even moderate comments on the train! Thus my wp-admin isn't as secure as someone who did lock it down, but this is a risk I'm willing to live with.

One of the area's that I did like was the tightening up of wp-includes & wp-content, but before you jump in and copy/paste what's in the pdf into .htaccess, you should be prepared for some work. Basically

Order Allow,Deny Deny from all <Files ~ ".(css|jpe?g|png|gif|js)$"> Allow from all </Files>

when applied stops any file except .css,.jpeg/jpg, .png, .gif & .js from being accessible; now this is great for stopping zero-day remote file includes from php files but it will mean that any php file (even those you may want access to) will be restricted. What I've decided to do below is document what changes you need to make to the recommendation to get some popular plugins to work.... This approach will also have a long term impact on the "hardening plug-in" that the blogsecurity team are planning; basically the issue is - the default recommended .htaccess will break plugins, the number of plugins avilable for a wordpress install is unlimited thus they will need to provide a community driven configuration repository that the plugin can draw upon to open things up for specific plugins.

For the purpose of this documentation, I'm going to assume wordpress is installed in /var/www/html so please change appropriately.

For those who use the rich editor and need the spell checker, you'll need to add this to your /var/www/html/wp-includes/js/tinymce/plugins/spellchecker/.htaccess

# Open up the spellchecker <Files "tinyspell.php"> Allow from all </Files>

To get the popular WP-Cache plugin to work changes are made to:/var/www/html/wp-content/.htaccess

Order Allow,Deny Deny from all <Files ~ ".(css|jpe?g|png|gif|js|html)$"> Allow from all </Files>
This will allow the static html files in the cache to be downloaded, now I didn't get to the bottom of this, but I believe that the wp-cahe php files might be called directly, so if you are having problems see if this resolves it...
<Files ~ "wp-cache"> Allow from all </Files>
This will open up the wp-cache files as if you hadn't installed the .htaccess in the 1st place - you have been warned, now you evaluate the risk :)

If you are using the google site map generator, then you can create a .htaccess file in/var/www/html/wp-content/plugins/google-sitemap-generator to allow the xml style sheet through:
<Files "sitemap.xsl"> Allow from all </Files>

The final one that might interest people is Share This, you'll need at .htaccess in /var/www/html/wp-content/plugins/share-this with:
<Files "share-this.php"> Allow from all </Files>

As you might have gathered this does involve creating a lot of .htaccess files, which is a bit of a pain, if you're fortunate enough to run your own web server and have access to your httpd.conf you can actually keep these all in one file, keeping with the last share this example, instead of creating a .htaccess in /var/www/html/wp-content/plugins/share-this you can edit your httpd.conf and just wrap the code in <Directory>, so you could actually paste this:
<Directory "/var/www/html/wp-content/plugins/share-this/">

<Files "share-this.php"> Allow from all </Files> </Directory>
I hope this all makes sense, and is of some use to someone...good luck to the blogsecurity team, if you need any help feel free to shout ;)



Nick Bettison ©