Welcome by an author (Daniel Brinneman)

The first line of defense in all of hosting and following sections I’ll write about, this being a subtle ‘zero’ or the least thought about topic of consideration, is your choice of usernames and passwords. I’ve had way too many clients always default to these two habits. The first is choosing a username that the whole of WordPress new sites used to have on install, ‘admin’ (no longer the case) and second, choosing a password that was easy for them to remember from anywhere. And then using that same combination on every single online account they had, even their personal accounts. Yikes! And even after I had generated a secure password for them, they changed it to something “easier” to remember. That always makes me feel extremely uneasy because I already can guess what’s in their site’s future. I have my clients’ best interest in mind when I generate those cumbersome passwords.

Update: Daniel moved his content to a new domain. This fixes a broken link. Let’s hope I don’t have to do this again.

Fellow, Desk.pm user, Daniel Brinneman recent wrote an article on how to harden a WordPress website. Daniel’s piece is well written and covers the basics. Please visit his site.

While Daniel and I use basically the same process I wanted to cover the personal process I used for securing my WordPress websites. For brevity, I didn’t go into detail about how to carry out each step. I may cover these steps in a later article.

Hosting Provider

Let’s start with the hosting provider. I want one that is reliable, available and secure. I use a non-shared virtual private server (VPS) hosting plan with Digital Ocean1. Digital Ocean calls these droplets. Digital Ocean has multiple data centres in multiple locations globally offering five popular Linux distributions that can be automatically pre-installed upon deployment of a server: Ubuntu, CentOS, Debian, Fedora, and CoreOS. While I can certainly build my web server stack from scratch I trust the staff at Digital Ocean. I opt to use one of their pre-packaged LAMP/WordPress stacks.

Each digital ocean SSD VPS comes with full root access, a choice of operating systems, and the ability to customise the configuration. With a shared hosting plan, I would be concerned that a compromise on another tenant’s account could lead to a compromise of the entire host. With a dedicated VPS, I can configure as much or as little security as I consider acceptable.

Operating System Hardening

On a *NIX system, the root user is the administrative user that has very broad privileges. Because of the heightened privileges of the root account, I would discourage regular use of the root account. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

Since, with root, I have complete control of the system, I start my hardening process at the operating system level by immediately changing the root password after the server is created. I choose a long and complex password but something that I can also remember. I then create a new non-root account and add it to the sudoers file. Using the new account (via sudo) I change the server SSH configuration to disable root access to SSH, create 4096 bit SSH keys for remote authentication, then disabling and removing any unneeded services, and then install and configure file integrity monitoring software. Next, I harden the web server. I generate and install TLS (not SSL) certificates, configure the web server with forwarding Secrecy, OCSP stapling, Public Key Pinning (HPKP) and Strict Transport Security (HSTS).

Server Services

One I complete work on the web server it is time for MySQL and WordPress. I change the MySQL database password, run the MySQL security script to remove all defaults etc.. I then login to WordPress and create a new admin account — again with a suitably long randomly generated password — before deleting the old admin account. I then install and configure a web application firewall with specific rules around the wp-admin URL and when to alert me. I then install a WordPress security audit plugin with rules about acceptable actions and when to alert me. I then delete all default posts and pages.

Just a Bit More

Finally, I configure CloudFlare or some other content delivery network to help with any denial of services issues. Most of these also offer a web application firewall and robust analytics.

From a security operations perspective, I use the VaultPress service to do daily backups and I check to make sure backups are complete. I have a weekly reminder in my calendar to check the Linux server and the WordPress install for security patches and to check my server logs.

I also perform my vulnerability scanning using various open source tools.

I only install plugins and themes from reputable sources. I try to reduce the use of plugins as much as possible to mitigate the risk of exploitation. Plugin updates are part of my regular weekly security checks.

If you need help implementing these WordPress security tips, I am available for hire.

This post was syndicated to How to Secure a new Linux WordPress Server.


  1. Use my referral link to get a discount on Digital Ocean when signing up, and help me keep my site going. ?