Varnish Administration Console

Setup and Security

The Super Fast Purger is a plugin to VAC that is capable of distributing requests to groups of Varnish Cache servers. The initial rationale behind the Super Fast Purger is to provide high performance purging, specific for Varnish Cache, and across data centers. For more information please take a look at Varnish Administration Console installation guide.

Setup

No additional steps required. The Super Fast Purger is an internal part of the VAC. Adding extra headers will be a matter of including them on the client-side and looking for them in the VCL (check the usage section).

Upon receiving an HTTP request, the Super Fast Purger will look at its X-Cache-Group header, and duplicate the request to all the members of that group. The responses’ headers are aggregated into one message and then sent back to the client.

Simple purge

An example of a basic vcl allowing purging on a Varnish server.

sub vcl_recv {
    if (req.method == "PURGE") {
        return (purge);
    }
}

We use a new verb, PURGE instead of GET to tell Varnish we want to actually purge. It is nice because the rest of the request can be an exact replica of a regular request, ensuring the vcl_hash for example, will react in the same way.

Security

Issuing purges across data centers is equivalent to remotely requesting content removal over a potentially unreliable medium. Within the Super Fast Purger VAC, the standard mechanism for checking the integrity of these purge requests is HMAC5. It is the preferred security mechanism for the Super Fast Purger when sending purges to Varnish Cache. HMAC provides a credible mechanism for ensuring data integrity and the authentication of the purge message. As an additional note HMAC is a cryptographic hash function requiring a secret key being shared between VAC and the respective Varnish Caches. The cryptographic strength lies within the size of the secret key, as well as the undisclosed makeup of the content being hashed. Brute force would be a common approach to uncover the secret key. However, unlike MD5 or SHA-1, HMAC is substantially less affected by collisions than their underlying hashing algorithms alone.

ACL filtering

However, you do not want all your users to be able to purge, so you can protect this operation using ACL, ie. ip ranges


acl local {
    "localhost";
    "192.168.1.0"/24; /* and everyone on the local network */
    !"192.168.1.23";  /* except for the dialing router */
}

sub vcl_recv {
    if (req.method == "PURGE" && client.ip ~ local) {
        return (purge);
    }
}

Note that X-group header is mandatory for the Super Fast Purger. It will be discussed in the Usage section.

HMAC filtering

Another way to filter who can purge, is to use the digest VMOD to build check an HMAC sent in the request. For example:

import digest;
sub vcl_recv {
    if (req.method == "PURGE") {
        if(digest.hmac_sha256("super_secret",
        req.http.host + req.url) != req.http.x-hmac) {
            return (synth(401, "Naughty user!"));
        } else {
            return (purge);
        }
        }
}

Here, we hash a private key (“super_secret”), the host header and the url of the request. If the header “X-HMAC” doesn’t match, the request is invalid (most probably, the issuer didn’t know the private key).

To create a request like that, we can use sha256sum

    HMAC=`echo -n "you.com/foo" | sha256 | awk '{print $1}'`
    curl you.com/foo -H "X-HMAC: $HMAC"

Beware: we need the -n, otherwise sha256 will hash the ending \n.