Practical tips for securing your WordPress blog

WordPress is one of the the most commonly used and talked about blogging platforms on the internet. Because of this, it has gained the interest of bloggers, hackers and corporate marketing douche bags who wear too much cologne alike. A simple Google search will yield numerous guides offering WordPress security tips and while there is a lot great information out there, I’ve found that most are either focused on a single topic or contain outdated information. That is why I’ve created this guide serving not only an overview of practical methods for securing modern versions of WordPress but will also a more detailed look at why these procedures are actually relevant and necessary.

Introduction

The WordPress platform is fairly secure “out of the box” but because the deployment script has been simplified for ease of use, many things such as default usernames and paths are predetermined. While this is convenient, it also creates potential for attacks by hackers who can easily find your default administration pages with a basic search on most search engines. You can see for yourself by searching Google with the following query: inurl:wp-admin: site:us . With just this basic example, the admin path to nearly 20,000 blogs is at your fingertips.

While this information alone is not enough to gain access your site, a hacker who has an exploit or a basic script to guess your password can potentially access your blog’s administration area without ever viewing your site. Below I’ve outlined a few of the most essential tips and additionally provided some insight on how to clean WordPress if your site once its been hacked.

Use random names for your Database and tables

Throw in some random numbers or letters; it is going to be a much more difficult attack your site with malicious queries or XSS if the attacker cannot identify your DB name.

I’ve been working in WordPress for several years now and have not noticed significant changes in the table structure. Hackers know this and can write queries on your default wp_posts and wp_comments tables in their sleep. Even if your Database has a strong name, it is a wasted effort if you do not use a unique table prefix. I suggest something completely random and meaningless containing both a number and letter.

Don’t use “WP_” as a table prefix

Throw in some random numbers or letters; it is going to be a much more difficult to use XSS attacks since the hacker will have to work a lot harder to target your DB.

Rename the ‘admin’ user

Having a strong password will certainly reduce the chances of unauthorized access but since hackers know that the default account login is admin , they are already 50% of the way in. Renaming the admin account can be difficult if not impossible to change from WordPress itself, so I recommend doing this directly from the database. Access your users table and simply rename the admin account to something harder to guess. It probably goes without saying but after you change the username, don’t make your Nickname the same as your login.

Server Configuration

Some hackers attempt to access WordPress through the admin interface which allows them full control of the content of your blog but what about the hackers who want to steal your traffic or install a prominent ad for “v1@gr@” on every page of your site?

Many exploits are aimed at the internal WordPress files which can potentially give the hacker complete control of not only your blog content but your entire server. Fortunately, blocking most of these attacks can be done with a few simple .htaccess tricks.

The majority of WP’s “guts” are located in the wp-includes and wp-content folders. I recommend placing an .htaccess similar to the one below in both the wp-includes and wp-content directories. Note:you might need to customize the <files> section depending on your plug-in requirements and WP version.

Order Allow,Deny
Deny from all

 Allow from all


This code will deter XSS attacks on your core PHP files and make it more difficult for hackers who do get into run malicious files that they’ve left in these directories in the future.

Another area in need of some .htaccess fun wp-admin folder. For this folder, we will require server authentication before accessing anything in the admin folder. To do this, create a .htpasswd file and then add create a .htaccess file with the code below (change AuthName and Require user fields as desired):

AuthType Basic
AuthName "Please insert coins to ride the Pony"
AuthUserFile /path/to/your/.htpasswd
Require user barbiegrrrl45453

This type of authentication can be confusing to less technical users, more information can found here and I also recommend checking with your host as I’ve found that many major hosting companies have a “protect a directory” feature in their admin panels.

As a final “sledgehammer” method, .htaccess makes it easy to block geographical areas from accessing your site all together. The basic syntax is show below and should be placed in the .htaccess located in the blog’s root directory (this file already exists so be careful not to remove any of the existing code)

order allow,deny
deny from 000.867.530.9
allow from all

To block a specific country you can refer to the aptly named BlockACountry.com for a list of specific IP addresses. Please note that by doing this, you are, in theory, blocking _EVERYONE_ from the specified country. This method can also increase page load times if the list is too long.

Have you already been hacked?

