How to secure WordPress

In this post, I’ll explain different strategies that can be use to secure WordPress.

If you are reading this, you are probably interested in strategies to secure WordPress as much as possible. You can start by reading the following 2 posts where I hint at some strategies which I’ll mention in this post:
1. https://www.tristandostaler.com/siem-102-detect-wordpress-bruteforce/
2. https://www.tristandostaler.com/an-overview-of-a-good-infosec-strategy/

Why we need to thoroughly secure WordPress

WordPress is one of the most popular CMS and website server in the world. It handles “more than 30%” of the websites on the internet. Because of this, bad actors are really interested in finding ways to get control of them.

Like explained in the post titled “An overview of a good InfoSec Strategy“, it’s important to have a defense in depth approach and to understand your Threat Model. If you didn’t read my post yet, I recommend you go read it because I explain what is a defense in depth strategy, a thread model and how to use both of them.

My assumptions

My assumptions for this post are as follow:

1. Your Threat Model is similar to mine as I won’t explain how to protect WordPress against highly motivated bad actors (the strategy is completely different)
2. You have a good control on your WordPress installation to be able to install plugins
3. You have some form of protection against DDOS (mine comes from my server provider, but it could be something like a Cloud-Based WAF)
4. This one is optional but allows for an optimal solution: you have a log aggregation solution or a SIEM to receive the logs and alert on them. You can see my posts on the subject: https://www.tristandostaler.com/category/information-technology/infosec/siem/

The strategy

The basics

The most basics and yet most important thing to secure WordPress is to make sure it is always up to date. The same goes for the server, services, plugins, etc. For most systems, like WordPress, the server or the plugins, you can enable automated updates.

I can already hear people telling me that by auto-updating something you have a risk of breaking it, or for the most fancy people, the risk of supply chain attacks.

For the first ones, I answer that you do need to measure the risk attributed to your context and take an informed decision, but for me, in my context, the risk and the impact of being hacked is of greater importance compared to the risk and the impact of having my website break. With a product mature like WordPress, and because I only use mature plugins still maintained, I have been using this strategy for a long time now and didn’t have any problem. The only problems I saw with other websites are when the customization to WordPress was not done following WordPress best practices (I once saw someone directly modifying some core WordPress files. That’s not a good idea and there are well documented, supported and official work around to fully customize WordPress). I challenge you to find a good reason not to keep everything automatically updated! If you do, please leave a comment in the comment section below, I am always looking to debate and learn!

For the second ones, I answer that supply chain attacks are real, but are currently more a buzzword than a real threat if you keep to mature and well maintained plugins and services. Of course, if you are a highly interesting target for attackers, my answer is not the same, but then I would direct you to my assumption number 1. The risk of not updating your WordPress is of magnitude superior (and I mean, really really really far superior) compared to the risk of a supply chain attack on a mature and maintained WordPress plugin. Also, make sure to uninstall plugins you don’t use.

After you’ve enabled automated updates, make sure you only grant the minimum privileges required by the persons updating the content of your site. In WordPress, you can give a role to a user to restricts permissions, more info here: https://wordpress.org/support/article/roles-and-capabilities/. Keep the number of Administrators and Super Admin to a bare minimum, and Ideally, lock your Super Admin away. If you have a WordPress with multiple admins (unlike my blog where I am the only one), you can split your Administrators and Super Admin password between multiple team using Shamir’s Secret Sharing algorithm. Admins of all kinds should be used only when necessary and account with less privileges used on a day to day basic. For example, your users could write posts with the “Author” privileges, and then reviewers could review and publish them using “Editor” privileges. Admins privileges are really only necessary when dealing with plugins, users, etc.

In my case, I pushed the principle a bit further and use the “User Role Editor” plugin to customize these roles to allow the strict minimum for most utilization use cases I have. On top of this, because you can be a Patreon subscriber which gives you an account in WordPress to allow you to access private posts, I used the “Code Snippets” plugin to hide some information in the profile page and restrict the logged on section to only the profile page.

The security plugins

I am using a few security plugins to help me protect my website.

The first plugin I am using, and probably the most important, is the Wordfence Security – Firewall & Malware Scan plugin.

This plugins adds a lot of excellent security features:

1. I can have MFA when logging in
2. I can add a CAPTCHA to any page that have input fields (the login page, comment sections, etc.)
3. This plugin will help protect against Bruteforce Attacks
4. This plugin will also detect other attack patterns commonly seen in WordPress
5. This plugin will periodically scan the files on the server to detect potential viruses, changes to existing website files or any other Indicator Of Comprise
6. And many other security features. The complete list can be found on their website: https://www.wordfence.com/products/pricing/

The second plugin I am using is the WP Activity Log plugin.

This plugin is useful to keep a log on all actions that occurs in the administration area of the website as well as other relevant information like system operations, logged in user activity, etc.

If any incident occurs on my website (security or otherwise), I can go in the plugin main page to see if any action occurred just before the problem that could maybe explain the problem. This plugin was useful to me on another website to discover that another user installed a plugin that broke the website and that this user did not test the plugin before activating it. I could also see other actions that the user did that broke even further the website. With all this information, it was way easier for me to fix the problem.

The third plugin, and last worth mentioning in this post, I am using is the Jetpack plugin.

This plugin has many advantages for security but also for other things like performance, site statistics, etc.

Security related, this plugin allows me to:

1. Be alerted if my website is down
2. Have another layer of Bruteforce protection
3. Keep the 20 most recent activity events (for the free version), like for the WP Activity Log plugin, but with all the information being sent to Jetpack cloud’s, allowing this information to be available even if the website is down, for example.
4. With a paid version, you could even automate and protect your WordPress backups

With the combination of these 3 plugins, I am highly confident that most of the attack scenarios are covered and protected.

Using a SIEM

A WordPress website is hosted on a physical computer and is served using a HTTP server that understands the PHP language which WordPress uses, like the Apache HTTP Server project. These software will record a lot of useful information on all activity happening on the website. All requests to a page of the website is recorded, be it a consultation of the website or a modification of the website. These logs can be sent to a SIEM for further analysis. This can then be used to alert and/or automate responses on attack patterns. For example, when a bruteforce is detected and blocked by one of my plugins, I will forever block the malicious IP from accessing my website (unless I manually reapprove the IP).

To get started on this point, you can read my posts on the subject in the SIEM 100 series:

1. SIEM 101 — Introduction
2. SIEM 101 — Initial setup
3. SIEM Solutions 101 — Basic usage
4. SIEM 102 — Detect WordPress bruteforce

Please note I recently changed the SIEM I am using. I explain the reasons here: Why I switched from Logz.io to Humio

Conclusion

I hope this post gives you a good idea on what to do to secure a WordPress website. If your context is slightly different, I hope it gives you enough information to devise your own strategy.

If you need advise in your specific context, don’t hesitate to contact me, it will be my pleasure to give you some hints! Also, if you want to secure a WordPress instance against highly motivated Threat Actors, don’t hesitate to contact me, I can definitely give you useful advices.

Feel free to leave your comment down here for any questions or comments.