Now that I have my WordPress sites up and running, I figured it was time to start working on locking them down. So I’ve been spending the past few weeks securing the server and the site to make sure there are no problems moving forward. It’s important to take actions these days as the threat by attackers continues to rise. Such is the case with my primary blog site which is currently being probed every few minutes all day long by bots from around the globe. Hopefully I can share some insight that others might consider for their own sites.
To start with, it might be good to provide a little refresher on how the site is architected. I’m running two WordPress sites on an Ubuntu server in an AWS EC2 instance. To manage access to both sites, I’m using Nginx as the front end web server. Using Nginx actually offers me a lot of flexibility and has been key part of helping to secure the site.
Securing the Connection
One of the first things I did was to move the site to secure connections. That meant putting certificates in place and directing all traffic to HTTPS connections. This keeps all logins and form submissions secure and improves the site’s posture with Google and other search engines. To do this, I found a great tutorial from Digital Ocean about how to secure an Nginx site with certificates from Let’s Encrypt. Using Nginx’s Certbot plugin, you can easily request and install certificates for all the sites you’ve configured.
The plugin examines the Nginx site configurations you have enabled and submits CSRs for those sites. It also puts in place the necessary Nginx configuration statements to enable HTTPS connections for the site using the certificates issued. It also gives you the option to redirect any non-secure connections to the secure site, something I strongly encourage. The only thing I have to do is renew the certificates every three months. Other than that, they are free and completely reputable.
One other suggestion I have is to go back to the overall Nginx configuration and remove any SSL protocol other than TLSv1.2. Protocols below 1.1 are susceptible to several exploits and even 1.1 has problems in some cases. Play it safe and just go with 1.2. You can find this in the Let’s Encrypt directory under etc in the options-ssl-nginx.conf file. The only risk is that Let’s Encrypt could overwrite the changes with periodic updates.
iThemes Security
Most of the security for my WordPress sites is handled by a free plugin called iThemes Security. It’s one of the highest ranked security plugins and has proven to be easy to use and configure. There is a Pro version that offers many more security options such as MFA, but at this point I really don’t see a need to pay the money. The site is small and I’m the only contributor, which brings me to the first measure.
Separate Admin Account
Since I re-launched my site, I’ve seen a steady stream of probers (I wouldn’t call them attackers) who hit my other site every few minutes trying to log in. Before I put some other measures in place I’ll get to later, I noticed they were using the account I used to author the posts. Since that account also had administrative privileges, I quickly created an admin account with another name and demoted the original account to author. That significantly reduces risk.
That should be the case with any system you use or manage. Separate of duties and privileges is a core security tenet and isn’t that hard to manage. With this in place, the most a successful attacker can do is to alter the content of my posts or author posts of their own. They have no other tools at their disposal. Add to that a non-typical admin account name and long password and the chances of breaking in as an administrator are reduced significantly. Oh, one other thing is that the account I changed to author also had an ID of 1, the typical administrator account.
Disabling XML-RPC
Another method used to log into WordPress is through the XML-RPC web service request. It’s typically used for authoring tools that communicate with WordPress through the web service to post content and interact with the site. To do so requires authentication which is why the authentication web service is exposed. You can disable this in the WordPress Tweaks section of iThemes Security along with several other features. Disabling XML-RPC will require a restart of your web server (e.g. Nginx), but that shouldn’t be a problem.
Changing the Admin Path
Probably one of the most significant ways of securing the site was to change the Login slug path. This is the path that users logging into the site use to authenticate. Bots know the common path and will attempt to log in using that path. By changing it to something obscure, bots will get a 404 page instead, preventing them from attempting to log into the site.
As of now, bots have stopped trying to log into my main blog site and have discovered this site, attempting to log in about every 3 or 4 minutes. I’m sure that will subside as the C2 servers determine it’s a wasted effort and move on. After all, the bots are a resource they have to use judiciously to avoid being detected.