Daniel Brinneman is a WordPress Theme Designer specialist and creates custom themes for self-hosted websites. He resides in Waxhaw, North Carolina.
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 accomplish each step. I may cover these steps in a later article.
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 deem 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 using it on a regular basis. 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 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 modify 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 Forward Secrecy, OCSP stapling, Public Key Pinning (HPKP) and Strict Transport Security (HSTS).
Once I complete work on the web server it’s 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 review my server logs.
I also perform my own 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. Most WordPress security issues can be traced back to insecure software development practices. Plugin updates are part of my regular weekly security checks.
If you need help implementing these WordPress security tips, I am available for hire.