Maintaining an Author Site: Security

Introduction

Do you figure your site is small, and hackers will go after the big targets rather than bother you? That’s what I thought, too–until my site was hacked.

The truth is that every site is a potential target. Here are some of reason hackers may attack your site:

  • to install malware, which could do anything from redirect your site traffic to install malware on the computers of your visitors;
  • to steal information (yet another reason for keeping visitor information stored onsite to a minimum);
  • to use the resources of your hosting provider for their own purposes;
  • to use the email account connected with your site to send out spam;
  • because they can.

For more information, check resources like this one. (The focus is on WordPress, but the reason hackers might attack are applicable to other kinds of websites.)

How Common Is Hacking?

(copyrighted by Rimom and licensed from www.shutterstock.com)

The internet is crawling with hacker-created bots looking for websites with vulnerabilities that can be exploited. During this week, Sitelock reports sixty-five attack attempts on my site so far. Today I’ve had 17 human visitors so far–and 1513 bots! (I should mention that not all bots represent hacker attempts. A large number of them are website crawlers from search providers like Google, Yahoo, and Bing. There are others that may be harmless as well. But my site gets visited by some malignant ones every single day.

Looking at the Wordfence statistics for my site is equally alarming. WF reports 872 attacks this month (but its firewall has only been out of learning mode for six days, which means that’s really only a week’s worth of data). Why are the stats so different? Sitelock catches attacks coming in through the domain name. Unfortunately, hackers can figure out what the actual IP address of the site is and attack that directly, bypassing Sitelock’s WAF (web application firewall). A bigger contributor to the difference is that Wordfence blocks not only actual attacks but any contact from IPs involved in recent attacks on other Wordfence sites. In such cases, the potential intruder might not yet have done anything that would have triggered an intervention by Sitelock’s WAF. Also, Wordfence counts failed login attempts in that total. Every day, several people and/or bots attempt to login using some variation of my name or  of admin to log into my site as me.

To put these statistics in perspective, a lot of these attacks wouldn’t succeed even without precautions. Most of them are probing for weaknesses rather than launching an actual attack.

Think of your site as a building and the hacking attempts as a horde of zombies surrounding the building. The zombies will feel along the wall. If they don’t find any way in, they will shuffle off to the next site. It’s only the ones that actually get in that are a real problem most of the time.

I went six and half years with no special security precautions before I was hacked. The problem is that vulnerabilities–gaps in your wall–can occur even if you do everything right. Using WordPress as an example, security flaws in the core files or in one or more plugins may not be spotted until someone exploits them. The problems are usually corrected quickly, but that doesn’t help the people whose sites have been attacked in the first place.

Safety Precautions Anyone Can Take

(copyrighted by jijomathaidesigners and licensed from www.shuttstetock.com)

These suggestions are hardly original to me. You can find them all over the internet. Basically, they are on the same level as being sure the doors and windows of your building are all appropriately secured.

  • Make the username that displays on your website different from the real username of your admin account. There are ways to get around this precaution, but it makes the process of guessing your username more difficult.
  • Use an extremely random password. That way it will be harder to guess as well. Make it long, include both uppercase and lowercase letters, as well as numbers and special characters. For extra security, change it from time to time.
  • Make sure that WordPress and all plugins are kept up to date. If a plugin appears to have been abandoned (no recent updates or efforts to verify compatibility with the most recent versions of WordPress), consider finding another one that functions similarly but that is supported. On a site with a fair number of plugins, you’ll probably see at least one update almost every day. Remember that a lot of these updates are designed to address newly discovered security threats, the kinds of holes in the wall that the ever-probing hands of the zombies are looking for.
  • Make sure you have a good backup solution in the event disaster, whether hacking or otherwise, corrupts your content. Most hosting providers do include some backup functions, but I’ve sometimes had trouble getting them to restore properly. For a long time, I’ve used Updraft Plus. The free version would be enough for most people. The paid version includes more varied storage options, automatic backups on occasions like WordPress updates and plugin updates, and easy site migration if you change hosts. (People wanting to migrate could save hours with the paid version.)

Those precautions were enough to keep me safe for years–but not indefinitely. I fell victim to a vulnerability in a plugin before I had the chance to update. These precautions are still good ideas, but more is needed.

Enhancing Safety Through CDN WAF

These days a CND (content distribution network) is desirable to make site speed relatively consistent across different geographical areas. CDNs can also incorporate caching and other technologies to improve site speed. However, a CDN can be important for security as well. Visitors (except hackers going straight for the server IP) will be arriving at your site through the CDN. That means it could be possible to stop the zombies at the border.

I’ve had experience with two CDNs, Cloudflare and Sitelock. This isn’t the place for a comprehensive comparison. In my own limited experience, both have advantages and disadvantages. Cloudflare seems to have a faster CDN and greater compatibility. For example, every onsite caching plugin I’ve tried has a built-in ability to work with Cloudflare; none of them play well with Sitelock. On the other hand, Sitelock has the advantage of being a more comprehensive solution because it also provides malware detection and removal for your site, something Cloudflare doesn’t. Support is good with both, though Sitelock gives you direct phone access even with its less expensive plans, while Cloudflare provides email only, or email and chat, except at the most expensive level. (In case you’ve never compared, a phone conversation can cover ground much faster than a chat. And if your site has just been destroyed by a malware attack, talking to a person is much more reassuring.)

(copyrighted by kentoh and licensed from www.shuttertock.com

Before I talk about pricing (as of May 2019), I should mention that you may be able to obtain cheaper prices–perhaps much cheaper–if you subscribe to one of these services through your hosting provider. (Cloudflare and Sitelock both partner quite often to provide plans at a lower price point than they would normally charge for a plan with comparable features.) There are also several other, less expensive alternatives. I’m only addressing the ones I’ve had experience with, but there is plenty of material on the internet about many others.

A Sitelock Secure Speed (midrange plan) is currently priced at $550 per year (or $50 per month). Secure Site (highest level plan) is $770 per year or $70 per month. The more expensive plan includes unlimited malware cleanup, continous scanning for malware, and automatic database cleaning; the less expensive one includes only one malware cleanup and a daily malware scan. (There is a also a $330/$30 plan that doesn’t include any free malware cleanup, block database attacks, or have blacklist removal (in the event your site gets blacklisted as a result of hacker activities).

It’s hard to equate Cloudflare prices with Sitelock’s because the plans aren’t really comparable. Aside from the free plan which provides a CDN but no firewall, Cloudflare offers one at $20 per month and one at $200 per month. (There is also an Enterprise Plan which requires you to call for a quote. I’m pretty sure indie authors aren’t going to be taking that one.) The difference is that the more expensive one is the one has chat support rather than just email, a 100% uptime guarantee, a more robust CDN, including more denial-of-service attack protection, and lots more customization options. (To get phone support, you need to go with the Enterprise Plan.)

It’s possible to separate Sitelock’s malware scan and removal service from its CDN/WAF, though I notice that’s not advertised on its website. You might want to investigate that if you like Sitelock’s malware benefits but want a different CDN.

Are these plans overkill for an indie author’s website? Maybe. For speed reasons, you’re probably going to want a CDN of some sort, though there are many other choices for that. How much extra security you add at the CDN level depends on how important your site is in your business plans and how much traffic it has. You can rely on Wordfence (see below), and see what happens. My own personal preference is for multiple levels of security, but I’m a little compulsive that way. And if disaster does strike, you can pay Sitelock or any one of several other companies for emergency website cleanup as needed even if you don’t subscribe to one of their plans. (However, if you get infected, it might be worth considering enhanced security at that point.)

Enhancing Safety Through Onsite WAF

(copyrighted by SAKARET TAWAKOON and licensed from www.shutterstock.com)

Again, there are many possible choices. I’m focusing on the one I’m familiar with–Wordfence–but there are alternatives.

For those of you shocked by the Sitelock and Cloudflare prices, Wordfence offers a free version, and its paid version is only $99 a year. For those prices, you aren’t going to get a CDN or phone support, and if your site is compromised, I’m tempted to think cleanup may take a little longer than with Sitelock. That said, what Wordfence does do is impressive. It may be enough to protect a site on its own. Even if you want to use a CDN with its own WAF, Wordfence offers features your CDN provider may not have. If you can afford it, a two-layer process with the CDN WAF at the border and Wordfence guarding all the doors and windows might be best alternative.

As I mentioned earlier, enterprising hackers can bypass an external WAF completely by going after your site’s server IP address instead of its domain name. I don’t know how common this is, but it’s certainly worth mentioning. Also, Wordfence leaves all customization options with you. Typically, CDN/WAF providers give you control of only limited customization, except in the most expensive plans. There are times when you might want to tinker yourself, especially if something on your site isn’t working right, rather than wait for support personnel to do it for you.

Wordfence’s WAF seems to work much like Sitelock’s, with the exception that they use different data sources. Wordfence accumulates data from all Wordfence sites so that it can proactively block entry to visitors from IP addresses that have been used for attacks before. In addition, Wordfence has copies of all the core files from all WordPress versions as well as all the free plugin files from WordPress.org. You can configure WF to check your files against its repository every time it does a malware scan. That means if someone has inserted code into a core file or plugin, even if it hasn’t done anything suspicious yet, WF will flag it and ask you what to do about it.

Like Sitelock, Wordfence does a daily malware scan, but it also allows you to scan whenever you want to. Something doesn’t look right? Scan right away and see.

Wordfence enables you to blacklist IPs yourself (but do that sparingly!) You can also whitelist IPs if you’re sure they’re false positives (do that carefully). If a suspicious process occurs while you’re onsite, WF notifies you and gives you the opportunity to whitelist the process if it’s something you initiated. The other day WF thought an ajax call made by WPBakery Page Builder was suspicious, but I was able to whitelist it and keep right on working.

Not always on your site? (I hope no one says no to this.) You can configure WF to send email notifications of what it’s up to and whether or not anything has gone wrong.

An especially neat feature is WF’s login security, now available in both free and paid versions. To prevent someone from logging in as an administrator even if the person somehow has your username and password, you can enable two-level authentication. To do this, you’ll need an app like Google Authenticator on your phone. Just use your phone to scan the QR code that WF will generate, and each time you input your name and password, you’ll be prompted for a six-digit code that Authenticator of a similar app will generate for you. WF also provides emergency codes if you lose access to your cell phone. Given how many false login attempts I get every single day, I’m especially happy with this feature.

Why Don’t Website Hosting Companies Take Care of Security?

(copyrighted by Alfa Photo and licensed from www.shutterstock.com)

Recently, a colleague raised this question in an author forum, so it seemed worthwhile to address it briefly. Many of us have the impression that our hosting company is taking care of site security. This is an impression based largely on wishful thinking.

Think of hosting companies as being like landlords. A landlord will rent you the apartment and provides some level of building security (like having a locking door or gate at the entry point of the complex). Some buildings may also include alarms, security cameras, or other measures as well. However, the landlord isn’t going to drop by and make sure the door to your apartment is locked. That part is your job.

In the same way, hosting companies take various precautions to protect the server hardware on which your site is being hosted. Some may offer security measures directed to the individual websites, but don’t assume they do anything beyond what is described in the hosting plan.  Often, site security needs can be addressed either through a more expensive hosting plan or through subscriptions brokered by the hosting company, as mentioned above. The one thing the hosting companies could do better is making clear to customers that some aspects of website security are the customer’s responsibility. It’s so easy to sign up for a hosting plan that many people, particularly first-time site owners, don’t raise security questions, and some hosting companies don’t emphasize the importance of security enough when a new customer first signs up. All too often, that customer won’t really think about security until a site has been hacked.

Final Recommendations

How to best meet the security needs of your site depends on your budget and on how important the site is to your overall business plan. While it’s important to have a platform you control (as opposed to a Facebook author page or an Amazon author page, for instance), authors may rely on their own websites to a greater or lesser degree. From what I can tell, the larger a fan base the author has, the more useful a website will be. (Websites of new or relatively unknown authors take a while to build up any real traffic.)

I’ve arranged the recommendations below by budget on the assumption that established authors with the potential for substantial website traffic would probably also have a larger budget. If you’re an outlier, you may want to adjust accordingly.

Almost No Budget: Wordfence free version

Small Budget: Wordfence paid version

Medium Budget: Wordfence paid version and low-level CDN WAF

Large Budget: Wordfence paid version and higher-level CDN WAF

(copyrighted by Phonlamai Photo and licensed from www.shutterstock.com)

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Don`t copy text!
Scroll to Top

To make this site work properly, we sometimes place small data files called cookies on your device. A few cookies are essential (help with proper site operation). Others improve site functionality. Click the appropriate button to accept or decline  the use of cookies. See our Privacy Policy for more information. You may change your cookie options any time on the privacy settings page or from the footer on any page or post. Please note that no site-based cookie blocking is 100% effective against third-party cookies. For complete protection on this and other sites, use your browser settings to block third-party cookies.