Varnish Web Application Firewall launches

The Varnish Web Application Firewall (WAF) is finally available.

The WAF story

At its most basic, the WAF is a key tool that enables you to protect your backend from a traffic overload - regardless of whether that traffic is legitimate or an automated threat just aiming to take unsuspecting sites down by exploiting a vulnerability. Not all WAFs are created equally - and no one solution will protect you from everything. But in a sea of WAFs, many of them standalone legacy solutions that add complexity to the stack, don’t scale, are expensive, ineffective and mostly in place to pacify compliance departments, we thought there had to be a better way. As it stands, many companies deploy their WAFs at the extremes: if rules are configured too restrictively, a lot of legitimate traffic can end up being blocked, meaning that many companies, wanting to avoid false positives, leave themselves more vulnerable and open to attack than they should.

The real value of a firewall is not in its code but in its configuration - and configuring at the extremes (or failing to configure at all) makes a WAF useless. In building the Varnish WAF solution, we wanted to create something that would make it easy to implement existing ModSecurity rules directly into one’s setup - that is, why start from scratch when open source rules let you get access to the OWASP Core Rule Set through Varnish, which you may already be using - and if not, maybe you should be! We chose a proven tool to embed in Varnish because we could just reuse rules that already existed and that are maintained and updated regularly.

As we see it, there are basically three kinds of threats that WAFs address:

Well-known, immediately identifiable, which are easily defined and rejected by rules set for and applied by the WAF
New threats, usually bug exploitations. The bug will be fixed, but in the meantime, your site needs to hang tight until the fix is ready. WAF rules can protect you until the bug fix is deployed on your backend, and the rule can be removed.
Brand-new threats that aren’t even on the radar. These often happen when you’re running really old software. Keeping up with these problems is like a full-time job, and you need to add more and more WAF rules as they accumulate. Unfortunately, with each layer of rules you apply, you also increase the risk that you’re blocking legitimate traffic.

It’s with this in mind that we developed the Varnish WAF. You get the flexible benefits of VCL and can, for example, trigger vmod_waf on just a select subset of requests very easily using the Varnish Configuration Language (VCL), which gives you near-endless flexibility for setting and adjusting your own WAF security logic.

What the Varnish WAF does

Built as a VMOD (vmod_waf) in versatile VCL, the WAF lets you inspect your HTTP traffic to detect malicious requests at the edge of your network before they reach your website or application. The main purpose of vmod_waf is to keep your backend protected from predatory traffic, such as the kinds of threats found in the OWASP top ten critical web application security risks. Exactly what a WAF is meant to do.

And of course, because Varnish is all about HTTP, VMOD WAF is only needed for cache misses, so normal cache hits operate normally until it’s time to access the backend, when security measures kick in ensuring that you maintain the balance between performance and protection.