Build A Better Blog Host Week 5 – Security

One thing you really need to do when running a blog platform of your own is to secure the site. Not just the software you use, but the server as well.

There have been many tips about securing WordPress. In fact, the same twelve tips seem to be making the rounds. While they are good tips in general, in the case of WordPressMU some are not applicable (blocking admin area by IP for instance), and a couple can actually lock you out of your own site. Like removing the admin user.

To start, let’s tackle one of the more common reasons for security breaches.

Passwords

Choosing a decent selection of passwords is really vital. Notice I said a selection. You have one password as the admin user. You also have a database password, an ftp password to your web account, and possibly another password to get into the server itself. These should all be drastically different passwords.

A few years ago, one of my own sites got hacked. The hacker was thankfully a nice person, and just left an index.html file on the server to let me know I’d been breached. How’d he do it? He managed to download or read my wp-config file (even though it had the right permissions) and get the database user password… which was the same as the cpanel password.

Oops. That was dumb.

I have read a tip on passwords recently where they stated that if you could remember your password it wasn’t a good one. I have a weird memory; I can remember things like my medicare number, my SIN, and the last 6 phone numbers I’ve had. A few reasonably decent passwords I use have enough of a meaningful pattern to me that I can remember them.

Here is an example of creating a password that is easy to remember but difficult to guess:

• Ronald & Roland are the same name except the l & n are transposed
• Rol/nald add in the either/or of the l/n
• Rol/nal<nd add the second either/or by logically comparing the 2 letters
• R0l/nal<nd substitute a ’0′ for an ‘o’
• R0l/n+l<nd substitute a ‘+’ (add) for an ‘a’

By doing something like this you don’t necessarily need to be able to remember the password. As long as you can remember the process you followed to create the password you can recreate it any time you need to. (We don’t use that one anywhere, it’s just an example.)

Securing WPMU

• Instead of renaming the admin user (which is one of the WP security tips), create a second user account for you to use on a day to day basis and add it to the site admin list. That way, you can make the admin user’s password as difficult/unrecognizable as you want.
• Ensure that the files in your site are not left with a protection of 777. 755 is the recommended protection. This permits only the owner to have write access to the files and folders.
• Follow the recommendations for themes and plugins below.

Securing the Server

If you are on a shared host there isn’t much you can do here. If you have a VPS or dedicated server, a few things you should do are

• disallow remote root login. This way root can only log in from within a logged in account. Someone trying to break into your server now has to guess a username and 2 passwords to gain superuser access to your server.
• change the SSH port to a number greater that 1500 and less than 65535. By default SSH runs on TCP port 22. Changing the port makes one more thing that a would be intruder has to guess. You could also rotate your port once a month or so.
• run a firewall (ex. iptables) utility on the server.
• run a BFD (brute force detection) utility on your server.
• avoid using FTP unless you absolutely have to. Use SFTP instead.

Themes

• Before putting a theme on your live site search the template files for ‘base64′, ‘bzip’ & ‘gzip’. If it has any of those it may have some freeloading extra code in it. Most themes we’ve found code buried in, it’s been in the footer.
• Also, check a theme’s template/function files for $wpdb. Unless the theme has custom coding that you have asked someone to write for you, a theme should not use $wpdb.
• Once you have checked the files, thoroughly test themes on a test blog before enabling themes for user blogs.

Plugins

For site admin plugins that have a user interface you should be able to find a check for is_site_admin. Similarly, plugins with a user interface should have the following checks:

• the plugin file blocks being called directly –
  if(!defined('ABSPATH')) {
die("Don't call this file directly.");
}

• appropriate user level –
  if(!current_user_can('import')) {
die( 'You don\'t have permissions to use this page.' );
}

• string variables coming from $_GET, $_REQUEST or $_POST should be processed to prevent SQL injection –
  $post_type = isset($_GET['post_type']) ? wp_specialchars($_GET['post_type']) : 'all';
$status = isset($_GET['status']) ? wp_specialchars($_GET['status']) : 'all';


The above security examples came from my advanced export plugin. You can look at it if you want to see the context of where the blocks were used.

And finally, the best way to keep up with security, is to follow the issues on trac. I also keep tabs on a couple of security related blogs, like Blog Security, for general notices.

Tweet This Post