Security

How to increase the security of your WordPress Blog?

April 16, 2013 srijit

Today I’m going to show you some simple (and some complex) ways to bulletproof your wordpress installations. Follow the instructions carefully to make your wordpress installation more safe and secure. The Problems and Solutions are listed step by step below.

Instructions

Problem:

Check if full WordPress version info is revealed in page’s meta data.

Solution:

You should be proud that your site is powered by WordPress and there’s no need to hide that information. However disclosing the full WP version info in the default location (page header meta) is not wise. People with bad intentions can easily use Google to find site’s that use a specific version of WordPress and target them with 0-day exploits.

Place the following code in your theme’s functions.php file in order to remove the header meta version info:
```
function remove_version() {
return '';
}
add_filter('the_generator', 'remove_version');
```
Problem:

Check if WordPress readme.html file is accessible via HTTP on the default location.

Solution:

As mentioned in the previous test – you should be proud that your site is powered by WordPress but also hide the exact version you’re using. readme.html contains WP version info and if left on the default location (WP root) attackers can easily find out your WP version.

This is a very easy problem to solve. Rename the file to something more unique like “readme-876.html”; delete it; move it to another location or chmod it so that it’s not accessible via HTTP.
Problem:

Check if server response headers contain detailed PHP version info.

Solution:

As with the WordPress version it’s not wise to disclose the exact PHP version you’re using because it makes the job of attacking your site much easier. This issue is not directly WP related but it definitely affects your site.

You’ll most probably have to ask your hosting company to configure the HTTP server not to show PHP version info but you can also try adding these directives to the .htacces file:
```
&lt;IfModule mod_headers.c&gt;
 Header unset X-Powered-By
 Header unset Server
&lt;/IfModule&gt;
```
Problem:

Check if expose_php PHP directive is turned off.

Solution:

It’s not wise to disclose the exact PHP version you’re using because it makes the job of attacking your site much easier.

If you have access to php.ini file locate
```
expose_php = on
```
and change it to:
```
expose_php = off
```
Problem:

Check if user with username “admin” exists.

Solution:

If someone tries to guess your username and password or tries a brute-force attack they’ll most probably start with username “admin”. This is the default username used by too many sites and should be removed.

Create a new user and assign him the “administrator” role. Try not to use usernames like: “root”, “god”, “null” or similar ones. Once you have the new user created delete the “admin” one and assign all post/pages he may have created to the new user.
Problem:

Check users password strength with a brute-force attack.

Solution:

By using a dictionary of 600 most commonly used passwords Security Ninja does a brute-force attach on your site’s user accounts. Any accounts that fail this test pose a serious security issue for the site because they are using passwords like “12345”, “qwerty” or “god” which anyone can guess within minutes. Alert those users or change their passwords immediately.

Please note that Security Ninja (by default) tests only the first 25 users (starting from administrators). This limit is imposed to be sure we don’t kill the DB while doing the brute-force attack.
If you want to test more or all users open securit-ninja.php and change the line #20 which defines this limit.
```
// maximum number of user accounts that are brute-force tested for weak passwords
define('WF_SN_MAX_USERS_ATTACK', 25);
```
Problem:

Check if “anyone can register” option is enabled.

Solution:

Unless you’re running some kind of community based site this option needs to be disabled. Although it only provides the attacker limited access to your backend it’s enough to start exploiting other security issues.

Go to Options – General and uncheck the “Membership – anyone can register” checkbox.
Problem:

Check if register_globals PHP directive is turned off.

Solution:

This is one of the biggest security issues you can have on your site! If your hosting company has this this directive enabled by default switch to another company immediately! PHP manual has more info why this is so dangerous.

If you have access to php.ini file locate
```
register_globals = on
```
and change it to:
```
register_globals = off
```
Alternatively open .htaccess and put this directive into it:
```
php_flag register_globals off
```
If you’re still unable to disable register_globals contact a security professional immediately!
Problem:

Check for display of unnecessary information on failed login attempts.

Solution:

By default on failed login attempts WordPress will tell you whether username or password is wrong. An attacker can use that to find out which usernames are active on your system and then use brute-force methods to hack the password.

Solution to this problem is simple. Whether user enters wrong username or wrong password we always tell him “wrong username or password” so that he doesn’t know which of two is wrong. Open your theme’s functions.php file and copy/paste the following code:
```
function wrong_login() {
 return 'Wrong username or password.';
}
add_filter('login_errors', 'wrong_login');
```
Problem:

Check if database table prefix is the default one (wp_).

Solution:

Knowing the names of your database tables can help an attacker dump the table’s data and get to sensitive information like password hashes. Since WP table names are predefined the only way you can change table names is by using a unique prefix. One that’s different from “wp_” or any similar variation such as “wordpress_”.

If you’re doing a fresh installation defining a unique table prefix is easy. Open wp-config.php and go to line #61 where the table prefix is defined. Enter something unique like “frog99_” and install WP.

If you already have WP site running and want to change the table prefix things are a bit more complicated and you should only do the change if you’re comfortable doing some changes to your DB data via phpMyAdmin or a similar GUI. Detailed 6-step instruction can be found on Tdot blog. Remember – always backup your files and database before making any changes to the database!

How to increase the security of your WordPress Blog?

Instructions

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution:

Problem:

Solution: