A Beginner's Guide to WordPress Security

WordPress is one of the most popular blogging/CMS (Content Management System) applications in existence; according to some statistics, WordPress accounts for more than 50 per cent of all CMS-powered websites totaling more than 60 million websites worldwide. This popularity has a flip-side though: there are probably more compromised (hacked) sites running WordPress than any other CMS. But this does not mean that WordPress is inherently insecure – or that it cannot be made secure.

In this post, we’ll take a look at some of the common issues that can lead to compromised WordPress sites – and some of the basic strategies that web developers can use to help ensure the security of WordPress-based sites.

THE PROBLEM

Before discussing the ways to keep WordPress sites secure, we first need to understand the basic reasons why so many WordPress sites have been compromised. As mentioned previously, WordPress is not inherently insecure – despite the large number of compromised sites, there have been few security vulnerabilities found in WordPress itself. Instead, when a WordPress site is compromised, it is almost always due to third-party add-ons: specifically themes or plugins created by companies and individuals other than the core WordPress development team. The reality is that many of these available themes and plugins for WordPress were created by people who lack the time, money, and/or knowledge to ensure that the code they’ve written is free of vulnerabilities – so they release software with easily-detectable security flaws, and any sites that use that software inadvertently expose themselves to security compromises.

And while it’s less common, there have also been reports of WordPress plugins and themes with intentional security vulnerabilities – in other words, they contain “back doors” that allow attackers to easily compromise sites which use those themes or plugins. These attackers download existing, legitimate themes/plugins, add malicious code, and then redistribute them to unsuspecting users. These purposeful security breaches are much less common than unintentional vulnerabilities though, and are best avoided by only downloading themes and plugins from well-established, reputable sites.

As mentioned earlier, compromises of WordPress sites can been seen as a side-effect of the software’s popularity. The vast majority of website compromises are done for some sort of financial gain: E.g. to upload phishing pages, which can be used to steal login information for banking sites (or Paypal, historically one of the largest targets of phishing scams). Compromised sites can also be used to send out spam, often advertising websites that sell illegal/counterfeit pharmaceuticals. The popular image of a lone, renegade hacker is largely outdated – today, most malicious activity on the internet is carried out by organized criminal groups. Because of the financial motives, attackers will look for exploits that allow them to make the greatest profits with the least effort – the same as any low-margin/high-volume business.

But the effects of WordPress’ popularity cut both ways: the people who exploit WordPress vulnerabilities tend to be lazy and not particularly skilled or knowledgeable – the vast majority have no clue how to compromise a website on their own, so instead they rely on turnkey exploits created (and sold) by others. They’re little more than the digital equivalent of someone who walks through a parking lot and randomly tries car doors, in the hopes of finding one that’s unlocked. This means that if an attacker can’t break into your site on the first few attempts, then they will likely just give up and go looking for easier targets.

THE SOLUTIONS

First off, it’s important to understand that there is no magic bullet or one-size-fits-all solution to securing WordPress. For those who insist on a one-size-fits-all approach, this is the closest you’re likely to get:

• keep your WordPress installation up to date
• don’t install any third-party code (no plugins or pre-made themes)

While that approach would be effective, it’s not realistic for the vast majority of sites. Instead, there are some general best practices that are not necessarily infallible, but they will protect you from most security vulnerabilities. It’s worth noting that these recommendations apply not only to WordPress but to any web-based application (and web development in general. And while I’m not a computer security specialist or expert by any means, I can (anecdotally) say that thanks to following these best practices, no WordPress site that I’ve been personally responsible for has been compromised (in 6-7 years of working with WordPress).

SOLUTION 0: CHANGE UNSAFE DEFAULTS

Before WordPress 2.8, users weren't given any control over the username of the default account created during installation; instead the installer would automatically create an account with the username "admin". It's this old default setting that has allowed the recent mass brute-force attack against WordPress sites, combined with the fact that WordPress lacks any built-in protections against brute-fore attacks (unlike many other applications that will temporarily block users after failed login attempts, and/or notify the site administrators by EMail).

Even sites that are kept up-to-date are not necessarily safe from those attacks, because WordPress upgrades do not remove the old "admin" user accounts. For these reasons, it's highly recommended that you check your WordPress dashboard (the "Users" section) to see if you have an "admin" user - or any other easy-to-guess usernames, such as "administrator", "test", or "root".

If you do find one of those accounts present on your site, you should create a new administrator user (if you don't already have one). Then you can delete the original "admin" account and re-assign all of its posts and/or comments to the new account.

SOLUTION 1: MINIMIZE YOUR USE OF PLUGINS

In computer security parlance, there’s a concept known as “minimizing the potential attack surface area.” Or, to use an analogy: by adding more links to a chain, you increase the chance of adding a weak link, so the fewer links the better. This concept applies to WordPress plugins: when you minimize the number of plugins you have installed, you minimize the risk of having a plugin that contains a security flaw. This applies to third-party themes as well, but less so because of their nature: typically you can only use one theme at a time, but you can have dozens (or even hundreds) of plugins installed at one time.

This approach is, of course, much more realistic than completely avoiding plugins – especially if you need functionality that is only available through third-party plugins. That said, there are many plugins that can be easily done without, especially plugins for embedding content from external services (usually called “widgets”). For example, I’ve encountered plugins for the “Share This” service, which provides a widget for sharing content via multiple social networks – and a widget for Disqus, which allows you to make use of their commenting system. But those plugins should not be needed by anyone with a basic knowledge of web development: both services can be enabled by simply adding a few lines of JavaScript directly to the template file(s). And at the risk of sounding harsh or elitist: if you don’t know how to do something that basic, then you probably shouldn’t be trying to build a website entirely on your own – because there will almost certainly be problems that you won’t see coming and that you won’t know how to fix.

And while the focus here is on avoiding security compromises, this approach often has benefits beyond security. Here’s a problem familiar to most WordPress developers and webmasters: you install a WordPress update, and it introduces a change that breaks one of the plugins you depend on – so you look for an updated copy of the plugin, only to discover that the plugin developer abandoned the project 2-3 years ago. So you have a choice between losing the plugin’s functionality, or being stuck on an old version of WordPress (which may contain security vulnerabilities). Minimizing the use of plugins reduces the chance of encountering that problem.

SOLUTION 2: EFFECTIVE PLUGIN MANAGEMENT

In addition to minimizing the use of plugins, it’s important to be diligent about managing the plugins that you do have installed. This begins with obtaining plugins from reputable sources/sites (namely, WordPress’ official plugins site). You should also keep your plugins up-to-date whenever possible – WordPress will notify you when plugin updates are available, and allow you to install the updates directly from the dashboard.

There’s one important aspect of plugin management that requires a bit more manual effort, however: removing un-used plugins. It’s important to understand that if a plugin contains security vulnerabilities, those vulnerabilities can still be exploited even if the plugin has been disabled – because if you merely disable a plugin, the files are still present on the server and continue to pose a security risk. Therefore you shouldn’t just disable unused plugins, you should delete the file(s) as well (using FTP or the file manager in your hosting control panel).

This not only reduces the risk of security vulnerabilities on your site, it also makes it easier to find (and remove) the vulnerability if your site does get compromised. As a hosting provider, we often end up helping to clean compromised sites that were developed by others & there’s one common problem we see repeated over and over again. Because of the number of plugins available for WordPress, developers will often try several different, but similar plugins – and because many developers are lax when it comes to removing unneeded plugins, we’ve encountered sites that had 15-20 (or more) plugins, when only 4 or 5 were actually needed. And if the original developer didn’t properly document their work – an all-too common habit - then (by the time the site gets compromised) the original developer will probably have no idea which plugins are needed and which can be safely removed.

In those situations, something that should be relatively simple turns into a time-consuming, drawn-out, frustrating, and potentially expensive exercise in trial-and-error. You disable and remove one plugin, then test to see if that breaks anything on the site, then wait a few days to see if the site gets compromised again. The time this takes is multiplied by the number of plugins on the site – the process can sometimes take weeks – which is another good reason to minimize the use of plugins.

And this recommendation applies to themes as well. Old, unused themes should be completely removed – not just deactivated, but physically removed from the server.

SOLUTION 3: SECURITY SCANNING/MONITORING SERVICES

There are a number of companies that provide website security scanning & monitoring services, easily found with a quick Google search for “wordpress security monitor.” Most of these services are commercial (AKA they cost money) and I haven’t used them before, so I can’t recommend for or against – though I have occasionally used Sucuri’s free SiteCheck service. That said, there have  been some recent claims that these types of services can cause more harm than good, especially those that display some kind of seal or badge on participating sites. The idea is that the badge/seal is there to verify that the site is not infected, or vulnerable to infections – but if a vulnerability is found, then the badge/seal is removed and that can inadvertently alert attackers that the site is now an easy target.

But I have found one free service that has been very useful for monitoring websites for security breaches: Google’s Webmaster Tools. If you register your site with Webmaster Tools, then Google will alert you if someone reports malicious or infected pages on your site, regardless of whether your site uses WordPress or another CMS. It will also check for a few WordPress-specific issues, and alert you if (E.g.) your site is using an outdated version. And, as we’ve detailed in some previous posts, Webmaster Tools can help with analysing and cleaning-up after a website compromise.

There’s also a very useful (free) plugin called WordPress File Monitor Plus – it can be obtained here, or by simply going to “Plugins > Add New” in your WordPress dashboard, and searching for “WordPress File Monitor Plus”. It will monitor the files in your WordPress installation and send you an EMail notification if one of those files is changed – which is very helpful for detecting security breaches. It does take some work to get it configured properly, however, especially if you use any caching plugins that regularly create new files. Effective configuration & use of the plugin is outside the scope of this post, but we will likely post a guide to that in the future.

DISASTER RECOVERY

So far, this post has largely focused on preventing security compromises – but it’s still very important to be prepared in case there is a security breach. The recommendations in this post will help reduce the risk of security breaches, but problems can still occur even if you diligently follow all of the best practices. While it’s less common today, websites are still sometimes compromised by exploiting flaws in lower-level software, such as the web server, the database server, PHP (a widely used scripting language), or the server operating system itself (typically Linux or Windows). If one of those components contains a security vulnerability, then it could be used to compromise a WordPress-based site even if the site itself is secure. And there’s always the possibility of vulnerabilities that are specific to an individual server, such as security features that have been disabled or configured incorrectly.

If a problem like that happens, then chances are that your primary goal will be getting the problem fixed as quickly as possible. And there is one simple recommendation that will make “disaster recovery” as painless as possible: backup your website on a regular basis (both the files and the database contents). There are numerous different methods of backing up a website, ranging from completely manual to completely automatic (and everything in between). There are several command line tools that can be used to automate backups (wget/rsync & mysqldump), the CPanel software has a backup feature that works well for one-off backups, and of course there’s always the manual method of downloading the files through FTP & exporting the database contents from PHPMyAdmin. While the specific steps are outside the scope of this post, we will likely post a future guide to automating website backups.

There’s a little more to it than that, of course. In addition to performing regular backups, it’s a good idea to keep an archive of old backups. In IT terms, this is known as “backup retention.” Sometimes website compromises aren’t discovered immediately – so if you only keep the most recent backup, there’s a risk that you could inadvertently backup the infected/compromised files (leaving you without a clean backup to revert to).

How long should you retain old backups? There’s no one-size-fits-all answer, but the best general policy is to retain old backups for as long as you can – which will largely depend on the amount of data stored on your site & what you can afford to spend for storing old backups. For most sites, it should be possible to keep several years worth of backups without the need for a huge amount of diskspace, especially if the backups are zipped (or compressed using some other method). And spending a hundred dollars or so on an external hard drive (to store backups) can save you a great deal in the long term, especially if you depend on your site for your business.

At the very least, don’t make a blind-faith assumption that your hosting provider will be able to bail you out in the event your site gets compromised. Performing backups for an entire server is much more complex than backing up a single website, and it requires much greater amounts of diskspace – as a result, many hosting providers only retain the most recent backup, and only for a short period of time (15-30 days is common). Or at the very VERY least, be aware of your hosting provider’s backup retention policy; in most cases, you can simply ask their support staff. And some hosting providers do offer separate backup services that you may be able to make use of (if you prefer to let someone else handle that for you).

CONCLUSION

So what are the key points to take away from all of this? One, that being organized and following basic best-practices for web development will keep your site safe from the majority of threats – don’t use third party plugins/themes unnecessarily, and remove any that you’re no longer using. And two, it’s important to have a plan for disaster recovery if your site does get compromised – including monitoring tools to alert you if a problem does occur, and backups that you can restore from.

Or, in the simplest possible terms: an ounce of prevention is worth a pound of cure – but you should still keep some cure around, for those times when prevention fails.

OTHER RESOURCES

• Hardening WordPress « WordPress Codex
• 10 simple ways to secure your WordPress site
• Securing Your WordPress
• 28 Ways to Secure WordPress Website

Last update: 12 July 2016

Comments