A Hotel Hacker Drove Me To Lock Up My Website!
Website security is probably not among your top ten concerns. But it’s high on my list today, and will probably be on your radar during the next year.
Why will you care about website security? For two important reasons, one visible and one less-than-visible. These are discussed in the following two sections.
Warning: This is a long blog. If you just want a quick summary of how to achieve website security, see the bullets below. Each summary statement links to a later discussion:
How To Get & Keep WordPress Website Security (Executive Summary)
- Basic Protection: A strong security plugin; random names for sign-in page and data files; “strong” random sequences for user names and passwords.
- Security Certificate: Buy a security certificate that’s appropriate for your website, and ask the provider to help you install it.
- Add Malware Protection: Install an anti-malware plugin on your website, and use it! But you also need to scan your site from outside the WordPress system.
- Change Internal Links: Convert every internal link in your website from HTTP: to HTTPS:.
- Change External Links: Make every external link in your website secure. If it opens a new tab or page (target=”_blank”) the link must also contain the attribute ref=”noopener”.
- Firewall Settings: Use high security settings in your firewall. Examples are given in this section of the post.
- Patch WordPress Built-In Weaknesses: WordPress has inherent weaknesses that you must protect. Periodically Re-Qualify and weed out defunct plugins. Note that this may entail considerable work on your part.
How Your Browser Announces Website Security When You Visit a Site
Already, your browser’s address line reveals when you visit a secure website. The kind of label depends on which browser you use. You can see the differences by visiting three types of websites and looking at your browser’s headers:
- https://honokeana.net has an “Extended Security Certificate.” This designation is the most expensive and tedious form of website security. It requires you to hire a CPA or attorney licensed in your state. That person then has to verify that you own your website and have a business with a confirmed physical site and regular staff hours.
- https://maui114.net has a regular Security Certificate. This designation provides the same encryption protection but does not require a CPA-certified public physical presence.
- http://hcaoao.com has no website security certification. Don’t worry, it won’t ask you for any personal information! Your communications with such a website are not encrypted. If you’re using a public wi-fi network, a hacker could see the pages that you visit. You would not want to enter important personal data into forms on such a website.
In general, an address with website security shows a padlock, either gray or green depending on the level of security. An insecure website shows no padlock and will not show “https” in the address line. On some browsers, there will also be a warning, “Not Secure.” Even if your website is secure, if your web page displays information from an insecure website, the browser will show a warning to the visitor.
The Visible Reason To Care About Website Security
Even two years ago, these differences were not so evident. However, each of the browser development teams is adding more and more warnings to steer the public away from non-secure websites. This is a key reason that many more websites have website security certificates today – including mine! – than even one or two years ago.
Soon, the warnings will be so evident and so scary that many people will simply not dare to visit an insecure website. These notices of course are being provided to protect the general public. Although they also benefit the companies that receive fees for issuing website security certificates!
The Less-Visible Reason To Care About Website Security
Here comes the less-visible reason that website security will matter to you:
Beginning in 2014, the Google search engine started to give higher search placement to secure websites than to insecure ones. The difference was minor to begin with, but Google shows every evidence that they will give more and more weight to website security. Other search providers such as Bing and Yahoo will probably follow suit.
Google owns the Chrome Browser, and the way it’s treating search queries is quite consistent with the way that Chrome is stepping up its support of website security.
Eventually, insecure websites will become a minority. By then, when you perform an Internet search the search engine will preferentially guide you to secure websites. Many non-secure websites will be forced out of business. The remainder will swallow hard and pay the price – both financial and labor-wise – of adding website security.
The Hotel Hacker Attack On My Websites
Last week’s blog post (A Hotel Hacker Is Out To Steal Your Identity!) told how several weeks ago a hotel hacker (to my best belief) stole both credit card and website credentials from me, then tried to use them to my detriment. That blog focused on identity protection: guidelines for me, and perhaps for you too. Today’s blog talks about website security: how the hacker tried to take control of my websites, and what I had to do to defend myself.
In summary, while traveling I performed website maintenance on my personal websites artchester.net and maui114.net. At that moment, both of these were non-secure websites, with http: addresses. Because the hotel wi-fi was insecure, the hacker could eavesdrop on my work. The hacker could collect most but not all of the data required to take control of my websites.
The hacker started by guessing my username. He or she tried to sign in as Art, Chester, artchester, admin, or using the website address as username. The hacker came to my website using an Internet address in a foreign country. He used the same address only twice, then changed to another address in a different country. Why might that be? Perhaps because some website owners think “three strikes you’re out.” Therefore, they set up their websites to lock out all sign-ins after three failures from the same Internet address.
When none of the guesses worked, the hacker studied the stolen screenshots and found my random, unguessable user name. He was still trying to guess my unguessable password when I was able to log in from a secure network and change all the sign-in parameters. By this time the hacker had made 41 attempts to break into my websites.
Website Security Basic – My Existing Protections
I was not a total babe in the woods as regards website security. My websites use a strong security plugin which gives my sign-in page and my data files unguessable addresses. I changed my user name from the default “admin” to a random sequence of letters and numbers. And I used different, strong passwords for each website.
However, I did not count on the likelihood of a hotel hacker figuratively looking over my shoulder at an otherwise reputable hotel. Nor did I expect the hacker to have such persistent friends with Internet addresses scattered all over the world, with which to cover their tracks.
As noted last week, the hotel hacker did not appear to intercept any information about the website that I co-manage, honokeana.net. Thank goodness! I had just finished making that a secure website prior to taking my vacation trip into hacker country. And its website security appeared to have worked – although I changed its sign-in password just to be on the safe side.
Website Security II – I Convert To HTTPS
Naturally, I converted my personal websites to HTTPS security as soon as I returned from my road trip. Since I’m not selling goods and asking for personal information, I didn’t need full-up Extended Validation. A regular Security Certificate gave me the website protection I needed.
However, converting to HTTPS involves a lot more than paying the fee. Yes, I wanted the website to “look” secure with its padlock in the browser window. But I also wanted it to “be” secure, meaning down through all levels of the file structure. This was necessary to protect it from hacking, and also necessary so that search engines would grant me “secure” status.
I have discovered no handbook that tells all the steps that you have to go through to achieve a secure website. You will find that information scattered far and wide, each article giving a bit more. The following material summarizes the steps I have taken myself:
Buy a Security Certificate for the Websites
This was the easiest step, apart from the cost. For $272 I obtained a two-year security certificate covering both artchester.net and maui114.net, plus the address evanolsson.com, under which the other two domains are hosted.
My hosting provider GoDaddy.com changed the address parameters within their system. They also added code to my “.htaccess” files, directing all incoming traffic from http: (insecure) to https: (secure).
I had to make several phone calls to their customer support before the certificate was properly installed to cover all these web addresses, plus the “www” versions of the addresses. Fortunately, GoDaddy has excellent 24/7 phone support. It’s staffed by techs, generally based in Arizona, who “speak-a my language.”
Add Malware Protection to the Websites
When I added the security certificate, GoDaddy offered to move me to a newer hosting plan. This one used new software and newer servers, promising more speed and less downtime. I understand up-selling, but I didn’t mind because the new plan was less expensive than my old one. After taking credit for stopping the old plan, I wound up with $52 “store credit.”
It’s just as well that I accepted the new hosting plan. Before GoDaddy moved me to their new servers, they wanted to ensure that my files didn’t contain malware (“malicious software”) that might contaminate their operations. They performed a malware scan and sent me a list of 17 files that contained malware!
Six files were contained in out-of-date WordPress files in achester.com and maui114.com, sites I am not currently using. But the rest were in artchester.net, which to my knowledge has never been hacked! I was mortified and alarmed.
I added an anti-malware plugin to scan my websites. Sure enough, it found four of the bad files GoDaddy had fingered plus one more. But it missed all the bad files that were stored remotely in the WordPress data base.
Obviously I needed stronger medicine, so I signed up for a GoDaddy security plan providing malware scan and repair encompassing all my files, including the remote ones. The new plan scans everything daily and promises to fix any problems within 12 hours. (A more expensive plan provides fixes within 30 minutes, for commercial websites that accept payments.)
A little paranoia breeds more of the same. Although it appeared that the hackers had not penetrated my sites, obviously somehow malware had crept in. The anti-malware plugin and the GoDaddy plan together provided “belt and suspenders” reassurance.
Change Internal Links in Every Blog Post
Was I done converting to security? Not nearly!
Every article that I write contains a number of web links. The internal links go to related articles on either of my websites. The external links go to original sources, or to well-written and reliable secondary sources that can give further information.
Naturally, all of the internal links on my more than 250 blog posts had insecure addresses, starting with http:. You might think, “Hey, no problem. A guest clicks that link, your system re-directs them to the corresponding secure https: page.”
Alas, not so. What if a guest visits my website using an insecure network and clicks an http: link while a hacker is eavesdropping? The hacker can grab the insecure address and re-direct the guest to another address before my system has time to make it secure. The other address might have a phishing page like the one I encountered, offering me to update my Adobe Flash Player but actually offering a virus download.
This may seem like a low-probability problem to you, but as I said, paranoia breeds more paranoia. If my websites are to be secure for the visitor, all my internal links must be explicitly written as https:.
Change External Links in Every Blog Post
As noted above, my blog posts also contain external links. In fact, over 5,600 of them at this time!
My external links are written so as to open in a new tab or browser window. (They contain the command target=”_blank”.) This is so that you can read my blog and click on a link for more information without losing your place in what you were reading.
A couple of years ago WordPress discovered that external links in its blogs were insecure, because a hacker could use them to display spoof pages in a visitor’s browser. The solution WordPress adopted in version 4.7.4 was to add the attribute ref=”noopener” to all links, which prevents an attacker from reaching into your brower when you click an external link. This addition has been automatic since April 2017.
Unfortunately, the WordPress security fix is not retroactive. WordPress provides it whenever I update an existing blog, but otherwise my older blogs wouldn’t have this protection. Thus I had to edit every one of my blogs to add the “noopener” command to each of the 5,000-plus external links. (At the same time, I added “nofollow” to most links, for search engine reasons.)
Beef Up the Firewall
As mentioned above, to combat malware I signed up for a GoDaddy security plan. That plan includes a firewall to protect my websites from some kinds of intrusion.
As I was researching website security, I found that a firewall doesn’t do much good if you don’t activate many of its options. Whereupon I turned on the following security options in the firewall I had purchased:
– Stop unfiltered HTML from being sent to your site.
– Stop upload of PHP or executable content.
– Block anonymous proxies and sign-ons from China, Russia, Turkey (the home bases for very many hackers).
– Aggressively filter against “bots.”
– Require passing the web address via a secure link.
– Detect and block evasive intrusions.
– Block certain intrusions relying on injecting software code (X-XSS-Protection, X-Frame-Options, X-Content-Type-Options).
– Enforce Strict-Transport-Security including Subdomains.
– Redirect all traffic to HTTPS Only site.
The Impracticality of Perfect Security
There’s one more step that security experts advise, but which poses problems. They suggest installing a Content Security Policy which imposes restrictions far beyond those above.
Unfortunately, typical WordPress sites, including those that I manage, rely on external sources for fonts, stylesheets and software. A highly restrictive CSP may add security, but it’s likely to “break” the website by disabling its software. To fix the website, you may need to import external data and build it into the web pages. But then the search engines will give you a poor grade because your pages respond too slowly to a visitor!
In summary, here is the security dilemma that many website owners, including me, face:
- We want a great-looking website for a reasonable amount of effort.
- To build a great website efficiently we use WordPress software, plus its Themes and Plugins. These tools give us great design power, but also complicate the software.
- The more complicated the software, the more security gaps are likely.
- Attempts to beef up security may louse up the website, or make it respond slowly, or both.
- Take your choice. You can have only two of the following three desires:
Website Security III – Counter the Built-In Weaknesses of WordPress
WordPress is a truly outstanding content management system (CMS) for websites. I have previously (in 2013 and 2015) sung its praises as a practical, flexible, powerful way to build and maintain a website.
The world seems to agree. Today, 30% of the world’s websites use WordPress. And among all websites that use a content management system, 60% employ WordPress.
However, I have come to realize that using the world’s most popular, best item in any category may also bring with it some problems. Consider the following:
WordPress Is a Rewarding Target for Hackers
Do you remember when we first started hearing about computer viruses? At that time, viruses mainly targeted Microsoft Windows. Apple’s Mac had such a small market share that the hackers didn’t bother with it. Or perhaps the hackers were using Apple computers and were fond of them!
Today of course, viruses are a problem for all the operating systems. But the point still holds, that a technology with large market share is simply a bigger target for bad actors.
WordPress Software Is Easy To Study
WordPress uses open source software, available to everyone. As a result, thousands of volunteers willingly contribute to improvements, and to finding and plugging security gaps. However, there are also thousands of well-paid, well-equipped hackers looking for and exploiting those same security gaps!
WordPress Relies On Many Plugins From Many Sources
WordPress is certainly a great tool, as is, for building a website. However, it lacks many features that website owners want or need. Among these are tables to display data, slideshows for images, ways for visitors to subscribe to the website, visitor contact forms, site backup, sitemaps to guide search engines and site backup. In addition, basic WordPress lacks security features such as spam filters, bot blocking, malware scanning, lockout of invalid users and file renaming.
The features missing from WordPress are supplied by a huge army of software developers. They create “Themes” for overall website formatting and “Plugins,” basically apps, to add needed functions. Because there are so many developers, it’s inevitable that some of them will be less skilled or less conscientious than others. If hackers can find a security flaw in a popular plugin, they can insert malware that can contaminate every website that uses the plugin.
In every complex software system, security gaps abound. Complicated software is inherently a “leaky boat.”
Each of my websites uses a number of plugins – between 24 and 33 at this time. The plugins are so frequently updated that virtually every day I have to update one or more of them. And the update description not only mentions improved features, but also security gaps that are being plugged.
Many website owners are casual about updates, updating their plugins only monthly or not at all. They are taking a significant risk in so doing. After all, even my obsessive site maintenance did not prevent all the malware revealed in my site scans!
The Incompleteness Theorem for WordPress
I mentioned above that I am using both an anti-malware plugin and a malware scanning service from GoDaddy. Why wouldn’t the plugin be sufficient, without the extra expense of an outside service?
I will draw an analogy to Gödel’s incompleteness theorems in mathematics. These theorems state (roughly) that no set of axioms about a field is able to prove all statements that are true within that field. Moreover, no mathematical system is able to demonstrate its own consistency.
Similarly, software within a WordPress website cannot fully analyze and protect that website. After all, I may (and do) have an anti-malware plugin. But how do I know that the plugin itself has not been corrupted by malware, either directly or by the action of some other plugin? How do I know that it can access all the data bases that I rely on?
As the Romans said, “quis custodiet ipsos custodes?” It’s necessary to reach outside the WordPress system – in my case, to the website host provider – to assure that the website is safe.
WordPress Does Not Notify Its User of Potential Risks
It was only while recovering from the hacker attack that I became aware of a serious drawback to the otherwise praiseworthy WordPress universe. WordPress has no mechanism to warn the website owner that his or her website may be seriously at risk due to bad plugins!
Here’s how it came about. When a plugin I’m using issues a new update, WordPress flashes a red symbol on the control panel of my websites. And I immediately update that plugin.
However, what about the plugins that have not been updated? How do I know they’re OK?
When I shop for a new plugin, I search the huge data base of plugins using keywords to find the one with the functionality I seek. At that time, WordPress tells me the user rating, how recently the plugin was updated, how many websites are using it, and whether it is compatible with the most recent version of WordPress. For example, a good plugin would have a user rating of at least 4.5 stars, have been updated within the last month or two, have at least 100,000 active users and be compatible with the latest WordPress. I can also read the description, see screenshots, read the FAQ page and, most importantly, read the reviews.
However, once I install the plugin, I’m on my own. WordPress never tells me if the plugin developer has abandoned it, or if recent reviews point to a serious problem. Moreover, even if WordPress deletes the plugin from its catalog, it takes no steps to inform users of that plugin that it is no longer safe for use.
Re-Qualify and Weed Out Defunct Plugins!
You can see the problem clearly, and so did I. So I compiled a list of all the plugins loaded in my various websites – 73 of them. For each one, I looked up the WordPress information as if I were installing the plugin for the first time. Essentially, I re-qualified it for my use. I took note of plugins not compatible with today’s WordPress, plugins that had not been updated for a year or more, and those with seriously negative recent reviews.
Many Plugins Did Not Pass Muster
The result were shocking. I found more than two dozen plugins that were candidates for deletion, for various reasons:
- Many of them had not been updated for more than a year. They had not been tested with the current version of WordPress.
- Some plugins I had loaded into my websites but never activated for one reason or another. The mere presence of the plugin was adding to my security risk, so clearly I needed to get rid of it.
- One plugin two years out of date (Buy This Book) recommended replacement with another plugin (Author Showcase). However, the latter plugin itself was one year out of date!
- One plugin (Easy Table) had been discontinued by WordPress. The plugin’s web page went to a phishing page set up by a hacker!
- One plugin (Websimon Tables) had been dropped by WordPress. The author’s web page said that WordPress had found security risks in his plugin and for that reason pulled it from their catalog. However, the author did not plan to fix the plugin because he was too busy! And I wonder why WordPress did not inform me, one of the plugin’s users?
- One plugin (Post Modified Date) was a year out of date but I really want and need that plugin. It adds the revision date to all my updated blogs. I e-mailed the author asking when he plans to update it. He replied, promising an update soon. And he delivered the goods just a few days after I first published this post.
Be Prepared For Additional Work
Deleting bad or unused plugins was not the end of the story. I could not tolerate the risks posed by Websimon Tables, given the WordPress actions and the author’s comments. So I needed another table plugin.
Unfortunately, a good table plugin simply does not exist in WordPress at this time. I found four candidates that might work, but two of them had serious drawbacks based on user reviews. One of the others distorted the table layout in all displays. The other one looked fine on a desktop display but gave an unreadable table on a smartphone.
My most critical need was to replace the rate table at https://honokeana.net/rental-rates/. It’s a big table, with 7 columns and currently 16 rows. It contains hot links to each of the rental condos. Everything in the table needs to be readable and clickable (by people with fat fingers) on the smallest smartphone display. And our rental business depends on this table being not only legible, but easy to use!
I finally abandoned plugins altogether. I created two versions of the table – a full sized one for large screen displays and a compact one for mobile devices. Each version was rendered directly in HTML code, which I achieved by using Microsoft Word plus two different versions of Excel. This took me over a week of steady work.
A Less Than Perfect Replacement For a Bad Plugin
This solution is not perfect. The tables display with too large a gap above and below them, and I have not found a way to shrink that gap. However, they are functional for now, and Google is not tweaking me for presenting an unacceptable user interface. I hope that my co-webmaster Phil Wolken will help me correct that remaining flaw.
The point I am making is that when a plugin goes bad, finding an acceptable substitute may require a great deal of work!