Issues such as inability to login to your account, mysterious ads and comments and random errors are obvious signs of that something is wrong. But what if your site has been hacked without any visual signs? These types hacks are typically the most frustrating and most difficult to check. The usual signs are HTML comments or hidden / broken code with spam keywords and / or links.

This type of attack is usually done when a hacker gains access to your server and then modifies your WP files to generate the malicious code. It is important to catch these types of attacks as early as possible (and to monitor your files occasionally) because Google’s bots typically can detect the malicious code which will often get you marked as a “Malicious / Spyware” site or in some cases get your site blacklisted altogether .

The specific files targeted vary depending on the purpose of the attack but after dealing with several types of attacks in the past, the most common files are custom JavaScript files linked in the header (usually hacked to show ads or deceive the user by creating invisible links), index.php ( typically injected an eval() statement that generates HTML) and through the .htaccess located in the root directory (typically used to generate traffic to malware / ad sites). These are the first three places that I check when I investigate a hacked site but there is also a good chance that the hacker will leave an innocently named file such as a .jpg or .swf which contains a “an all access pass” to your server.

The other type of attack wherein the hacker gains unauthorized access to your database can usually be resolved much easier. With this type of attack you will be able to tell if anything is out of place with the posts or comments tables since these are published on your site but it is also very important to check the users and options tables for un-authorized users and suspicious entries.

If all else fails, back up your database and files and start with a fresh install and then add your theme files and data in small batches once you deem them clean. There is also a great plugin to check if your code has been hacked.

Common Sense Messures

Regarding user accounts, I suggest using this feature with caution. At very least, accounts should require administrator approval. For those who are paranoid, you can always rename or remove the wp-register.php file (after you set up all of your accounts) so that no additional accounts can be created.

One of the easiest things you can do is make sure that the version if WordPress your site is running is the most current. It can be tedious but it is the most effective and easiest way to protect your site. <soapbox>While I am a fan of WordPress, I am usually wary of choosing it as a CMS solution for my clients because of the potential for vulnerabilities in older versions. I suggest to anyone reading this who uses WordPress as a CMS on client projects to consider the potential issues and plan for (and perform!) routine upgrades accordingly.</soapbox>

My last recommendation is to create a secret key in your wp-config.php. The secret key is a hashing salt which makes it more difficult for a hacker running a password hacking script to gain unauthorized access. WordPress has a secret key generator which I highly recommend using for this operation. Below is a SAMPLE key, please make sure to change it if you use it on your blog! Note: the exact implementation of these keys depends on your WordPress version. Since you’ve read this far down, I assume you have already upgraded or will be shortly, but visit the entry in WordPress’ Codex for more information.

define('AUTH_KEY', ':dr+%/5V4sAUG-gg%aS*v;&xGhd%{YKC^Z7KKGh j>k[.Nf$y7iGKdJ3c*[Kr5Bg');
define('SECURE_AUTH_KEY', 'TufWOuA _.t>#+hA?^|3RfGTm>@*+S=8"'+"}]<2V^$T])=8Xh2a:b:}U_E');
define('NONCE_KEY', 'k1+EOc-&w?hG8j84>6L9v"6C89NH?ui{*3\(t09mumL/fFP_!K$JCEkLuy ={x{0');

If you have any questions, suggestions or corrections feel free to add them in the comments.

3 comments on “Practical tips for securing your WordPress blog

  1. I found your blog on google and read a few of your other posts. I just added you to my Google News Reader. Keep up the good work Look forward to reading more from you in the future.

  2. Yeah, there are some great plugins worth taking a look at too (maybe a future post?):

    Login LockDown – Limit login attempts
    WP-Ban – Ban naughty commenters/spammers
    WP-DBManager – Automatic Database backups emailed to you daily
    WP S3 Backups – Entire website backed up automatically everyday on my Amazon S3 Account… just in case

    • all those plugins are handy, but it is wise to use them and more.

      After using WP Ban for a while it is an easier option than updating the htaccess file myself on the road.

      I only use it to keep the spam to a minimum, and I have to manually approve comments otherwise I would have hundreds of spam comments a day!

      Doing a spring clean after every install of a new updated version of wordpress is the only way to go, as some of the security fixes you do can be recreated by the installation of the latest version of the system.