I attended the WordCamp Birmingham conference this past weekend to find out more about all things WordPress. WordPress is an open source blog engine/lightweight Content Management System (CMS) that has a huge community of users and developers, and an enormous repository of plugins to extend its functionality.
One of the presentations I attended, Mitch Canter‘s session on WordPress Security, had 6 good tips for making your WordPress-based site more secure:
- Updgrade WordPress
WordPress recently released an important security update. Making sure that you are using the most current version will ensure that you have the latest security patches. (WordPress will complain if you aren’t running the latest, greatest version, so no need to fear: you’ll know.) - Update your plugins
Plugins are 3rd-party code that can have their own security flaws [a good reason, in my opinion, to do a little research before you install any old WordPress plugin you find lying around the internet]. Find out if updates are available for yours. - Set your file permissions
A lot of WordPress users may not be familiar with Unix/Linux file permissions, and once they find out, they may become even more confused, as files permissions use an octal-based numeric scheme to determine who (the owner, the group, or other users) can do what (read, write, execute) with a file.Depending on which user your web server runs as, your files should be set to 0775, which means you (the owner of the files) and the associated group can read, write, and execute the files, but other users can only read and execute the files. With Apache 2, you can use mod_suexec and a SuexecUserGroup command to make the webserver run commands as a specific user and group, which means you should never have to make any of your files or directories world-writable.
[“World-writable” is a misnomer here–it really means “writable by anyone who has access to the server.” That means other legitimate users who may have an account on the same machine, or malicious users who have compromised someone else’s account on the system.]
- Make backups
I was really glad this came up, because security is about much more than preventing malicious attacks. It’s about maintaining your data over time. Mitch suggested the wp-db backup
WordPress plugin. [Although one of the options is to have WordPress send an e-mail with the compressed data, e-mail is not a secure way to transfer data, and I would recommend against it.] - Delete the admin account
Every WordPress install comes with a privileged account, ‘admin’. Automated attacks can be launched against your system attempting to login as this user with a guessed password.Anyone that really wants to hack into your system can do a bit of sleuthing and probably guess your actual login name–but creating a new account with administrative privileges and changing the admin account should at least provide some protection against the most automated attacks.
- Change your WordPress database table prefix.
This setting is contained within the wp-config.php file, and it’s easiest to change it when you are first setting up a new WordPress install. Otherwise, you will need to change not only the config setting, but additionally all the table names in your database. This change will help protect you from automated SQL injection attacks.
Some additional ideas were floated during the questions and comments portion of the session, most of which included plugins, such as:
Other ideas included:
- Restricting access to the files within wp-admin to specific IP addresses (this may not work for most people, who want to update their sites from wherever they happen to be)
- Installing a self-signed SSL certificate and requiring SSL (https instead of http) to log in. This wouldn’t be good solution if you are setting up a site for someone else, as they would get browser warnings unless they permanently accept the self-signed certificate.
I will probably be posting further updates this week with my notes from the WordCamp.