WordPress Ultimate Security Part 1: SSL & Firewalls

A while ago, I had written an article that outlined some steps to take in order to secure your WordPress website.

Given that WordPress now powers almost 35% of all websites on the ENTIRE Internet, I felt it was time to revisit this topic and perhaps identify some additional measures as well as recapping on the previously mentioned ones.

The topic will be spread out over a number of individual posts, as the subject warrants serious consideration and enough content real-estate for each point discussed to make sure the points hit home.

I’ll be starting out the series from the outside — in. That’s to say, we will cover all the possible levels of access to you site — from the public internet at DNS level, right through to file modifications on your website itself.

So, lets get started…..

1. DNS & Web Application Firewalls

Using a DNS provider such as Cloudflare helps protect your website before a would be attacker even gets close to your actual web server. The requests are filtered at the DNS level — and here ‘bad’ traffic can be stopped before it gets to your website. Whether it’s a DDoS attack or some attempt at brute force login, a DNS level firewall can be set up to identify repeated attempts from an IP or range of IP addresses — and block them.

Web Application Firewalls, or WAFs as they are commonly known, sit between your site and the internet to analyse all the incoming HTTP requests.

They can help protect against threats such as:

o Unvalidated input — Attackers tamper with HTTP request (including the url, headers and form fields) to bypass the site’s security mechanisms.

o Cross-site Scripting (XSS) — Attackers inject client-side scripts into web pages viewed by other users

o SQL injection — Malicious code is inserted or injected into a web entry field that allows attackers to compromise the application and underlying systems.

o Cookie poisoning — Modification of a cookie to gain unauthorized information

When a HTTP request contains malicious payload the WordPress firewall drops the connection.

The way a WordPress firewall detects malicious requests is similar to how malware software detects malware infections. They use a list of known attacks called signatures, and when the payload of a HTTP request matches a signature it means the request is malicious.

Before the request is actually processed by WordPress it is parsed by the WordPress firewall.

WordPress firewalls can come in a number of various types.

1. Firewall plugin for WordPress — this would sit on the same server as your WordPress installation and is in fact part of the WordPress instance. There are a number of these available — both free and paid. The downside with these is that if a hacker has gained access to your server — it is already too late to protect your site, since he or she will be able to disable or bypass the plugin at the server file level. DDoS attacks would also hit your server directly — as that is where the WAF is situated — therefore rendering the WAF irrelevant as the attack overwhelms your server’s resources.

2. Online — an external WAF working as a proxy for your site — your website’s traffic passes through it for filtering and then forwarded to your website. Users would have to pass through this firewall server in order to get to your site at all. This is inherently more secure, but obviously significantly more expensive. This also acts as a buffer to your website — enabling more effective protection against DDoS attacks.

These external WAFs do however have an inherent limitation. Your web server has to be accessible over the internet for the WAF to forward the traffic to your WordPress site. This means that everyone can still communicate directly with your web server if they know its IP address and potentially bypass the WAF entirely.

2. SSL

SSL stands for “secure sockets layer” and means a user’s connection to that website is secure and encrypted any data they enter is safely shared with that website.

It creates a secure connection between a visitor’s web browser and the server of the company they’re interacting with — designated with an extra ‘s’ after the http.
So the link would be formatted in such a manner: https://www.yoursite.com

Ok — there’s absolutely no excuse for not implementing this one — whether your website is WordPress based or not. Besides the fact that Google now punishes sites that are not encrypted —

https://www.forbes.com/sites/zakdoffman/2019/10/05/google-warns-users-about-new-chrome-updatesome-content-will-now-be-blocked/#2ae906af30a9

https://www.theverge.com/2018/2/8/16991254/chrome-not-secure-marked-http-encryption-ssl

Its just good practice and common sense to keep sensitive information that is sent across the Internet encrypted so that only the intended recipient can access it (personal information, credit cards etc.)

To ensure that the SSL certificate is trustworthy, it should obviously be signed by a recognized body — and today this is easier than ever, with free options such as Let’s Encrypt offering certificates as well as the well known commercial offerings of Comodo, RapidSSL and Thawte.

In the next article, I will examine ways to protect the server itself at an O/S level as well as talking about good back up hygiene.

For more information and advice on how to protect your online content investments, contact us at [email protected] or visit our website at https://www.leadmetrix.net

Leave a comment