Why use a WAF? Because what doesn't kill you makes you stronger

Our helpdesk often encounters confusion about Web Application Firewalls, or WAFs - what they are, how to use them, and what issues they can potentially cause.

The bad news is that setting up your WAF properly can be a little painful. But never fear! We're here to help. And once you're up and running, a properly configured WAF can make your system stronger than ever.

Read on for help combatting any confusion around WAF basics, and the ins and outs of using one.

What is a WAF?

A Web Application Firewall (WAF) protects web based applications from common vulnerabilities. A WAF applies a set of rules to HTTP traffic and blocks actions it regards as suspicious. Loadbalancer.org uses the industry-standard ModSecurity for its WAF engine.

Listen below to an audio introduction to WAFs, from our very own Andrew Howe:

But I already have a web proxy - why would I want a WAF?

Having a web proxy will generally protect your clients, but what about your servers? Who or what will protect them from attacks, and who will ensure that you are PCI compliant?

This is where WAFs come in.

They’re designed to protect your servers by offering immediate remediation of security flaws for your existing, new and modified web applications. This assists you in maintaining a PCI compliant environment. WAFs also come in a range of formats - as a hardware device, an application, or a plugin (as per our WAF module on the Loadbalancer.org appliance).

Why can't I use a cloud-based WAF solution?

Good question - and one we get asked a lot. If you can use a cloud-based WAF, then please do! For the vast majority of our customers, it's actually our default recommendation.

Cloudflare, Incapsula or Sucuri will give you a simple, responsive and low-latency solution (low enough for most customers, anyway).

But if you need more detailed control, higher security and lower latency - or more likely, if your application is on the internal network and you can't use a cloud-based WAF - then we can help.

Does having a WAF make me PCI compliant?

No! An out-of-the-box WAF does not make you PCI compliant. Configuring the WAF to be in line with PCI DSS regulations will help with this. But that’s just the start of your PCI adventure - there are other things that need to be considered, such as:

• PCI assessments will check whether your network/environment passes as PCI compliant.
• Penetration tests will need to be performed, both outside and inside your network.
• Your web applications will need automated vulnerability scans.
• All public-facing web applications must be reviewed at least once per year and after any changes are made to your system.

What does it actually do?

A WAF monitors all incoming http traffic, then filters that traffic against a set of rules (OWASP core rule set, kindly provided by our friends at ModSecurity). It blocks what it deems as a malicious attack, such as SQL injections, cross-site scripting (XSS) file inclusion, and other security misconfigurations.

What’s the OWASP rule set?

This is a collection of rules that protect your web applications. They can be enabled and disabled on a rule-by-rule basis.

At Loadbalancer.org our WAF module uses the default vulnerability rule-set based on the ‘OWASP top 10’, which defines 10 areas of vulnerability that can affect web applications:

• Injection
• Broken Authentication and Session Management
• Cross-Site Scripting (XSS)
• Insecure Direct Object References
• Security Misconfiguration
• Sensitive Data Exposure
• Missing Function Level Access Control
• Cross-Site Request Forgery (CSRF)
• Using Components with Known Vulnerabilities
• Unvalidated Redirects and Forwards

Note: A description on each rule can be found in our admin guide here

Why don’t you offer regular WAF updates?

You may have noticed that while some vendors regularly announce updates for their WAF, we don’t. There’s a very good reason for this: updates don’t usually help! In fact, they may be the last thing you want in a WAF, as they’re likely to break applications without thorough testing.

We provide updates when they’re actually needed, and most importantly, we always ensure that they won’t affect existing customer installations.

A WAF doesn’t work the same way as antivirus software, so it doesn’t need to be constantly prepared for the latest threats, because it’s designed to pick up ‘styles’ of attack across a broad range of vulnerabilities. And WAFs do a really good job of this - which is why, leading on to our next point, they can be a little troublesome if they aren’t handled properly.

Are there any downsides?

Unfortunately, as with any security device, a WAF can be overprotective, leading to a plethora of false positives being highlighted within the security logs. These in turn end up breaking your web application by blocking client access to areas where it shouldn’t, leaving you with confused and disgruntled customers.

Web applications, for example, vary widely in terms of what’s acceptable input, so configuring a WAF requires more effort than network firewalls. That said, you may want to consider a WAF administrator to work with the application development team so they don’t inadvertently bring down any business critical applications.

There’s an upside to false positives, in that they can highlight a poorly designed site and be an indication of things that need to be updated to current web security standards. But if your site/web application is designed up to the recommended security standard and you are still suffering from false positives, you need to remove security from your WAF. This is where rule whitelisting and anomaly scoring come in.

Rule whitelisting

As I mentioned earlier, rules can be disabled on a per-rule basis, controlling what traffic is allowed through. However some may find the default rule set too restrictive and as such may be experiencing false positives so rule whitelisting is the way around this.

Anomaly scoring

This is the implementation of collaborative detection and delayed blocking. Individual rules can be run to maintain detection of vulnerabilities without applying any disruptive action against the suspect traffic. The rules then contribute to a transactional anomaly score collection, which in our case defaults to 5 for both inbound and outbound traffic. This is equivalent to the occurrence of one critically rated anomaly, meaning that an inbound anomaly score would need to exceed that threshold before being denied access.

We're here to help!

This process is like strategically punching some holes in the protective wall so that your app can actually work. It can be pretty painful - and because every app is unique, there’s no standard way of doing it.

But the good news is that a properly configured WAF is a useful WAF. And the even better news is that we’re here to help, every step of the way. While other vendors won’t help you configure a WAF unless you’ve purchased an expensive support package, Loadbalancer.org will help anyone who’s purchased our products to configure their WAF. (With Kemp, even if you do have that support package, you still have to pay extra per WAF incident!)

Unlike other vendors, we care enough to include a WAF as standard because we want it to be there if our customers ever need it. When it comes to configuring, we take the time to ask the right questions and get to the heart of what matters - because it’s our mission to ensure that our clients’ businesses are never interrupted.