Here are some relatively simple steps that should help ‘toughen up’ your WordPress installation:

Don’t use the “admin” account.

Either change the username via MySQL

UPDATE wp_users SET user_login = 'username' WHERE user_login = 'admin'

*where “username” is whatever you want to call it.

Or, create a new/unique account with administrator privileges and delete the original admin account.

From WordPress 3.0 you can set the administrator username and password during the installation process, which is a good step forward.

Use secure passwords.

Use strong passwords to protect your website from dictionary attacks. WordPress will tell you when your password is strong (the admin interface for users has a password strength indicator).

Don’t restrict your strong passwords to the WordPress installation, do the same for FTP, SSH and MySQL as well.

Update the folder permissions on your WordPress files.

A good rule of thumb is to set the following permissions:

Files should be set to 644
Folders should be set to 755

If these settings are too restrictive, i.e. you can’t upload files, change the permissions to increase the privileges (e.g. 775 or even 777).

Remember, permission levels vary depending on your specific server configuration, but you can generally set them to the desired level quite easily via FTP or SSH clients.

For example, with SSH:

find [your path] -type f -exec chmod 644 {} \;
find [your path] -type d -exec chmod 755 {} \;

Move the configuration file (wp-config.php).

From WordPress 2.6 it became possible to move the configuration file up a directory and out of the WordPress root folder.

For example, if WordPress is located in the following directory:

public_html/wordpress/wp-config.php

You can move it to the following directory:

public_html/wp-config.php

WordPress automatically checks the parent directory if the configuration file is not found in your website’s root directory.

This makes it nearly impossible for anyone to access your configuration file as it now resides outside the website’s root directory.

Move the wp-content directory.

Like the configuration file, WordPress 2.6 added the ability to move the wp-content directory to another location.

Once moved, make two additions to the configuration file to identify the new location:

define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content');
define('WP_CONTENT_URL','http://domain.com/blog/wp-content');

You may also need to define the new location for plugins:

define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/blog/wp-content/plugins');
define('WP_PLUGIN_URL','http://domain.com/blog/wp-content/plugins');

If hackers can’t find your wp-content folder’s location, clearly it becomes far more difficult for them to hack it.

Stay current with all updates.

The main WordPress installation files, plugins and themes can be updated easily via the admin interface. Make sure you do so each time a new version of either are released.

For plugins, the plugin change log makes it easy to see what has changed and therefore ensure compatibility with your version of WordPress.

Remove the WordPress version information from your header.

Viewing source on most WordPress websites will reveal what version of WordPress the website is running.

<meta name="generator" content="WordPress 3.0.1" /><!-- leave this for stats -->

This helps hackers find vulnerable blogs or determine ways to hack a particular version.

To remove, find the code shown below in your header.php file and delete it:

<meta name="generator" content="WordPress <?php bloginfo('version'); ?>" /><!-- leave this for stats -->

The wp_head function also includes the WordPress version in your header. To remove, include the following line of code in your theme’s functions.php file:

remove_action('wp_head','wp_generator');

Use secret keys.

A secret key is a hashing salt, which makes your website harder to hack by adding random elements to the password. These secret keys are found in the WordPress configuration (wp-config.php) file.

Visit the following URL to get the secret keys: https://api.wordpress.org/secret-key/1.1/salt/

Replace the following in the configuration file

define('AUTH_KEY','put your unique phrase here');
define('SECURE_AUTH_KEY','put your unique phrase here');
define('LOGGED_IN_KEY','put your unique phrase here');
define('NONCE_KEY','put your unique phrase here');
define('AUTH_SALT','put your unique phrase here');
define('SECURE_AUTH_SALT','put your unique phrase here');
define('LOGGED_IN_SALT','put your unique phrase here');
define('NONCE_SALT','put your unique phrase here');

With the generated keys (example only):

