Making WordPress Secure Takes Work Ignored By Most
Sucuri.net, well-recognized security professionals, has some great tips for WordPress security. Scroll down to the section “My Final Take-Aways” to see them listed in bullet point format. Their article on taking security to another level provides even more hardening steps. The single biggest technique to secure WordPress is to control access to WordPress at the server level. As Sucuri observes:
The user running WordPress (generally www-data or apache) should not have permissions to modify any file.
That protects you in case there is a vulnerability in any plugin, theme (or even in WordPress itself), since they won’t be able to modify anything.
But that’s a practice that’s not followed by most WordPress sites, and it can’t be followed if you’re on shared hosting. As a simple test, if you can update a plugin or WordPress itself from within your dashboard, you’re not following best practice to secure your WordPress site.
A review of the steps necessary to make WordPress secure leads to a few inescapable conclusions:
- most self-hosted WordPress sites aren’t hardened by nature and if they’re on shared hosting, they can’t be properly hardened;
- many won’t or can’t follow best practices when it comes to security;
- following best practices is hard work.
The hard work of hardening WordPress is one of the best arguments for our managed WordPress hosting.
Our Basics of WordPress Security
As we see it, implementing good WordPress security comes down to 4 things:
- Sticking to safe practices;
- Blocking bad actors;
- Avoiding security plugins whenever possible;
- Staying vigilant.
Stick To Safe Practices
At the most basic level, WordPress security requires sticking to safe practices. Here are just a few of the practices we follow:
- Controlling server permissions so WordPress core, plugins, and themes can’t modify themselves;
- Keeping WordPress core, plugins, and themes up to date;
- Accessing servers using secure tools such as SSH and avoiding insecure tools such as FTP; and
- Blocking creation of “generic” accounts that are magnets for bad actors.
Each of these practices takes more work compared to the easiest alternative. For example, it’s more work to access a server over SSH compared to FTP, but the payoff is much greater security. We’ll always adopt the measure that provides more security even if it requires more work.
Blocking Bad Actors
Our discussion of WordPress security would be very brief were it not for the bad actors on the internet. There are a lot of them, and their identities change by the hour. For that reason, we maintain a variety of systems to protect the security and reliability of our network and the sites we host. In general, our systems are designed to block or throttle those who have engaged in unwanted behavior in the past or whose activity is suspicious because of its nature. We attempt to block those who engage in:
- Trying to post comment spam;
- Trying to create a spam blog (splog);
- Trying to access URL’s which we consider to indicate malicious intent; or
- Repeated unsuccessful attempts to log in to our network or a site hosted by us.
We attempt to block or throttle crawlers or spiders that:
- Do not observe the restrictions placed in a
robots.txtfile; - Do not identify themselves via a user agent string;
- Make excessive page requests;
- Scrape content without our permission or the permission of a site hosted by us; or
- Make any page request without demonstrating to us a legitimate business purpose or offering a service to us or a site hosted by us.
Our efforts to block or throttle may target, among other things, specific IP addresses, IP ranges where we’ve observed excessive levels of the unwanted behavior, user agents, or hostnames. Because the identities of the bad actors on the internet are constantly changing, our efforts to block those actors change frequently, often several times each day.
No blocking system, including ours, is perfect in that it catches all bad actors without a single false positive. There is a chance that our systems on rare occasion will block a visitor that we do not really want to block. If that happens, we’re sorry for the inconvenience. As soon as we learn of the unwanted block, we’ll adjust our systems to reduce the chance that happens to that visitor in the future.
Avoiding Security Plugins Whenever Possible
For all of the security measures we adopt, we avoid security plugins whenever possible. We do that for a simple reason: we’ve tested a number of security plugins, and every one we’ve tested has a negative impact on performance that isn’t necessary to achieve the intended benefit.
That’s not a knock on those creating security plugins for WordPress. The performance impact comes from running security code in PHP, so it’s unavoidable. Further, many of these security plugins provide real benefits to those running on shared servers, who can’t make use of our better security practices and may not be able to switch – at least not immediately.
Stay Vigilant
If good WordPress security only required following some good practices and blocking potential troublemakers, we could stop there and pat ourselves on the back for a job well done. Unfortunately, our network would be secure for only a short period of time. The bad actors and their unwanted behavior are constantly changing. One example of a now widely recognized attack is search engine poisoning (SEP). It wasn’t that long ago that mention of SEP would have drawn blank stares.
To stay effective, security measures have to evolve as quickly as the threats they try to block. Otherwise, over time the blocks become less effective and at some point might become ineffective. Staying vigilant means keeping a watchful eye on discussions about WordPress security, including emerging attacks and ways to combat them.
Of course, we cannot and do not promise security that is impenetrable from attack. It would be impossible to keep that promise. We do promise a high degree of vigilance to minimize the risk from threats to our network and the sites we host.