Craig asks,
Our IT/IS Managed Services provider recommended that we reach out to you about enhancing our website security with a Web Application Firewall (WAF) or reverse proxy. Can you please advise and potentially assist us with the recommended enhancement?
Hi, Craig,
It sounds like a general concern to improve security on your site, to reduce the risk of certain attacks. When talking about security, the crucial thing to understand is that security is about managing risks, that no website is 100% secure, and that introducing new layers can actually increase your exposure, by creating more "attack surface". So while we're generally a very security-minded company, some of our recommendations may be counter-intuitive. We think more about managing the actual risks, taking into account any governance issues you might have.
So in our thinking, the main reason to implement a WAF is if you are required to by some standard you must comply with. Otherwise we don't think it's worth the trouble.
But why? A WAF can certainly block some dangerous attacks. Why shouldn't we want to be as secure as possible?
When evaluating risks, there are a bunch of rubrics defining the space. I like to evaluate risks as:
- What is the chance of an event happening?
- What is the consequence of a successful attack as is?
- What does it take to mitigate this risk?
- How much does the mitigation lower the chance of an attack?
- What other impact does the mitigation have?
What does a WAF do?
From CloudFlare's description,
A WAF or web application firewall helps protect web applications by filtering and monitoring HTTP traffic between a web application and the Internet. It typically protects web applications from attacks such as cross-site forgery, cross-site-scripting (XSS), file inclusion, and SQL injection, among others.
Sounds great, right? At its heart it's a "policy engine" that runs a bunch of rules on traffic to block known malicious attack patterns. The thing is, mitigating those attack patterns is exactly what a security update does, for your application (e.g. WordPress or Drupal). So most of the time, a WAF is blocking attacks that are entirely harmless, because your application isn't vulnerable to them, as long as you're on top of maintenance. And that's why you're on our protection plan already!
So the main reason to get a WAF is that sometimes it is easier/faster to add a new policy than it is to update your website. As long as someone is actively managing the WAF for active threats, it can reduce the time you are vulnerable. If your site is a target that an attacker is actively trying to bring down, this time period might be important enough that it's worthwhile to add a WAF. If not, the time period may not be significant enough, because the vulnerability will be fixed in the software before an attacker attacks your site.
Now, we do see a lot more successful attacks on WordPress than we do on Drupal, so if you're on WordPress, you should definitely be considering security risks. Which gets us to the next consideration: the impact of a successful attack.
What is the likelihood of an attack that a WAF can mitigate? Pretty much 100%. But the thing is, the rest of the environment and the app itself probably is not vulnerable anyway -- it's blocking a bunch of attacks that may already be unsuccessful.
The nature of attacks
Like risk rubrics, there are ways of categorizing attacks. OWASP maintains a list of the top 10 types of vulnerabilities that we pay attention to, and evaluate when doing security assessments. But the impact is a bit simpler to figure out for each one -- another security concept is "CIA":
- Confidentiality - if an attack is able to access confidential data -- personal information stored on the system, passwords, etc.
- Integrity - can an attack modify code in your system, make it untrustworthy
- Availability - does the attack make your system (or parts of it) go down
Availability
This is where the impact of an attack comes into consideration -- particularly the "Availability" part. A WAF may be redundant to the protections an environment or the app itself has for a particular attack -- except when it comes to volume, it might handle a "Denial of Service (DOS)" attack better. A light-weight layer in front of your app may be able to discard a lot of traffic that would otherwise need to be handled by your app, and if there's enough of this traffic it can certainly take you offline.
But getting taken offline by an attack doesn't have quite the same impact to your organization as a confidentiality breach. If your site goes down, people can't use it while it's down. If an attacker steals a database of personal information, you may have requirements to report the breach, legal exposure, and a much bigger hit to your reputation.
Confidentiality
In our thinking, the worst kind of breach is if it exposes sensitive data. Do you have any sensitive data in your website? For a lot of simple sites, the only thing that might be considered confidential are the passwords for site editors, which are already protected by cryptography and pretty secure as long as people are using strong passwords, even if an attacker gets your entire database.
If you have confidential customer data in your website, or things like credit card numbers that an attacker can use directly, or passwords for other systems, you definitely need all the protection you can get. But if you don't have any of that in your already-public website, you don't really have much exposure to an attack that gets your private data, except for possibly employee passwords -- which are easy to change if you have a breach. But those could lead to an attack on your website integrity.
Integrity
Some attacks can lead to an attacker modifying code or content on your website. If they are able to modify code on your site, all bets are off -- they could inject malicious code to collect anything your website processes, intercept passwords, mine bitcoins, whatever they want.
This is an area where your hosting can (and does) protect you far more than a WAF. With our hosting, as well as the vendors some of our clients use (in your case Pantheon), an attacker cannot change the code running in production. This means you cannot directly apply updates or install new modules or plugins on your production site -- the code is entirely read-only for the processes that make your site available to the web. So this does introduce a bit of friction and delay for rolling out updates -- we have an entirely different process to go through, because the websites cannot update themselves -- which means a huge range of dangerous attacks on your site are simply not possible.
This is the main reason we don't think a WAF is often worthwhile -- the hosting environment already blocks the main tactics mass attackers use to do anything dangerous.
However, if an attack allows an attacker to gain access to your database, or if they gain an administrator password, there is still damage they can do -- they can modify your content, make you look bad -- or send spam email through your account, or plant hidden content to game search engines, or add malicious code to hijack your site visitors' insecure browsers to form a botnet, or possibly even do a ransomware attack.
The first line of defense here is backups, and monitoring. We do daily integrity checks on all our production sites, and keep some historical backups up to over a year.
So in short, most of the dangerous attacks a WAF can prevent boil down to attacks we mitigate with the hosting environment, or vandalism. If you're getting vandalized, then perhaps a WAF can help -- but even then, it only blocks specific known attacks that will be patched in the app anyway, and there are always new ones.
What does it take to implement a WAF?
Active websites like WordPress and Drupal have several layers of services that need to run to give you a website. Both WP and Drupal run in a PHP runtime environment, usually behind a web server (common web servers include Apache, Nginx, Caddy lighttpd). A WAF is usually a policy engine that the web server filters all traffic through before sending it to the PHP engine. In many cases, people actually use them on another web server that sits in front of the webserver that talks to PHP -- this second web server is often called a "Load Balancer" or "Reverse Proxy". Load Balancers are light web servers that distribute traffic to other web servers so a site can handle a lot more traffic than it could if there was only one -- this is needed for the largest sites. A "reverse proxy" is really the same thing -- in both cases, it's just another webserver layer between your website and your visitor's browser.
Whenever you add a layer, you are adding "latency" -- making your site slower, and "attack surface" -- another system that an attacker can try to break into. Which also means you are adding cost -- more software that needs to get maintained, and if it's not promptly maintained, you might actually be making your overall security worse.
There's a certain amount of snake-oil sales going on here. It's much easier to manage a new dedicated web server layer with a defined WAF pre-configured and built in, than to build it into the one webserver you already have -- and it allows you to charge a lot more, because it's more hardware, software to manage, policies to keep up-to-date. A lot more cost for a tiny marginal reduction of risk.
There are sites that need this extra protection, don't get me wrong. It's just that for the vast majority of sites, it's entirely unnecessary.
We've saved several customers thousands of dollars per year by removing load balancers -- and as a result their sites got faster, and they actually went offline less. Save (a lot of) money, make your site faster, do better in Google, and have less downtime due to less things that need to get updated or might go down and take you offline. There is a slight increase in risk, but only in that you have more exposure to what is typically minor/easily recoverable.
So when should I add a WAF?
The vast majority of sites don't need a WAF. Here are a few cases where you might consider one.
1. Your site is slow/going offline due to a lot of attacks
A WAF might handle these attacks better, and offload pressure from your PHP server.
2. You have extremely confidential customer data on the site
If you have data protected by HIPAA, credit card data, or other extremely sensitive info that could put your entire organization at risk, you'll need to spend to reduce your exposure as much as possible. Just be aware that doing this properly while maintaining uptime and performance can make your costs go up by a factor of 10 (or more).
3. You're running WordPress or Drupal on a host that doesn't harden the production environment
If you can install plugins, modules, or themes in your production site, a successful attacker can do far greater damage. A WAF can help here - but I strongly recommend improving your hosting. Contact us and we can help!
4. You don't believe in maintenance, and aren't applying updates - or you're stuck on a legacy platform and cannot upgrade
A WAF is better than no maintenance at all. But really? WAFs only block certain attacks. If you can't or won't update your software to block new vulnerabilities as they are discovered, a WAF can at least block those attacks, which might be enough to keep you mostly safe.
Much better to upgrade your site and get on our protection plan to keep it up to date.
Add new comment