We often get asked what security measures we implement when hosting our client WordPress websites. How is your website being secured? Do you need additional security plugins?
Let’s preface this article by saying that we can (and will) adjust the below default setup if your website requires modifications as no single website is identical. Further, security is a broad topic and there is no ONE way to secure a website or a server, in fact, there are several different avenues one could take to successfully secure their environment.
With that said, this article outlines how we’ve decided to implement our default security setup in order to lock down and secure your WordPress site(s). We take the security of your websites and our servers very seriously. We are constantly learning new things and implementing new procedures to keep up with the every changing digital landscape, and, as such, will keep this article up-to-date as our default setup changes.
We have broken our security strategy into two parts: Prevention and Detection/Recovery.
Prevention includes everything we do to keep your websites secure before there is an issue (aka: keeping the bad actors from ever accessing your website). We do everything we can to prevent a security threat before it happens and, as such, most of the details below are about the prevention measures we’ve put into place. Theses measures include implementing a web application firewall (WAF), server and application hardening, and security best practices.
Detection/Recovery is all about planning for the worst-case scenario. In the event, despite all of our efforts, your site still gets hacked, this part of our strategy covers how we will detect an issue, minimize risk of reputation damage to your website and company, and get the site cleaned up and back online as quickly as possible.
Before we dive in, it’s important to understand the 3 levels of security that applies to websites, not just WordPress security. The earlier a threat can be stopped in the chain, the better. A request to view your website first goes to DNS, then goes to the server, which then loads the application (application = WordPress website in our case) to display the website. Therefore, the chain goes DNS > Server > Application.
If you’re not sure what DNS is, DNS stands for Domain Name Servers. This is where all request to visit your website go first to figure out where your website files are actually hosted. Real web addresses aren’t the nice, memorable strings you type into your address bar (i.e. watchdogstudio.com). The real address is the IP address, a special number, that is assigned to the server in which your website is hosted on, which looks something like: 18.104.22.168. To make it easier to find the website you’re looking for, Domain Name Servers were invented. These are special servers that match up a web address you type into your browser (like “watchdogstudio.com”) to the website’s real (IP) address.
If we can block an attack at the DNS level, the bad actor never even reaches our servers. Next if we can block an attack at the server level, then the attack is immediately dropped and never reaches the application (aka, your website).
We take this approach to security in order to prevent attacks before they even reach your website. If an attack can’t reach your website, it can’t compromise your website to begin with.
Before we even get to the details of what we do, it’s important to look at what you do.
Security extends beyond just website security itself, but actually starts with the user logging into the website. Malware on your computer could theoretically scrape usernames and passwords or grant backdoor access to a hacker who could steal all kinds of information.
We can do everything to build Fort Knox to protect your website, but if you leave a key out under the mat at the front door, there is really not much we can do to protect you.
Just like you maintain good hygiene habits day-in-day-out (taking a shower, brushing your teeth etc — at least we hope), you should do the same and take the time to approach your It and online systems “health.” A little cyber hygiene goes a long way. In fact, implementing the most basic security controls could reduce the potential of a cyber-attack by 80%!
We recommend 4 primary things to enhances your cyber hygiene dramatically.
There are a few fundamentals that every website should follow. While we take care of some website security for you, there are some things you are responsible for.
When we deploy a new server, our deploy scripts take care of a ton of details the instance the server is ready for website deployments. Then, once a new website is setup and/or migrated over, additional security steps are implemented to the website itself.
All of our servers are hardened during the provisioning process. Ports are locked down, and Fail2Ban and the Linux UFW (uncomplicated firewall) are preconfigured. Access to every server is restricted by SSH key and server security updates are applied automatically so we don’t have to remember about them.
No one can access any of our servers over an unsecured connection. No exceptions. We configure every server to only accept connections via SFTP and SSH.
We isolate websites by assigning each one a different system user. This way, if a website on a server does get hacked/infected with malware, the malicious code will be unable to spread to other websites on the same server.
By default, when a new website is created and/or transferred to one of our servers, we set all files and folders with secure READ, WRITE and EXECUTE permissions. These permissions determine who is allowed to do what, and loose permissions leave your websites and servers open to attack. If you’re interested in learning more, you can read up on WordPress file permissions.
Every website is provisioned on an up-to-date version of PHP. We are currently defaulting to PHP 7.4.
WordPress runs on PHP. If the version of PHP running your website is out-of-date, this could mean the core running your website is no longer actively supported and therefore there are no more security patches coming. As a bonus, up-to-date PHP versions generally offer significant performance improvements. While PHP 7.4 is currently the most up-to-date option (PHP 8 is coming soon) and faster than it’s predecessor, 7.3, not all plugins play well with it (which is not a good sign for that plugins longevity). If you find you have a plugin or theme that doesn’t work with PHP 7.4, we can downgrade your PHP version to 7.3, but we’ll recommend you consider looking for an alternative option.
HTTP Strict Transport Security protects against Man-In-The-Middle (MITM) attacks and cookie hijacking by forcing the use of HTTPS and preventing sensitive data exposure.
Due to forcing HTTPS, this needs to be implemented in combination with an SSL certificate. Lucky for you, Watchdog Studio implements SSL certificates by default on every site running on our servers. To implement HTTP Strict Transport Security, once the SSL certificate is provisioned for your website, we automatically add this header to your website:
The “31536000” at the end is the number of seconds in a year. This instructs browsers to only access the server over HTTPS for the next year.
We automatically prevent anyone from seeing any of the WordPress installation files (including all PHP files and dotfiles like .user.ini) and disallows access to readme.html, readme.txt, install.php, and wp-includes.
This measure prevents sensitive data exposure which can be used in an attack against your website. The less information a hacker has to work with, the harder it will be to attack your site.
We also move the wp-config.php file, which contains database usernames and passwords along with other sensitive information one level up from the main root directory, where all of the other WordPress files are stored, to keep it hidden and protected.
Finally, we block install.php. This file is used to install WordPress, but WordPress is already installed so it is redundant.
WordPress allows links to be imported or exported using the OPML format via the wp-links-opml.php file. Hitting this page presents an XML output with details of the WordPress installation. Some bad bots will try this page when exploring your site for information. Most websites do not use this functionality, so we block it by default. If your website requires this functionally, let us know and we’ll happily unblock this for you.
A brute force attack is a bot hammering away at your login page in an attempt to gain access to your website by systematically entering all possible passwords until the correct one is found. If left unchecked, this can put a tremendous strain on our server resources. Feel free to read up on a few examples of different types of brute force attacks if you’re interested.
Fail2Ban is pretty amazing. It helps prevent brute force attacks, keep bad bots off our servers, conserves server resources, and even blocks comment spam. We’ve implemented a direct integration with the WP Fail2Ban plugin and looks for patterns of bad behavior. Some of the things Fail2Ban detects include things like failed login attempts, user enumeration (where a bot probes your site for usernames), and then bans the offending IP addresses. It does this exceptionally well.
Additionally, we add additional protection for wp-login.php in which we will “jail” any IP address that fails to login 5 times. The offending IP address will be “jailed” for 20 minutes.
We also place a limit on the number of requests that can hit wp-login.php at the same time to 1 hit per second. This means the login page can only be accessed 60 times per minute per IP address (and not, for example, 1000 times per minute by the same IP). If the rate limit is reached, the request will be dropped with a 503 error code.
With all of the above measures in place, a brute force attack on these websites would be a fruitless waste of time for any would-be attacker.
“Denial of Service” or DoS is an attack with the goal of taking your website offline by denying access to your website. This is accomplish by an an attacker flooding the server your website is installed on with TCP and UDP packets. These packets overwhelm the server’s resources, rendering it unable to serve your website’s visitors, possibly causing the server to shut down entirely.
A DDoS attack has the same goal, but uses multiple connections that target a single system, making it easier to overwhelm the server while also making the attack itself more difficult to mitigate. Large scale DDoS attacks use thousands of connections, often other compromised devices or servers (also known as a botnet), to attack a single server.
So, let’s look at how Watchdog Studio protects our servers and your website(s) from these attacks.
Fail2Ban helps mitigate DoS and DDoS attacks by identifying bad behavior and blocking IP addresses that are hammering the server. While this is a good first line of defense, unfortunately, hackers/attackers know about Fail2Ban and how it works, so it is unlikely Fail2Ban will be able to provide the protection necessary against a massive attack.
XML RPC is an old, outdated, and insecure method of remotely posting to a WordPress website. Attackers know WordPress websites have the xmprpc.php file available in the open and will generate several requests to the file causing excessive server CPU and memory usage.
There are plugins available that can disable XML RPC at the WordPress (application) level, however, this will not prevent the requests from reaching the server and loading the application. If the requests are still able to load the application, with enough bad request at a time, the attack can still overwhelm the server and bring it down.
Most of websites no longer need or use XML RPC, so, by default, we disable it. If you have a case for having it enabled, please reach out and we’ll have it reenabled for your site.
WordPress has a feature that concatenates wp-admin JS and CSS using load-scripts.php and load-styles.php which can be exploited to create a DDoS attack on your website. This was a good idea before the age of HTTP/2 (which all sites on our hosting use). With HTTP/2, there is no need to concatenate files, in fact, it is actually an anti-pattern and therefore concatenating load-scripts isn’t really necessary. Because of this, we disable it by default.
Creating GeoIP restrictions is the practice of blocking traffic from specific countries from accessing your website. We can implement restrictions at the server level, but better yet, these restrictions can be created at the DNS level using Cloudflare’s free firewall rules. The payoff vs the inconvenience of blocking/unblocking different countries on request needs to be considered when implementing GeoIP restrictions. However, if you only serve customers in a single country, we highly recommend implementing GeoIP restrictions to mitigate, not only DDoS attacks, but any type of malicious activity and to save precious server resources.
This is one of the primary reasons we require DNS to be hosted with Cloudflare. If we notice your website is under attack, we can flip a switch in Cloudflare and turn on “I’m under attack” mode. If all else fails, this option would be our final stand.
“Cloudflare Under Attack Mode performs additional security checks to help mitigate Layer 7 DDoS attacks. Validated users access your website and suspicious traffic is blocked. When enabled, visitors see an interstitial page… The “Checking your browser before accessing…” challenge determines whether to block or allow a visitor within 5 seconds.” – Understanding Cloudflare Under Attack Mode
While not perfect for visitors, it is far better than the alternative. Feel free to read up and learn more about Cloudflare’s under attack mode.
Next up is blocking injection attacks trying to compromise your website with malware and/or send malicious code to your website visitors.
When most people talk about malware, these are the types of attacks they are referring to and the ones we dread the most. They are horrible for your reputation, SEO, and visitors, and a serious pain to clean up. Google blacklist over 10,000 websites every single day due to these types of hacks. Once blacklisted, you’ll see organic traffic to your site drop dramatically, upwards of 95%!
A good WAF enhances every aspect of your website’s security, including everything we’ve already discussed. By default, we deploy a ported version of the 7G Firewall on all websites we host. 7G is extremely lightweight and allows us to add custom rules as needed.
Alternatively, when on a dedicated hosting plan, we can deploy the ModSecurity firewall. ModSecurity is a sophisticated enterprise-level firewall that is configured to protect sites from a wide array of attack vectors including:
Due to the more comprehensive nature of how ModSecurity detects patterns of bad behavior, it requires more resource to run than the 7G WAF, which is why we only deploy it for clients on a dedicated server and only if necessary. Further, ModSecurity takes some time to fine tune based on the functionality of a given website.
WordPress has a built-in mechanism to allow trackbacks (notifications on your posts that someone has linked to them). Unfortunately, trackbacks have, in the past, led to several MySQL injection vulnerabilities and if unguarded can lead to a lot of SPAM. By default, we block trackbacks on all sites. If you have a desire or need for trackbacks, we can enable it for you.
These 3 directories each need to be writable for your website to function properly. Your theme and plugins need their directories to be writable to upload and update, and your uploads folder needs to be writable so that you and other users can upload files to your website.
The problem here is that, while this is a necessity for your site, it means that hackers can exploit these directories by uploading malware to them. If this happens, and your directories also allow for PHP execution, then malware can be executed and infect your site.
Disabling PHP execution won’t prevent hackers from being able to inject PHP malware if your site has a vulnerability through either WordPress core, a theme, or a plugin, but, it does mean that this malware won’t be able to execute once injected.
This is a major step towards preventing one of the most common types of security vulnerabilities, especially as plugin vulnerabilities are the leading cause of WordPress hacks.
This is one of the options we won’t disable within our shared hosting environment as we believe it is a core security feature keeping your website and our server safe. If you have a plugin or theme that requires PHP execution, first, we recommend you contact the plugin author and/or look for an alternative solution. If neither is an option, we’ll require you to be on a dedicated server to have this feature disabled.
All Watchdog Studio hosted websites are launched with security headers in place to ensure security vulnerabilities such as cross-site scripting and clickjacking are automatically prevented. This shuts down one of the biggest security vulnerabilities on all websites online today, WordPress or not. If you need to allow external iFrames to load on your site, we require the implementation of a custom Content Security Policy. Please review our Clickjacking Protection article.
Cloudflare comes with some great features that can be enabled by turning on the orange cloud on a particular DNS setting within your account. This includes some default firewall configurations implemented by Cloudflare (and that are uneditable) as well as an extra 5 free custom firewall rules. We can implement some custom firewall rules (including GeoIP Restrictions mentioned above) for you if you’d like the added security.
Our recommended Cloudflare firewall settings are as follows:
Malware security scans aren’t enough to detect a security breach. In fact, IBM issued a report stated that, on average, most security breaches go undetected for 280 days! This is due to the lack of sufficient log monitoring.
Not here! We actively monitor the server logs along with your website files and the database for hacker activity. The instant any malicious changes are detected, all users are immediately logged out and the offending user’s password is changed. Best of all, unlike some of the popular WordPress security plugins (i.e. WordFence, iThemes Security, etc.) that will slow down your website, our monitoring is done with zero impact on website or server performance due to the monitoring taking place on a separate server.
Finally, if any malicious code or otherwise was successfully added to the server or your application, it is automatically removed and a root cause analysis report is generated for us to review further in order to lock down any security holes.
“Good backups are like insurance… if insurance covered everything, cost practically nothing, and always paid out. They are the single most cost-effective investment in your online presence that you will ever make.” — Patrick Gallagher, GridPane CEO
As one last step, as insurance, between our care plan and hosting, we have four different backups of your site. Two backups being done by the care plan software on a daily basis to two different remote locations, one backup being performed by the server to yet another remote location, and finally, one hourly backup being saved on the local server every hour.
If anything were to happen to your website, we can easily get it live again within 15 – 30 minutes once we’re made aware of an issue. Easy peasy.
There’s always more than can be done, but the above is what we’ve decided to implement by default. If you’d like even further security, we can assist you with setting up any of the following additional measures:
Some or all of these additional options may be useful depending on how you manage your website.
All of the typical security “suite” plugins that most people think about when we talk about security plugins have their pros and cons. This includes all the well-known names like Sucuri, iThemes, Wordfence, and MalCare etc. There is not much any of these security plugins can offer beyond all of the default settings we put into place. Most of what these plugins do is essentially a band-aid for insecure web hosting.
Due to the ever-changing nature of WordPress (and all CMS platforms), the plugins and themes you might have installed, etc. it’s just not possible to guarantee 100% protection. We can implement a comprehensive security strategy, but we can’t prevent a hack occurring via something we can’t control. As an example, a zero-day vulnerability in a plugin that you might have installed on your website. We’ve put all the pieces in place to keep as many bad actors out as we can and, if somethings does gets through, we’re ready to detect it and clean it within a moment’s notice.
If you do your part by choosing themes and plugins from reputable developers that are actively maintaining their code, all of the security measures we put into place by default will help us mitigate the damage that most potential vulnerabilities can cause.