Securing WordPress sites

We have written posts describing WordPress vulnerabilities and the methods hackers use to exploit these. In this post, we describe steps by which a web site owner can mitigate the risks of using WordPress as a content management system. After all, it cannot be denied that WordPress remains the most user-friendly tool for creating and managing both large and small websites, as shown by its enormous adoption rate.

There is a very rich literature describing WordPress vulnerabilities and ways to harden a system against exploits. Here we distill some of these learnings into a practical guide for WordPress-based web site owners. We specifically have in mind small to medium-sized medical practices that wish to use WordPress to create (or maintain) their online portal for patients. In a future post, we’ll describe how such steps can meet HIPAA-HITECH guidelines for safeguarding electronic protected health information (ePHI).

We describe these steps in a layered way – starting at the bottom with the hosting server infrastructure, before moving to the WordPress platform itself and other applications.

Securing the hosting environment

There are at least two options for creating, running and maintaining your web site. One option is to run your own server (called self-hosted), while the other is to place your site on a shared server platform (called a hosted or managed platform).

A self-hosted environment gives you choices over the server environment. You can use a “computer room” in your own office to host the physical infrastructure, use a commercial datacenter, or a cloud provider (such as Linode or AWS). However, such solutions require deep IT skills as you will be responsible for the maintenance and updating of the host operating system and applications (such as PHP and MySQL). If hosted in your office, you’d have to configure the appropriate communications links as well as firewalls, intrusion detection systems, etc. You’d also have to be up-to-date on the latest security vulnerabilities for these components and ensure timely updates[1] when patches are released.

Given the complexity of a self-hosted solution, it is no wonder that the vast majority of web site owners prefer a hosted or managed solution. (In what follows, we’ll assume that most small business sites prefer the managed/hosted environment.) Here, the site is on a server infrastructure maintained by a hosting provider who is responsible for its core software (including PHP and MySQL), their maintenance, the underlying security infrastructure, networking, and external communications. However, you share your site’s underlying platform with hundreds (often thousands) of others.  This is where a thorough analysis of the level of support and services offered by the hosting provider pays off, and it is usually also an instance of “you get what you pay for”. A web hosting service such as LuxSci takes care of all these underlying infrastructure aspects for you and places you on a dedicated server, leaving you only with the responsibility of managing WordPress – although LuxSci can also set this up for you.

In the heady rush to set up an attractive website and start catering to visitors, most website owners forget, or do not give precedence to, the security aspects. In addition to factors such as storage capacity and site availability, the following security-related aspects are an essential part of the due diligence:

• The provider must offer Secure Shell (SSH) tunnels or Secure FTP (sFTP) for site administration and restrict insecure modes of access.
• The provider must offer SSL/TLS for access by your site users[2]. You may have to purchase the site certificate, but free DV ones are readily available. Our suggestion would be to aim for an Organization Validated (OV) certificate.
• Opt for hosting you site on a dedicated server whenever possible.  Operating on a shared server leaves you vulnerable to attack though the compromise of other web sites hosted on the same server.
• It is important to ensure that a hosting provider offers an application-level firewall or an equivalent intrusion detection system. While it is possible to use WordPress plugins for securing an individual site, an overall application-level firewall can prevent all sites on a host from being overwhelmed by a Distributed Denial of Service (DDoS) attack.
• Hacks into WordPress sites can take days to discover. It is important to be able to restore a site to a known safe, earlier version. A hosting provider with a good backup plan that retains backups for a reasonable period is essential in case of a compromise. It is also important to have access to log files associated with a website going back at least a month, to be able to probe the cause of an exploit, when discovered.

The Open Web Application Security Project (OWASP), a not-for-profit organization devoted to improving application level software security on the web, offers hosting providers detailed guidelines on securing their WordPress infrastructure. These guidelines offer information on additional aspects of the infrastructure that are specific to the use of WordPress – the PHP code which powers it and the MySQL used for database access. These guidelines can be particularly useful for a self-hosted site. Hopefully hosting providers are also aware of these and have taken the necessary steps outlined therein. LuxSci follows all the necessary guidelines to secure its hosting environment.

Securing the WordPress Application

Having chosen the appropriate hosting environment is critical, but not enough. Web site operator has the responsibility for securing and running the WordPress installation and any other applications running in the hosting environment. There are many aspects to fine tune here, and a default installation is fraught with peril. Luckily, there are many how-to guides, tutorials, tips and general advice on the web for a diligent WordPress site administrator to study and implement to harden the web site. Google is your best friend for finding these. Some general guidance, which is a synthesis from such sources, follows.

Recall that the core WordPress software is augmented by plugins and themes. Plugins offer a variety of enhanced functions beyond the core, while themes offer additional visual/presentation-related functions. However, these also present a rich source of vulnerabilities, as described in our previous post.

