Return to Blog
April 9, 2014
2 min read time

Locking down Varnish 4.0 - high security installations of Varnish

Per Buer

Varnish Cache 4.0 is just around the corner. We did a beta release a couple of weeks back and the feedback has been pretty good and I think the release will be out later this week. Anyway, there are a lot of changes in Varnish 4.0.  A couple of the changes in Varnish Cache 4.0 are security related ones, giving you the option to lock down a Varnish installation to make it ultra secure.

Varnish has two processes. One is the caching process, which typically runs as nobody. This one has very few priviliges as it talks to random people on the internet, which generally can be considered a dodgy bunch. The other is the master process. This one runs as root, as it has to do all sort of stuff. However, it generally doesn't talk to strangers. If it is enabled it will only talk to people knowing the secret. The people you trust.

Read-only parameters

With the 4.0 release of Varnish Cache you can now draw a clear line of where that trust ends. In 4.0 you can set certain parameters as read-only. This is done with the -r option. It allows you to specify a list of parameters that, once set, cannot be changed. If you want to run a tight ship I suggest setting the following parameters as read only:

  • cc_command
  • user
  • group
  • vcc_allow_inline_c

Setting these read only will make sure that anyone with access to the Varnish CLI doesn’t do anything insanely silly or evil. They are of course able to do things like loading a invalid VCL or stop the cache process, but the probability of them successfully executing an escalation of privileges attack is greatly reduced.

Inline C is now default disabled

There is a new parameter, vcc_allow_inline_c, which is off by default. Turning it on allows you to embed inline C code into VCL. Pretty powerful stuff, but not something you want a potential attacker to have access to. Embedding raw C in your VCL can to funny stuff to Varnish unless you know exactly what you are doing. Subtle errors in your C code can introduce memory leaks and corruption.

VMODs have access to request body

Since the VMODs have access to more data than before there will probably a couple of new security related VMODs that might show up sooner or later. Lasse Karstensen has written the policy VMOD that allow you to hand the request, including body, over to external program in order to validate it. We’ll probably see this being used to clean up POST requests, removing attempts at SQL injections and other nasty stuff.

All in all our security track record is pretty solid. With the 4.0 release I think we've added a couple of new security barriers, hopefully maintain our reputation as a pretty solid product. I would advise the various people packaging Varnish to consider setting the mentioned parameters read only and keeping inline C disabled. Power users can usually be relied upon to check the relevant documentation if they want to change these things.

Ready to learn more about Varnish Cache, VMODs and all things Varnish? Why not download the Varnish Book?

Download the book