[Top][All Lists]

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

Re: Cfengine and multiple firewalls/security realms

From: Mark . Burgess
Subject: Re: Cfengine and multiple firewalls/security realms
Date: Tue, 22 Jun 2004 18:34:17 +0200 (MEST)

Hi - You can tie cfengine services to a specific interface using

You can turn off DNS verification of IP addresses using

SkipIdentify = ( true ) in cfagent

This means that you have to use a different way of assuring that the
keys are exchanged in a trusted manner.


On 22 Jun, Scott Omar Burch wrote:
> Hello,
> We have been working through testing Cfengine and noticed a few things 
> that are making deployment/operation difficult in our environment. The 
> following things have caused us trouble:
> 1) Authentication with keys appears to be tied to the primary network 
> interface of each server. Systems which sit behind firewalls in our 
> environment have multiple network interfaces. The primary network 
> interface is always considered the production interface. We always have 
> a secondary interface which is used for management operations (backups, 
> monitoring, etc.). If I have a host called snoopy then qfe0 would be 
> snoopy and qfe1 would be snoopy-mgmt. For this example snoopy sits 
> behind a firewall and the Cfengine policy server is on the other side of 
> the policy server. When we execute cfrun on the policy server we found 
> that no matter what we did we could not get authentication to work along 
> the management interface...we needed to open 5308 on the production 
> interface...Cfengine appears to always use the interface named snoopy. 
> (This problem is really a minor issue, but we would prefer to do all 
> Cfengine operations on the management interface..we did try binding the 
> agent/cfservd to managment..but that did not work because the keys 
> appear to only try to finalize the authentication along the production 
> interface)
> 2) Our bigger issue is how to have a policy server when there are 
> multiple security realms. We have multiple layers of firewalls. For 
> instance there are firewalls between application servers, web servers, 
> database servers, and authentication servers, as well as our internal 
> networks. (The servers in application/database/web/authentication layers 
>   are on external networks). The Cfengine policy server sits in a 
> special managment network that is on our internal network. Our general 
> policy is not to allow external machines to tunnel through our 
> firewalls. Source NAT and Destination NAT is in heavy use here, so 
> sometimes we have used NAT names for internal machines to allow access 
> to them from outside..also sometimes host routes along the management 
> interfaces solve some issues. How are others working around this type of 
> issue. We don't really want to have multiple policy servers..I 
> especially don't want multiple servers that require the use of external 
> tools to keep in sync (I have seen the discussions of having a policy 
> server inside/outside, etc...obviously this will not work here as we 
> have mutiple firewalls to contend with..we would need far more than 2 
> policy servers. It would be really nice if Cfengine had the option to 
> push rather than pull, that would allow it to function nicely in our 
> environment without opening holes through our firewalls. I am aware that 
> it is unlikely that Cfengine could be used to exploit the policy server, 
> but buffer overflows have and can be introduced in the code...and we are 
> not generally willing to take those risks (also having a general policy 
> to open ports into our internal network is not a good practice). We care 
> as much about the security of the servers that are clients as we do 
> about the policy server. What are your suggestions..and are there any 
> plans to implement the option of a Cfengine push/rather than pull.
> -Scott
> _______________________________________________
> Help-cfengine mailing list
> address@hidden

Work: +47 22453272            Email:  address@hidden
Fax : +47 22453205            WWW  :

reply via email to

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