Secure WordPress

A CMS is only as secure as its weakest link. This article provides a best practice for securing WordPress. It does not claim to be exhaustive. It is intended for our customers to raise awareness of the security issues with WordPress.

WordPress is a multifunctional content management system that offers web designers a vast array of possibilities. Because getting started with WordPress is so easy, and because WordPress is sometimes pre-installed, it has a very high market share. Its widespread use, along with many WordPress systems that are not professionally secured, makes it an attractive target for hackers.

Topics

Update WordPress
Secure Hosting
Configure Web Server
Set File System Permissions
Secure the Database
Use Secure Passwords
SSL Encryption
Salts
Directory Browsing
Prevent Access to Backend Login via Password Protection
Rename the WordPress Backend Login

Update WordPress

WordPress regularly receives updates for the core and installed extensions. Minor versions are updated automatically. It’s a good idea to check if the latest version is installed. In the past, there have been issues with the update process. For example, an update to the minor version WordPress 4.9.3 was automatically applied, which had a bug that prevented further automatic updates.
Trust is good, but control is better!

Themes and Plugins

Third-party themes and plugins should be updated.
Always exercise special caution when using third-party extensions.

Prevent Direct Access to wp-config.php

The web server can be configured to categorically block access to the wp-config.php file.

<files wp-config.php>
order allow,deny
deny from all
</files>

User Rights

The wp-config.php file contains, among other things, the database credentials. It is advisable to adjust the user rights for wp-config.php.
After WordPress installation, the wp-config.php typically has default user rights of 644. This is generally sufficient, but certainly not as secure as possible.

cd ~/www/<dir>
chmod 400 wp-config.php

Salts

By default, WordPress supports the use of unique strings (salts).
Salts are stored in the database by default. The wp-config.php is prepared to store individually generated salts.

define('AUTH_KEY',         'put your unique phrase here');
define('SECURE_AUTH_KEY',  'put your unique phrase here');
define('LOGGED_IN_KEY',    'put your unique phrase here');
define('NONCE_KEY',        'put your unique phrase here');
define('AUTH_SALT',        'put your unique phrase here');
define('SECURE_AUTH_SALT', 'put your unique phrase here');
define('LOGGED_IN_SALT',   'put your unique phrase here');
define('NONCE_SALT',       'put your unique phrase here');

Mark Jaquith states (in essence) that while the reasons for setting salts in the wp-config.php may not be obvious, this step is quite sensible. He justifies his statement with a risk splitting. If an attacker gains read access to the database, they can’t authenticate successfully based solely on the passwords stored there, because salts are needed, which are no longer present in the database. In order to create a login cookie, both database access and additional filesystem access are required, making a hack much harder.

Mark Jaquith uses a metaphor for this:

If your house had two deadbolt locks on the front door, you wouldn’t keep both keys under the same rock. (Comment by Mark Jaquith on vaultpress.com, 24.03.17)

Generate new salts

Which files and directories are particularly critical regarding user rights?

These are, of course, configuration files that contain hashes and passwords, such as the wp-config.php file or the upload/ directory.

Security Plugins

Check the ratings and number of installations before installing a plugin. A bad plugin can simply make things worse.

When installing a plugin, make sure to check how many active installations exist and how actively the plugin is maintained by the developer, which can be seen in the changelogs and the WordPress compatibility for the current version.

With the free plugin “Login Lockdown,” you can prevent the intruder from entering the password multiple times.
The intruder will be locked after a set number of attempts.

The WordPress login area can be protected by directory protection.

Directory Browsing

Directory browsing allows the display of files in a web directory if no index page is present. This function is often already disabled. It doesn’t hurt to check this.

The login area can be rewritten via a redirect. Access to the previous directory wp-admin/ will result in an HTTP 404 error page. Plugins are also available for this.

Preventing Executability in the Uploads Directory

If an intruder manages to access the uploads/ directory, they could use any uploaded code, such as a php file, to access other areas. The following code prevents the (Apache) web server from executing .php files in the uploads/ directory.

<FilesMatch "\.(php|phtml|php3|php4|php5|pl|py|jsp|asp|html|htm|shtml|sh|cgi|suspected)$">
    deny from all
</FilesMatch>

Secure WordPress