Fellow, Desk.pm user, Daniel Brinneman recently 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 the same process, I wanted to cover the personal process I use for securing 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. You 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 webserver 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 immense privileges. Because of the heightened privileges of the root account, I would discourage using it regularly. One of the reasons for 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 I want something that I can also remember. Do not store this password in a plan text file. I recommend using a password vault. 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 disable and remove any unneeded services (FTP, Telnet, etc.) , and then install and configure file integrity monitoring software. Next, I harden the webserver. 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). I recommend using TLS 1.2 as a minimum and choosing strong cipher keys.
Once I complete work on the webserver, it's time for MySQL and WordPress. I change the MySQL database password, run the MySQL security script to remove all defaults. I make sure that the database server only allows local access. One additional step is to configured a local firewall that restricts access only to the needed ports (e.g. 22, 443, 80). 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
Optuonally, 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 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.