WordPress has 60% share among all Content Management Systems (Jan 2018, W3Techs), therefore taking WordPress security seriously is critical!

It’s WordPress they are after, no matter the website.

Even if you have a small, personal website on WordPress, hackers are interested in the underlying WordPress infrastructure, not your website or content.

In other words, bad guys are interested in exploiting the (big-enough) resources that power your (small) website.

So, even if you have a website that can turn visitors into customers, it must also be secure or else you may lose it all one day, and get in trouble too!

A remedy by a Canadian web hosting company. But does it work?

In a recent post, a local web hosting company suggests a particular treatment against such attacks. (In the spirit of competitive fairness, I cannot reveal the identity of this popular Canadian web hosting company.)

So, this company suggests to its clients the following remedy:

Not being found to begin with is the best defense. Here’s how. 

Your site should have a file called .htaccess. It is necessary for your site to run properly. WordPress will have created one for you during the installation of the program, but fills it only with the bare minimum. You need to edit this file adding the following lines to the top: 

SetEnvIfNoCase User-Agent “Firefox/40.1” tool
Deny from env=tool

Once this is added the bad guys are eluded. Your site is off the radar. 

Then, they go on to say that they charge $9.50 per website they host to apply the fix and $14.50 for websites they do not host.

Everyone who visits a website leaves behind a trace of how they accessed that website. For example, Chrome 41.0.2228.0 leaves behind the following trace:

Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

Some spam bots (automated programs hackers unleash first, to find vulnerable websites and WordPress installations) leave behind a fake trace. (By the way, this trace is called “user-agent”.)

Apparently, this particular web hosting company has suffered a massive attack from a particular spam bot with fake trace identification (“user-agent”) of “Firefox/40.1”. (Firefox never had such a version.)

All the recommended code does is block access to visits with that particular user-agent.

How to NOT secure your WordPress website

The methodology used by the web hosting company mentioned above is flawed on multiple fronts:

• The USER_AGENT directive used in the code comes directly from the visitor’s end (“the client side”), so it is easy to spoof / change.
• This method protects only against one very specific attack / spambot. How about all the rest? It is not fair to misguide clients that $9.50 will protect their website against (multiple) attacks, now and in the future.
• This “protection” does nothing to really protect the site from the myriads of dangers lurking in the shadows.
• The “patch” is applied on the actual website. The bad guys are already in the lobby, trying to get in the offices. If they flood the lobby, you still have a problem! They can flood your website with these false user-agent attacks, which will increase the burden on the underlying server and eventually cause huge problems to your website.

For better WordPress security

Security is like pealing an onion. Before you reach the core, you must go through various layers. Website security is the same way. Security and protection must be established on multiple layers:

• At the DNS level. (DNS=Domain Name Services). Before a signal even reaches your web server (where your web site resides on), it goes through the DNS level. Think of that level as a routing agent – all traffic first arrives at the DNS level, and from there, it is distributed accordingly to each final destination web server. If we catch the bad guys here, right from the get-go, we protect all our underlying infrastructure and solve a big problem at its genesis.
• At the web server level. Traffic is routed from DNS to the web server. This could be a local machine, a machine on the cloud, etc., and it could host one or thousands of websites. This is our secondary level of defense, and gives us the opportunity to stop the bad guys right before they actually hit our website.
• At the website level. If all other methods fail, the attacker is at our doorstep. There is myriad of different ways to penetrate our “fortress” from here. Some include attempts to break our Unix security using ssh and/or other access methods, break our WordPress login mechanism, SQL injection, Cross Site Scripting (XSS), malicious file uploads, Directory traversal, local file inclusions, and much-much more.

Rather than relying on its customers to secure their own WordPress installations, a decent website hosting company must include all these layers of security to its business website hosting offering. After all, the DNS and web server levels are not easily accessible to website owners. Even if they were, small business owners wouldn’t have the skills to apply security (properly) on those layers, and monitor performance in the long-run. (Please beware of Gimmicks of small business web hosting!)

Below you can see some screenshots from the various security layers we use on our infrastructure.

Security on the actual website, pass DNS and server security. A variety of attacks are blocked, including “Brute Force” attacks.

Photo by Jose Fontano