As you probably know, Varnish has always been a very secure piece of software but so far, that safety only applied to itself and therefore, a malicious request could still go through it and hurt your backend. But as a reverse-proxy (load-balancer, origin shield, etc.), Varnish is going to see everything the backend receives and sends, so there's a great opportunity here to sanitize the traffic before it reaches it.

It turns out that we have seized that opportunity and after a few months of live trialing with various customers, we have finally merged the Web Application Firewall (WAF) into the Varnish mainline! Read on to know what this means for you!

Protecting vulnerable backends against malicious requests, and against themselves

A web application firewall, like a lower-level firewall, allows the user to apply rules to restrict the traffic a piece of software/equipment can send and/or receive. In the WAF case, we are talking about HTTP traffic, and the firewall will be able to inspect both requests and responses to determine if any message is dangerous.

This is extremely useful when you have a service with security vulnerabilities, for example a CMS server that is susceptible to SQL injection. You know that the next release is going to fix the issue, but in the meantime, you can't leave that server with a big gaping hole in it, can you? This is where the Varnish WAF comes in: add a rule to block requests that look like an attack and they'll never reach your backend. You can wait for that security fix without worry.

Of course, what's true on the way in is also true on the way out; a configuration issue may be exposing PHP code, or maybe credit card information. Once again, the WAF can be instructed to block responses looking like unprocessed php code, or containing sensitive information.

Being thorough AND fast

If you've used Varnish before, you know that we believe in modularity, with small components doing one thing and doing it well. It should be no surprise that this WAF implementation reflects this philosophy.

The WAF features hinges on a VMOD, a small plugin that's activated only when needed. In this case, the VMOD is an integration layer to ModSecurity, an open-source and trusted WAF solution.

One thing to note is that because Varnish is a caching server, it has a definitive speed advantage over most WAF implementations and integrations. Typically, you can use a WAF in two ways:

• in-band: the actual traffic goes through the WAF.
• sidecar: the reverse proxy copies the relevant data to test, sends it to the WAF to get a OK/NOK response and decide what to do.

The sidecar option has been available to us for as long as we've have vmod_http; it was nice because we didn't have extra code to write/integrate, but as you can imagine, it's not very efficient, and the user needs to maintain an extra server on the side.

So we went for the second approach, plugging ModSecurity directly into Varnish. Now, the question that you are sure to have: how does this compare with using NGINX or Apache as reverse proxies, as they also have ModSecurity integration, and are also doing in-band analysis?

Varnish does it faster! Or rather, it does it more efficiently. The work is really being done by ModSecurity, and we can't go faster than that, but we can push less work to it. As I mentioned above, Varnish is a cache, and we want to protect the backend. So everything in cache has already been checked and we don't need to clear it again, so we don't call the WAF on it again, saving us a lot of time (and CPU power).

Same as bowling, there are rules

One reason we went for a proven solution is that the heart of a WAF beats by the rules you set to block or detect bad traffic. And in ModSecurity's case, there's a wealth of documentation available, as well as a complete set of rules covering the top attacks/issues that is ready to be deployed.

Since these rules can be imported as-is and that pretty much everything you'll read about them will also apply to your Varnish setup, getting started and tuning your own rules is going to be an easy job.

Security doesn't have to be hard

With this new component, Varnish takes an extra step to secure your environment without adding new services but leveraging the power of Varnish. By the way, I didn't tell you about it, but the configuration is pretty straightforward!

The code is ready and will be out next week with the next Varnish Enterprise release, so get ready!