Operating cfengine through a firewall

Relevant classes: any Some users want to use cfengine remote copying through a firewall, in particular to update the cfengine policy. Firewalls are often shrouded in myth and mystery. It is very important to see the firewall security model together with the cfengine security model. Often the firewall administrator is not the same as the cfengine administrator, so it is important to understand the consequences of one's security strategy. Any piece of software that traverses a firewall can, in principle, weaken the security of the barrier. The set-up we shall describe is illustrated in the figure. We label the regions inside and outside of the firewall as the "secure area" and "De Militarized Zone" for convenience. It should be understood that the areas inside a firewall is not necessarily secure in any sense of the word unless the firewall configuration is understood together with all other security measures. Our problem is to copy files from the "secure" source machine to hosts outside, in order to send them their configuration policies. There are two ways of getting files through the firewall. An automated cfengine solution (pull from inside to outside). A manual push to the other side of the wall (push from inside to outside). One of the main aims of a firewall is to prevent hosts outside the "secure area" from opening connections to hosts in the secure area. If we want cfagents on the outside of the firewall to receive updated policies from the inside of the firewall, information has to traverse the firewall. Push and pull are different in this regard: a push requires only an outgoing connection from a trusted source to an untrusted destination; a "pull" necessesarily requires an untrusted connection being opened to a trusted server within the secure area. For some administrators this is simply wrong, but it is important to evaluate the risk. What do these words mean and how much risk is involved? Some caveats: It is not the aim og this note to advocate any one method of update. You must decide for yourself. The aim here is only to evaluate the security implications. Exporting data from the secure area to the DMZ automatically downgrades the privacy of the information. The cfengine security model assumes that the security of every host will be taken seriously. A firewall should never be used as a substitute for host security. Push - update outside of cfengine Cfengine cannot push files. By design, cfengine's security model is about protecting each individual host. A firewall breaks this model because it says that some hosts (not us) are more important than us. Copying to a policy mirror is the recommended way to copy files, so that normal cfengine pull methods can be used by all other hosts in the DMZ, using the mirror as source. The policy mirror host should be as secure as possible, with preferably few or no other services running that might allow an attacker to compromize it. Any method of pushing a new version of policy can be chosen in principle: CVS, FTP, RSYNC, SCP. The security disadvantage of the push method is that it opens a port on the policy-mirror, and therefore the same vulnerability is now present on the mirror. Since this is not a cfengine port, no guarantees can be made about what access attackers will get to the mirror host. Pull - the cfengine way To distribute files to hosts that are outside the firewall it is best to create a policy-mirror. This is important because it means that you only need to open a single tunnel through the firewall from the policy-mirror to the cfengine service port on the source machine. Connections from any other host will still be denied by the firewall. This minimizes the risk of any problems caused by attackers. To open a tunnel through the firewall, you need to alter the filter rules. A firewall blocks access at the network level. Configuring the opening of a single port is straightforward. The rules look something like this -- but make sure you seek the guidance of an expert. Cisco IOS rules look like this ip access-group 100 in access-list 100 permit tcp policy mirror host policy source eq 5308 access-list 100 deny ip any any With "IP chains" it would look something like this: iptables -N newchain iptables -A newchain -p tcp -s policy-mirror-ip 5308 -j ACCEPT iptables -A newchain -j DENY # all else Once a new copy of the policy is downloaded by cfengine to the policy mirror, other clients in the DMZ can download that copy from the mirror. The security of other hosts in the DMZ is dependent on the security of the policy mirror. Questions about this method: Doesn't opening a port on a machine on the inside of the firewall make it vulnerable to both Denial of Service and buffer overflow attacks? Buffer overflow attacks are extremely unlikely in cfengine by design. The likelihood of a bug in cfengine should be compared to the likelihood of a bug existing in the firewall itself. Denial of service attacks can be mitigated by careful configuration (see separate FAQ item). Cfservd reads a fixed number of bytes from the input stream before deciding whether to drop a connection from a remote host, so it is not possible to buffer overflow attack before rejection of an invalid host IP. Another possibility is to use a standard VPN to the inside of the firewall. That way one is concerned first and foremost with the vulnerabilities of the VPN software. Doesn't opening the firewall comprimise the integrity of the policy information by allowing an attacker the chance to alter it? The cfengine security model, as well as the design of the server, disallows the uploading of information. No message sent over the cfengine channel can alter data on the server. (This assumes that buffer overflows are impossible.) Couldn't an IP spoofer manage to gain access to data from the policy server that it should not be able to access? Assuming that buffer overflow attacks and DOS attacks are highly improbable, the main worry with opening a port is that intruders will be able to gain access to unauthorized data. If the firewall is configured to open only connections from the policy mirror, then an attacker must spoof the IP of the policy attacker. This requires access to another host in the DMZ and is non-trivial. However, suppose the attacker succeeds then the worst he/she can do is to download information that is available to the policy-mirror. But that information is already available in the DMZ since the data have been exported as part of the policy, thus there is no breach of security. (Security must be understood to be a breach of the terms of policy that has been decided.) What happens if the policy mirror is invaded by an attacker? If an attacker gains root access to the mirror, he/she will be able to affect the policy distributed to any host in the DMZ. The policy-mirror has no access to alter any information on the policy source host. Note that this is consistent with the firewall security model of trusted/untrusted regions. The firewall does not mitigate the responsibility of security every host in a network regardless of which side of the firewall it is connected. Back to documentation