define('AUTH_KEY','*QCT0a,T+3hxeg)ti7k}#~<AQSmm&x+ff=*$d:)<-;+!a?yS{ArmuR-#*GyLCgI)');
define('SECURE_AUTH_KEY','[)|y._i~B5js,h3@4%M[<l:DJ&]Ou$2|n(e?DJ`+R4pk6um/6zS%6@@i{^N-6(4]');
define('LOGGED_IN_KEY','@+l2X{3wvy/1K[zRm|P_r;WixJ:,>V&JL![gyJq ?b[Wf.W|U_MKutdrL*$l][-S');
define('NONCE_KEY','T$R>#*2)2kO?NIr&o|>[L>T5%YGd^yJ+eE$7wkcL-?1v]-X*{f`Pg)NZqKU}^e8R');
define('AUTH_SALT','<8JD%+O!t.F%]6RaO9L_MI<w2Lw_-Bc5u_(WDdPoO0D;j9zwu*?1i{%nH/RBjF6J');
define('SECURE_AUTH_SALT','oS|EP&Pm`bf8iG!C<X8#yFG%8J)x G+3M`wRBtp#]7)&hj}ZV/p> yh-BtbBRbTk');
define('LOGGED_IN_SALT','tW4|J/m|habEJ+BTvF0PfpuiOgf-6,dIav-5K|FTM$&Agy;FqDjp|5Ci7>nJFD/#');
define('NONCE_SALT','T-v&f++w!c%5zs2t8qH?,n,/WE&uWd--o4t{FL49/4e~|e+HV+.~A?JYZ1Ev<5)u');

You can add or amend the secret keys at anytime. This will invalidate all existing cookies and require users to login again.

Change the WordPress table prefix.

You can define the WordPress database table prefix in the WordPress configuration file. By default, the prefix is set to:

$table_prefix = 'wp_';

Change this to whatever you prefer.

If you already have a version of WordPress installed, you will need to manually amend the database table names in MySQL, or do a clean install and data import.

Force SSL on login and admin access.

Set the following option in the WordPress configuration file to force SSL (HTTPS) on the login and admin screens.

define('FORCE_SSL_LOGIN',true);
define('FORCE_SSL_ADMIN',true);

Use IP lockdown on the wp-admin directory.

Create an .htaccess file in your wp-admin directory with the following lines of code:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
order deny, allow
deny from all
#IP whitelist
allow from 72.14.207.99
allow from 216.239.51.99

Where the IP address lines are whatever your chosen IP addresses are. Only users with these IP addresses will have access to the wp-admin folder and hence the admin part of the blog.

Resources:

• http://codex.wordpress.org/Hardening_WordPress
• http://codex.wordpress.org/Changing_File_Permissions
• http://codex.wordpress.org/Editing_wp-config.php
• http://codex.wordpress.org/htaccess_for_subdirectories

If you have any more suggestions, that don’t necessitate plugins, feel free to comment.

1. Download the Mac OSX disk image from the MySQL website:

   http://dev.mysql.com/downloads/mysql/5.1.html#macosx-dmg

   I used the mysql-5.1.42-osx10.5-x86_64.dmg disk image, which seems to work fine. The image contains 4 files including a ReadMe file.

2. Install the following packages found in the disk image to the default location and with the default options:

   mysql-5.1.42-osx10.5-x86_64.pkg
   MySQLStartupItem.pkg

3. Install the following profile found in the disk image to the default location and with the default options:

   MySQL.prefPanel

4. Start the MySQL service in the System Preferences panel and check the Automatically Start the MySQL Service on Startup option.

That is all you need to do. However, if you’re working with PHP, you will need to correctly reference the mysql.sock file in your php.ini file. To do this, find the following line and ensure the reference is correct:

mysql.default_socket = /tmp/mysql.sock

(Remember to restart Apache if you make changes to your php.ini file.)

The task I was trying to achieve was the installation of development versions of WordPress, Drupal, MediaWiki and Moodle, all of which would require a MySQL database. Trying to load the MySQL extension should have been a simple case of uncommenting the line in the php.ini and restarting the Apache service. With Vista, this was certainly not the case.

I set up a very simple page detailing the php configuration in an index.php file:

< ?php phpinfo(); ?>

This showed me the default configuration path of my php.ini and extensions directory, amongst a whole host of other information.

In both cases the paths were incorrect. First and foremost the configuration file path stated C:\Windows when in fact I had installed it in the root (C:\PHP5). So, although I was amending the php.ini file with the correct detail, Vista was using the default values. If there is no php.ini file in Windows, then you’ll continue banging your head against a brick wall.

The problems didn’t stop there. Moving the php.ini file to the Windows directory under Vista isn’t a simple copy and paste task. You need to be administrator. But Vista’s administrator priviledges are more pseudo than actual! In order to amend and save the php.ini file in the Windows directory, you must run Notepad as administrator and save the file as such. Voila! Everything then works. The phpinfo() function returned the correct installation detail and I could continue with the job I was meant to be doing.

PS. Thanks to Rob Douglas for his help.