Mailing List Archive: Named listen addresses in VCL

Named listen addresses in VCL

Jul 4, 2016, 5:22 AM

Post #1 of 5 (1230 views)

Hi,

Inspired by stevedore names that (if I understood correctly) are now
properly checked at vcc time, I'd like to add names to -a options too
and introduce a new field in server too.

On the command line: -a [name=]address[:port][,proto]

In VCL: server.listen_address

In varnish-cli: listing listen addresses no longer a debug command

In varnishtest: s1_addr for the first one, s1_addr_$NAME for all

The point is to decouple IP/port addressing from the purpose, and for
example being able to distinguish secure traffic:

if (server.listen_address == "hitch") {
set req.http.X-Forwarded-Proto = "https";
}

The listen address name could be safely used on different environments
(prod, qa, dev...) without requiring a single change in the VCL code.

It would also be an alternative to ACLs when dealing with
administrative requests:

if (req.method == "PURGE") {
if (server.listen_address != "admin") {
return (synth(405));
}
return (purge);
}

Those snippets wouldn't compile on a varnishd instance not started
with named listen addresses "https" and "admin".

So far, all the work I've done on this feature is writing this email and
a bit of thinking, should I proceed further?

Best,
Dridi

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: Named listen addresses in VCL [ In reply to ]

phk at phk

Jul 4, 2016, 8:21 AM

Post #2 of 5 (1215 views)

Permalink

--------
In message <CABoVN9C6D2WwzYLaC0OzD146Gpi_oQ2Vt-G2oGg81Ko3tqrc_Q@mail.gmail.com>
, Dridi Boukelmoune writes:

>Inspired by stevedore names that (if I understood correctly) are now
>properly checked at vcc time, I'd like to add names to -a options too
>and introduce a new field in server too.

TCP/IP doesn't really work that way, in particular people forget that
packets may take different routes forth and back.

As best as I can tell, all your proposed uses would open you up to
rather trivial attacks, given a single compromised machine anywhere
in your DMZ.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: Named listen addresses in VCL [ In reply to ]

dridi at varni

Jul 4, 2016, 8:31 AM

Post #3 of 5 (1216 views)

Permalink

> TCP/IP doesn't really work that way, in particular people forget that
> packets may take different routes forth and back.
>
> As best as I can tell, all your proposed uses would open you up to
> rather trivial attacks, given a single compromised machine anywhere
> in your DMZ.

I don't understand, the use cases I'm suggesting are as "unsafe" as
relying on ACLs with either client.ip or server.ip.

I'm suggesting making the alternative to ACLs more convenient, by not
having to match addresses or extract the port number with std.port()
and relying on an abstract name instead.

You have the same problem if anything matching one of your ACLs
trusted address is compromised.

Dridi

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: Named listen addresses in VCL [ In reply to ]

phk at phk

Jul 4, 2016, 8:39 AM

Post #4 of 5 (1221 views)

Permalink

--------
In message <CABoVN9BRpGPUoQxO3k1s7FKWQNT0hwHe5ez9nSFNpj0o14+pcg@mail.gmail.com>
, Dridi Boukelmoune writes:

>I don't understand, the use cases I'm suggesting are as "unsafe" as
>relying on ACLs with either client.ip or server.ip.

With your suggestion, any traffic coming through a particular
listen address would be trusted, even if that traffic does not
have anything to do on that particular subnet.

>You have the same problem if anything matching one of your ACLs
>trusted address is compromised.

There is a big difference between hijacking the IP of a server in
use, which is likely to trigger alarms, and being able to attack
using any IP going in through a particular interface.

Neither is watertight, but I don't see "convenience" as a valid argument
for increasing the sizes of the holes.

--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev

Re: Named listen addresses in VCL [ In reply to ]

dridi at varni

Jul 4, 2016, 9:01 AM

Post #5 of 5 (1216 views)

Permalink

>>I don't understand, the use cases I'm suggesting are as "unsafe" as
>>relying on ACLs with either client.ip or server.ip.
>
> With your suggestion, any traffic coming through a particular
> listen address would be trusted, even if that traffic does not
> have anything to do on that particular subnet.

That's the point of providing the mechanism. If you trust your network
because you happen to have a trustworthy and competent team of network
engineers, why turn a networking problem into an application problem?

>>You have the same problem if anything matching one of your ACLs
>>trusted address is compromised.
>
> There is a big difference between hijacking the IP of a server in
> use, which is likely to trigger alarms, and being able to attack
> using any IP going in through a particular interface.

I don't see any difference between dealing with clunky VCL constructs
and using a label to achieve the same.

> Neither is watertight, but I don't see "convenience" as a valid argument
> for increasing the sizes of the holes.

The main goal is not *mere* convenience but actual decoupling between
the application layer and the networking nitty gritty. On my dev box
the "hitch" listen address might mean localhost:8888 while in
production the hitch server may be on a different host in front of a
Varnish cluster.

With named listen addresses I can write my VCL policy once and not
require changes between environments (dev, qa, prod...) instead of
using platform-dependent server.ip.

Dridi

_______________________________________________
varnish-dev mailing list
varnish-dev@varnish-cache.org
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev