RE: Listening on specific interfaces

[Ferguson, Steve]

Mark Burgess wrote:

> I'm not sure, but I suspect that there is a general misunderstanding
> here. When a server binds to an address, it binds to an address that
> it is *listening for traffic from*, not the address that it claims
> to be itself.

*Nods*  Yup.  And by default, if you have a machine that's attached to a DMZ
_and_ and internal network (which does not per force make it a firewall),
you might send all "management" traffic to it only over the internal
network.  You don't want cfservd to listen to anything coming from outside.
 
> Servers generally bind to 0.0.0.0 whih means, I'm accepting traffic
> from anyone in principle.

This is what folks are considering an issue.  They don't want to accept
traffic from anyone.

> In cfservd, there is access control after this, based on IP addresses
> that allows to to then reject traffic unconditionally before 
> a potential
> client has had any opportunity to send any data. This means that there
> is no possibility of exploiting any possible bug, not any advantage to
> binding to an individal client address.

Two cases:

1. There could at some point be a bug in the cfservd code that does this IP
check.  If that code had some sort of exploitable condition, you're sunk.
2. Someone might tunnel into your DMZ and present spoofed packets that look
like they're coming from an internal interface.  The hows and whys are
beyond the scope of this discussion, but it can and does happen.  The gist
of it is this: Say your DMZ network is 10.x and your internal network is
192.168.100.x.  An attacker can tunnel in and present packets to your DMZ
interface, claiming they come from 192.168.100.  cfservd will then happily
accept these packets.

Granted, it has other access controls, but this is a valid issue.
Application layer security can be compromised.  Combining application layer
with network layer security is a much stronger, more secure solution.

> So to everyone who has brought this up: I think this is a Red Herring.
> There is no advantage to binding to any other address.

Yes, there is, as outlined above.  cfengine may have its own internal access
controls, but the best security is always comprised of multiple layers, not
just application layer security.  And I'm not implying that there's anything
wrong with the code.  Someone might at some point compromise the cfengine
distribution.  It happened at ftp.gnu.org and they didn't detect it for
MONTHS.  Imagine a few dozen people updating cfengine to a new version, one
compromised to send out "Hey, hack me" alerts to the person who compromised
the source.  If these installations are configured in such a way that they
only listen to private networks, this information does a potential hacker no
good.  If cfengine is listening on all interfaces and someone has
compromised it to accept special commands prior to IP validation, they're
sunk.  Yes, there are MD5 sums, but if someone has compromised the
distribution point, they can probably replace the checksums as well.

Call me paranoid, but it's my job to be paranoid. :-)  While we're on the
subject of compromise, has anyone considered releasing cfengine
distributions with a PGP signature instead of or in addition to MD5
checksums?

> As for 
> listening on only a single interface -- I just don't know how to do that.

I'm no C programmer, but my understanding is that this can be done by
passing the appropriate argument to bind(2).

Is it worth the effort to code?  My understanding is that it shouldn't take
much, probably no more than a tweak to the configuration parser and an
argument passed to bind(2).  I'd do it myself if my C weren't so rusty.

Steve

--
Steve Ferguson
gedas USA, Inc.
Steve.Ferguson@gedas.com
http://www.gedasusa.com