For the core WordPress software, the message is three simple words – update, patch, and repeat. Since version 3.7, WordPress has introduced auto updates for minor releases, which include maintenance and security updates. WordPress urges every site administrator to turn on this auto update feature with assurances that it has, by now, been shown to work safely and smoothly without site disruption. Many site administrators make their WordPress PHP code unmodifiable, hoping to prevent exploits. However, this also prevents auto updates. Updating all the files manually after a new version is released can be a lengthy task. It is far better to stick with auto updates.

As for plugins and themes, it is important to download these from reputable sources. The WordPress.org site has a repository of plugins as well as a directory of themes. Any security flaws in these are likely be swiftly patched. The WordPress auto update feature has also been enabled for themes and plugins. There are also many commercial sources of plugins and themes, especially for various industry verticals. Caveat emptor should be the guide here. Research the vendor and user comments before using one.

In addition to the WordPress software, there are a number of operational steps that the site administrator should take to prevent exploits. These include the following:

1. Hardening against brute force attacks on login using various username/password combinations is the first obvious step.
   • The use of strong passwords (not repeated across sites) for both administrators and users cannot be over emphasized. In the event that the password database is compromised, where passwords are stored as hashes, strong passwords protect better against dictionary attacks.
   • It is also be advisable to use two-factor authentication for sites which retain lots of personal identifiable information. WordPress offers a plugin for it. There are also others.
   • Use security plugins which allow you to change the address of your login page.  This will place your site outside of the attack scope of most bots scanning the Internet for WordPress sites to attack.
2. All access, whether for administrative purposes or for end user access, should be over SSL/TLS. Administrators should use sFTP or Secure Shell tunnels for file transfers, while end users should only be able to use HTTPS for site access.
3. The critical file wp-config.php, which contains access information about the site’s database, lives in a directory that is accessible from the internet. The “.php” extension means that it is run as a PHP application and not served as a web page. However, if this file were edited (or renamed) directly on the website so that the “.php” extension is missing or changed, it is possible for it to be served as text over the web. With minimal effort, such a file can reveal database credentials. Thus, important files should be edited offline and then uploaded over secure access.
4. Botnet scripts typically search for WordPress installations and then enumerate their versions using information found in the HTML metatags (e.g., a footer such as “Powered by WordPress”), a html file or a license.txt file. By hiding these, a superficial search by an attacker to find older installations of WordPress with their security holes will at least face a small barrier. Other files that enumerate the plugins and themes and their versions can also be hidden from scans. A scanning tool for finding such (and more) vulnerabilities is here. A suggestion for how to hide such files is here.
5. As a corollary to the above point, it is important to keep additional web applications (such as phpmyadmin, for administering databases) on the site to a minimum. If present, such applications should also be properly secured and updated to prevent vulnerabilities in these from being exploited to attack the WordPress site.
6. It’s best to complete a new installation of WordPress at one go. There is a vulnerability where attackers scan for the file /wp-admin/setup-config.php, which indicates that the WordPress setup is in progress but the account has not been configured. At this point, the attacker can take over the installation process and configure it to his preferences, including an admin account and access to a database. The site is then compromised, and potentially others at the same host. The hacker can also leave a backdoor shell program for remote code execution, which is hard to detect and remove.
7. Often “lazy” backups of a WordPress site are placed in sub-directories of the main installation and then forgotten. Hackers scan for old installations (typically of older and vulnerable versions) in public accessible sub-directories and can use the information in these as an entry point into the site. Backups should be stored elsewhere, or at least not in web-accessible, public directories.
8. Sites using “git” and “subversion” source code tools can inadvertently leave information behind in directories that they create. If publicly accessible, these can be exploited. Storing source code in GitHub or another publicly accessible repository can also be a serious vulnerability.  For example, passwords and security keys are often inappropriately checked into these public repositories.
9. Of course, obvious web site hygiene should also be followed – minimize or restrict the number of accounts with admin rights; follow the principle of least privilege; set a limit on login attempts; etc.

OWASP provides many links to resources that describe how to mitigate various WordPress vulnerabilities. Every site administrator should study and implement these. However, as with any shared solution, a hosted environment is as secure as its weakest link (or site, in this case). A poorly secured site in a shared environment can affect its neighbors. Use a dedicated solution whenever possible. If everyone followed these guidelines, the overall WordPress community would cease to be such a compelling target for hackers.

Read Next: For a deep dive, see our white paper: Securing WordPress

[1] Recall that the recent Equifax breach started with an unpatched Apache host. And this, too, at a company with large IT knowhow and assets.

[2] Apart from security of communications, lack of HTTPS access will affect your site rankings.