[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: running cfengine across firewall

From: David Douthitt
Subject: Re: running cfengine across firewall
Date: Tue, 01 Feb 2005 00:16:18 -0600

On Mon, 2005-01-31 at 17:50, Tim Nelson wrote:
> On Mon, 31 Jan 2005 address@hidden wrote:

> > Ask youself *why* you don't want to open your firewall.
>       It's all a matter of exposure.  The firewall in this case was a 
> Smoothwall (Linux firewall) machine (slightly modified).  IIRC, it had no 
> open ports, so the only vulnerabilities in it, if I understand, would be 
> TCP/IP attacks (or possibly iptables) on Linux.  And if they allow 
> compromise, I'm in big trouble :).

Actually, there were iptables vulnerabilities found a while back.  But
recent kernels don't have that.

There - don't you feel better now?  ;-)

>       OTOH, if I port-forward the cfservd port (since the network behind 
> was NATed), then the exposure is the same as I originally had, *except* 
> that I also have to worry about cfservd (and bugs in the port-forwarding 
> mechanism).  If there's a cfservd hole, sure I have to rebuild some 
> external machines, but I can just rebuild the config from the internal 
> one.
>       The question is whether I think that there's more risk from 
> allowing access to the internal cfservd, or from the danger of updates not 
> getting pushed through properly.  The external cfengine machines, though, 
> could still get their config from the external cfengine server.
>       I agree, usually pull is better, but I prefer push going from a 
> (supposedly) higher security zone to a lower security zone.

I agree.  In the last setup I had, I used an internal cfengine server to
handle internal traffic, and made the occasional push to an external
server on the DMZ.

The biggest problem I had was that everything was different between the
internal and external servers, right down to the IP network and netmask
and router and everything.  Made it hard to segregate the files apart,
and made for a LOT of duplication in the conf files.

David Douthitt
UNIX System Administrator
Linux+, LPIC-1, RHCE
HP-UX, Unixware, Linux, FreeBSD, OpenBSD

reply via email to

[Prev in Thread] Current Thread [Next in Thread]