Small Security Tipps for your WordPress Install

WordPress enjoys great popularity and draw more attention of people who want to gain unauthorized access. As with any open-source software developers and attackers alike can view the code. The risk of spam links, the destruction of the blog and other attacks is therefore very high. But this article shows the possibilities to secure WordPress in many ways.

There are many ways to secure a WordPress installation. In this article we will show only those who are easy to implement with little effort in WordPress. Which possibilities you use always depends on the different options available. For example, if you have access to the server’s configuration, you can already create a high level of security. Here it is only about security settings within WordPress.

Install WordPress securely

WordPress is known for its simple and uncomplicated installation. This fact has contributed in particular to the popularity of the software, but also ensures that many settings are equally on many installations. This allows hackers to set up at various initial positions and gain unauthorized access.

Already during the installation of WordPress, you should pay attention that your own blog has less in common with a default installation of WordPress. An installation that differs from the standard, makes it more difficult for potential intruders to unauthorized access. In this context, you should consider a few points when setting up a new installation of WordPress.

All tips are limited to the possibilities of the basic installation without extensions. However, there are also some useful Plugins for more security in WordPress, which are particularly for less experienced users an alternative.

Table prefix

Access to the database is configured in wp-config.php. In this file, the table prefix is defined which uses WordPress to create the database at installation. By default, this is the prefix “wp_”. You should always configure a random prefix that does not meet the standard. You should also make sure that you are using only numbers, letters and underscore, because other characters are not supported.

Authentication Unique Keys

Also in wp-config.php, you have the ability to define four security keys to increase the safety of WordPress. The keys either created manually or via a generator at wordpress.org. The four keys are assigned to different cookies and are used at different places in order to increase the security of WordPress, so it is also important that every installation has different keys. The relevant keys are:

• AUTH_KEY Is used for unsecure connections via http.
• SECURE_AUTH_KEY This constant can be realized through https secure..
• LOGGED_IN_KEY holds firmly to whether a user has logged in, not an administrative cookie.
• NONCE_KEY appaers at $_POST-queries of WordPress and can be used via extension with function wp_nonce().

If you update an existing installation of WordPress, the key should be supplemented here by the example of AUTH_KEY:

define('AUTH_KEY', 'put your unique phrase here');

File and Folder Permissions

Distinguish the rights of files and directories properly. Restricted Rights make it difficult for an attacker to alter files and directories.

Search engines usually take up to a certain depth, which they can get. Prevent using the robots.txt file to have access. The internal directory of WordPress shouldn’t appear in any search results – a simple Disallow is enough.

Depending on server configuration, the possibility exists that you can list the contents of the folder in the browser. This must be prevented, which is quickly done by passing an empty index.html in each directory. Alternatively this can be done with the help of Secure WordPress Plugins.

Rename wp-content

All extensions, files and themes are stored in the default installation folder wp-content. Often, themes or Plugins opens a security hole in the system, so it is possible since version 2.6, to enter an arbitrary name for that folder, and storing the folder elsewhere. With a new installation it can be done easy and fast. It can lead to problems with Plugins or themes, since not all authors check this path by using the available constants and functions. Therefore, this option is only recommended for experienced users.

To redefine the folder, it is sufficient to establish that with the help of the constants in the wp-config.php.

define('WP_CONTENT_DIR', ABSPATH . 'test');    // wp-content Directory
define('WP_CONTENT_URL', 'http://example.com/test');    // wp-content URL

Secure access

With version 2.6, a new option has been added to secure the back end of the installation: access via SSL – Secure Sockets Layer is an encryption protocol for transmitting data. Your internet provider must support the use of SSL. If so, you can enable the protocol in wp-config.php . To use the SSL capabilities in the backend, you must define FORCE_SSL_LOGIN with TRUE, not in quotes, it is a boolean value. From now on, all data is encrypted in the backend.

define ('FORCE_SSL_LOGIN', true);

Safety of existing installations

Also existing blogs can be made safer with a few simple steps. If the blog is already active and the database is already filled with content, changing the table prefix have fatal consequences. Yet there is also the possibility here to change the prefix. These various steps with the help of SQL is required that you perform in the most appropriate interface. Alternatively, you can go down that route with the help of a Plugin. Any changes to the database requires a backup of current database in advance.

To change all ten standard tables, the following SQL statements are necessary. Have you more tables, for example because of Plugins, they must also be changed. Adjust the sample wp_i1d_ to your requirements.

