help-cfengine
[Top][All Lists]
Advanced

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

RE: cfengine, firewall and security


From: Elmar Kurgpold
Subject: RE: cfengine, firewall and security
Date: Thu, 9 Nov 2000 13:14:27 -0800 (PST)

I suggest bypassing cfengine to do the actual distribution, at least in
part.  I thought I heard mention of adding support for different transport
mechanisms as a future enhancement, but for the time being it's probably
better to be paranoid.

One possibility is to use a sort of bastion host solution.  Designate a
host outside the firewall as a cfengine repository, and push the updated
files from the inside server using ssh and rdist/rsync.  Then run cfd on
the bastion host and allow the other systems to connect to it as needed.
This keeps your inside server secure and allows you to tighten up access,
especially if you can shut everything else down on the bastion host.

Another way is to simply use the inside server to distribute to all the
outside systems with ssh etc. 

        ++Elmar


On Thu, 9 Nov 2000, Patrice GUERLAIS wrote:

> Thanks Mark, but it doesn't really solve my problem.
> 
> What I want to do is to keep all my reference files and configuration scripts 
> on a server protected behind the firewall, and then
> "push" all those things from that server to the clients. The clients can be 
> either protected behind the firewall themselves (and I
> have no problem to achieve that), or exposed outside the firewall (here is 
> the concern). The server must be very well protected,
> because it maintains the configuration of _all_ my systems (clients), and can 
> connect to any of them.
> 
> The problem is that I don't want somebody who breaks into an exposed client 
> to be able to connect to the server protected by the
> firewall. I must then close the firewall from outside towards inside, but I 
> can leave it open from inside towards outside. That's
> the exact contrary of your answer :-) , and your systems look rather exposed 
> :-(
> But as cfengine works on a pull rather push mode, I understand that it can't 
> be done, because the actual connection is initiated by
> the client, and not by the server, even if you use cfrun : as long as I 
> understood it, cfrun only asks the client to connect itself
> to the server and to synchronize itself. Therefore, the "request for sync" is 
> sent with cfrun from the server to the client (no
> firewalling problem), but the real stuff is done by the client, which 
> connects itself to the server. And then generates those damned
> firewalling concerns.
> 
> Am I right, or did I totally misunderstood ?
> 
> Thanks for your help
> Patrice
> 
> 
> > -----Message d'origine-----
> > De : help-cfengine-admin@gnu.org [mailto:help-cfengine-admin@gnu.org]De
> > la part de Mark R. Lindsey
> > Envoy? : jeudi 9 novembre 2000 13:56
> > ? : Patrice GUERLAIS; cfengine-help
> > Objet : Re: cfengine, firewall and security
> >
> >
> > : has anybody ever tried to use cfengine through a firewall without
> > : compromising security ? I mean, keep the reference server protected
> > : behind a firewall, and synchronize clients located both inside and
> > : outside the firewall.
> >
> > I have one cfengine server setup with firewall filtering; the protocol
> > is straightforward enough -- connections from any TCP port on the client
> > are made to port 5308 TCP on the cfd server, and no TCP connections are
> > made from the cfengine server back to the client.
> >
> > Just setup specific rules on the firewall to allow each external client
> > to connect to 5308 TCP on the internal cfengine server.
> >
> >
> >
> > _______________________________________________
> > Help-cfengine mailing list
> > Help-cfengine@gnu.org
> > http://mail.gnu.org/mailman/listinfo/help-cfengine
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org
> http://mail.gnu.org/mailman/listinfo/help-cfengine
> 

|  Elmar Kurgpold
|  Email: elmarkurgpold@yahoo.com





reply via email to

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