I think it makes sense that the very first post on my brand new WordPress blog would be about hardening WordPress itself. This makes even more sense if you consider it took me more time to harden this blog than to write this post.
For the installation just follow the official documentation found here to which I just want to make one remark about the database password strength:
GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername"@"hostname" IDENTIFIED BY "password";
Use a long password here, something like sK8ytB8mR5PtxqqTmCEYThEUJS5J6D which is 30 chars long. You won’t need to type this password often so there is no need to use a memorable one.
To be honest, a weak password here wouldn’t be that bad since it is unlikely that you server will fall because of this…unless you expose it beyond 127.0.0.1.
For the hardening, start here. There is some smalltalk but there are also some good advices regarding a few topics:
- updates
- file permissions
- wp-admin
- wp-includes
- security plugins
updates
Keeping your installation up to date is paramount to ensure proper security. Before version 3.7 updates really sucked because the easiest way to (automatically) update was to have all files writable by the webserver process, so basically any malicious code executed by the webserver would be able to overwrite any file from our installation. The alternative was more secure but harder, so people wouldn’t update.
In the latest versions there is some magic that let you have automatic updates without the need to have files writable by the webserver. I think there is more than one way to achieve this: I went for the SSH one.
I followed this tutorial. In addition to the 5 defines added to the wp-config.php file, I also added define('FS_METHOD', 'ssh2');.
Since we are adding a new SSH user and we don’t want to increase your attack surface, disable password authentication for SSH at /etc/ssh/sshd_config with PasswordAuthentication no. Well…you should always disable password authentication for SSH.
file permissions
The important thing here is to prevent the webserver from writing files. There are some exceptions, as you might want to allow functionality such as image upload (so I can haz pretty potatoes pic).
You can have all files with owner and group wp-user, everything with 644 (files) or 755 (diretories).
The exception is wp-content/uploads that must be writable by the group (775) and have the group www-data set. You don’t need to allow webserver writing for the others since updates and installations are done through SSH and run with wp-user.
wp-admin
/wp-admin is a prime target for attackers because that is where you login to administrate your blog with your admin username and your weak password :)
Leaving /wp-admin world accessible exposes you to two problems: credential bruteforce/reuse/theft and direct access to files that may have all sort of vulnerabilities.
The most practical way to protect you from these is require some sort of authentication, say basic authentication. With nginx you just need to add this to your virtual host
location = /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /path/to/your/htpasswd;
}
and define the username and password. Please use a strong password here and also for your /wp-admin accounts.
EDIT
Also protect the /wp-login.php since it is used to login to edit the blog.
I include the snippet below to demonstrate the care you must take with nginx locations while configuring the rules described in this blog. Without going into details, prefix matching has precedence over regexp matching and nested locations with regex must have only regex inside.
location = /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/htpasswd;
}
location ~ .php$ {
location ~* /wp-login.php {
auth_basic "Restricted login";
auth_basic_user_file /etc/nginx/htpasswd;
}
location ~* wp-config.php {
deny all;
}
security plugins
Having many plugins installed is asking for trouble since many have vulnerabilities and don’t even get fixed. So, going against the usual recommendation of not installing plugins, install the Sucuri Security – Auditing, Malware Scanner and Hardening plugin.
After installing, you get a Sucuri Security button on your dashboard side menu that lets you access the plugin dashboard
Some of the features are paid, but you get a few nice things for free. In the hardening tab you can verify if have the proper secure configurations, however some only work if you are using Apache. More specifically, “Protect uploads directory”, “Restrict wp-content access” and “Restrict wp-includes access” will remain red under nginx even if properly configured, because the plugin expects Apache specific configuration.
In the Settings tab you have another interesting feature: the scanner. The plugin can scan your wordpress installation for changes and notify you by email, like an HIDS. Go through the Settings tabs and activate/deactivate options as you please.
Additionally to the 5 previous topics, I recommend following this extra 2:
Delete themes
Regarding themes…you just use one so delete those you don’t use, as well as the pre-installed useless plugin Hello Dolly.
Limit PHP execution
Direct access to PHP files laying around in your installation are known to cause problem, so disable PHP execution wherever you can. If using nginx add the configuration below to your virtual host. For Apache just use the Sucuri plugin or use Google.
location ~* wp-config.php {
deny all;
}
location ~* wp-content/(.*).php$ {
deny all;
}
location ~* wp-includes/(.*).php$ {
deny all;
}
location ~* wp-includes/uploads/sucuri$ {
deny all;
}
And finally…HTTPS
I don’ need extra motivation to make my blog available only by HTTPS but you if you are thinking twice, just remember Google favors HTTPS sites in the search results and you can get certificates for free from StartSSL, for instance.
Configuring HTTPS for WordPress is just like doing it for any another virtual host. Just remember a few things:
- change your site from http://example.com to https://example.com at Settings->General->WordPress Address and Site Address
- force a 301 redirect from HTTP to HTTPS
- send a HSTS header to ensure you are always under HTTPS
- disable all SSL versions and enable only TLS
- enable strong ciphers such as
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:RC4:HIGH:!MD5:!aNULL:!EDH
- enable server cipher preference
Then, go to SSL Labs and test your configuration.
If you are paranoid, you can continue hardening your WordPress, webserver, PHP, and OS forever, but you have to balance that against the time you have available.
So..I guess I have an WordPress blog. Lets see how long it holds without being hacked…