RENAME TABLE wp_comments to wp_i1d_comments;
RENAME TABLE wp_links to wp_i1d_links;
RENAME TABLE wp_options to wp_i1d_options;
RENAME TABLE wp_postmeta to wp_i1d_postmeta;
RENAME TABLE wp_posts to wp_i1d_posts;
RENAME TABLE wp_terms to wp_i1d_terms;
RENAME TABLE wp_term_relationships to wp_i1d_term_relationships;
RENAME TABLE wp_term_taxonomy to i1d_term_taxonomy;
RENAME TABLE wp_usermeta to wp_i1d_usermeta;
RENAME TABLE wp_users to wp_i1d_users;

Unfortunately, WordPress uses the installation prefix, to clearly identify some of the fields in the tables options and usermeta. Therefore, you must rename these fields.

UPDATE wp_i1d_options SET option_name = REPLACE(option_name, 'wp_', 'wp_i1d_');
UPDATE wp_i1d_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'wp_i1d_');

Since Plugins may be able to create fields with the prefix, it is advisable if you now search the database for the old prefix and change the values.

SELECT * FROM wp_i1d_options WHERE option_name LIKE 'wp_%';
SELECT * FROM wp_i1d_usermeta WHERE meta_key LIKE 'wp_%';

Rename Username

The user name of the default installation is admin and not only known to you. After an installation you should delete this user. Be sure to create a new administrator. This is done in the administration area and should be the first act after the initial login.

This will change not only the user name, but also the ID, which is after the initial installation 1. Two fields that makes it easy for an attacker if you don’t change them.

Would you like to set a very large value for the ID, the manual option in the backend is very complicated, because WordPress is adding to each new user only 1. Alternatively, you can change this value via SQL or with the Plugin Search & Replace.

UPDATE `wp_users` SET `ID` = '815' WHERE `wp_users`.`ID` = 1;
UPDATE `wp_usermeta` SET `user_id` = '815' WHERE `wp_usermeta`.`user_id` = 1;
UPDATE `wp_posts` SET `post_author` = '815' WHERE `wp_posts`.`post_author` = 1;
UPDATE `wp_links` SET `link_owner` = '815' WHERE `wp_links`.`link_owner` = 1;

Don’t reveal WordPress version

The version of WordPress is displayed in many parts of the blog, in your backend, feeds and in your theme. Each version has its quirks and errors that potential attackers are known.

For this reason, nobody should receive information about your WordPress installation. The simplest way to remove the version information from all areas (except the back end), is the use of Secure WordPress Plugins. Alternatively, it is sufficient to suppress the function of publishing the release.

add_filter( 'the_generator', create_function('$a', "return null;") );

Disable Error and Information messages

The backend of WordPress can be reached via login with username and password. If the user produces an error, WordPress provides related tips to ease the login. As useful as the information for the user is, so it is also useful for unwanted intruders.

Consider whether you need to allow these messages, or want to, otherwise they can be disabled by the already mentioned Plugin Secure WordPress Plugin.

If the constant WP-DEBUG is defined in your wp-config.php, you need to set it on FALSE or delete, otherwise any error in WordPress will be displayed in your browser. This constant should be used only in the development environment of WordPress.

define('WP_DEBUG', false);

Security via .htaccess

The possibilities with .htaccess are various and we can also secure WordPress sufficiently. Specifically, the different requirements should be considered here, because not infrequently the usability suffers from the security settings. Consider the safety of WordPress also from the perspective of users, not only from the administrator. You should also note the configuration of your web space, so that there will be no errors.

In principle, any directory can be protected, especially the folder wp-admin, because there are the files to get access to your backend stored. Access is controlled via wp-login.php and WordPress always forwards to it, no matter which unauthorized call was placed in wp-admin. It must be added a .htpasswd file, that contains user name and password. Various online generators can help you create the file contents.

# protect wp-login.php

AuthName "Admin-Bereich"
AuthType Basic
AuthUserFile /your_lokal_path/.htpasswd
require valid-user

As already mentioned, the file wp-config.php contains the accesses to the database, which makes them especially worthy of protection. A few lines in .htaccess of the root are helpful.

# protect wp-config.php

Order deny,allow
deny from all

If the server environment allow an open directory environment, it is advisable to either store the main index.html in each directory or block access via “Options Indexes” in the .htaccess.

The folder wp-content and wp-includes are worthy to protect. The following syntax shows a simple method to protect the respective folder.

Order Allow,Deny
Deny from all

Allow from all


Allow from all

The file formats should be adapted and possibly be expanded and tested. Alternatively you can also use a Plugin solution that can greatly improve security and will decrease the work: AskApache Password Protect.

Conclusion

PHP and security have been and are frequently discussed and sometimes makes a web programmer pretty nervous. Security with PHP is not a “secret science”, already with a few basics you can make a WordPress extension safer. Even WordPress itself provides this functionality. WordPress is much used in different configurations and versions of PHP, so that we can discuss the issue on different levels. The featured selections are simple and almost everywhere doable, which should not be ignored, if you want to keep your blog under your control.