managing network security with cfengine,
part 1

by Mark Burgess
<Mark.Burgess@iu.hioslo.no>

Mark is associate professor at Oslo College and is the author of cfengine and winner of the best paper award for LISA 1998




Also, see Part 2 (October issue) and Part 3 (December issue) of this article.

You can read more about cfengine and obtain it from <http://www.iu.hioslo.no/cfengine>. (Please note that the following Web sites are not associated with cfengine, and readers are advised to steer clear of them: www.cfengine.com, www.cfengine.org, www.cfengine.net)

A Word of Warning
It is only proper to state the obvious. You should never trust anyone's advice about configuration or security without running it past your own gray matter first. The examples provided here are just that: examples. They might apply to you as written and they might need to be modified. You should never accept and use an example without thinking carefully and critically first! Also, in any book of recipes or guide to successful living you know that there are simplified answers to complex questions and you should treat them as such. There is no substitute for real understanding.

Computer security is about protecting the data and availability of an association of hosts. The key words are authentication, privacy, integrity, and trust. To understand computer security we have to understand the interrelationships among all of the hosts and services on our networks as well as the ways in which those hosts can be accessed. Tools that allow this kind of management are complex and usually expensive. A simple free software program that is in widespread use whose functionality is at least equal to commercial packages is cfengine. It runs on nearly every UNIX-like system and on NT with the cygwin tools installed.

Software security is about access control and software reliability. No single tool can make computer systems secure. Major blunders have resulted from the belief that a single product (e.g., a firewall) would solve the security problem. For instance, a few years ago a cracker deleted all the user directories from a dial-up login server belonging to a major Norwegian telecommunications company — from the comfort of his Web browser. This was possible, even through a firewall, because the Web server on the host concerned was incorrectly configured. The bottom line is that there is no such thing as a secure operating system, firewall or not. What is required is a persistent mixture of vigilance and adaptability.

Many perceive security as synonymous with network privacy or prevention of network intrusion. Privacy is one aspect of security, but it is not the network that is our special enemy. Many breaches of security happen from within. There is little difference between the dangers of remote access from the network and direct access from a console; privacy is about access control, no matter where the potential intruder might be. If we focus exclusively on network connectivity we ignore a possible threat from internal employees (e.g., the janitor who is a computer expert and holds a grudge; or the mischievous son of the director who was left waiting to play in Mom's office; or perhaps the unthinkable, a disgruntled employee who feel unappreciated). Software security is a vast subject because modern computer systems are complex. It is only exacerbated by the connectivity of the Internet, which allows millions of people to have a go at breaking into networked systems. What this points to is the fact that a secure environment requires a tight control of access control on every host individually, not merely at specific points such as firewalls.

This series of articles is an attempt to illustrate how cfengine can be used to help you automate a level of host integrity on all the hosts of your network. Cfengine is a network-configuration tool with two facets. First, it is a language used to build an "expert system." An expert system describes the way you would like your hosts and network to look and behave. Second, cfengine is a software robot that compares the model you have described with what the world really looks like, and then sets to work correcting any deviations from that picture. In many ways it is analogous to an immune system, neutralizing and repairing damaged parts. Unlike many shell-script packages for system administration, cfengine is a C program, which means that it's light on system resources. It works on a principle of "convergence." Convergence means that each time you run cfengine the system should get closer to the model that you have described until eventually, when the system matches the model, cfengine becomes quiescent, just like an immune system. In the words of one user, your hosts "never get worse." This assumes of course that your model is what you really want.

Model-building using cfengine becomes synonymous with formulating and formalizing a system policy. What makes cfengine a security tool is that security policy is a part of system policy: You cannot have one without the other. You will never have security unless you are in control of your network. Cfengine monitors and indeed repairs hosts with simple, easily controllable actions. From an automation perspective, security is no different from the general day-to-day business of system maintenance; you just need to pay more attention to the details. We cannot speak of "having security" and "not having security." There is always security — it is simply a matter of degree: weak or strong; effective or ineffective.

Automation

Even in the smallest local-area network you will want to build a scheme for automating host configuration and maintenance, because networks have a way of growing from one host into many quite quickly. It is therefore important to build a model that scales. A major reason for using cfengine is scalability. Whether you have one host or a hundred makes little difference. Cfengine is instructed from a central location, but its operation is completely and evenly spread across the network. Each host is responsible for obtaining a copy of the network model from a trusted source and is then responsible for configuring itself without intervention from outside. Unlike some models, cfengine does not have to rely on network communication or remote-object models. We also need integration or "the ability to manage the interrelationships between hosts." It is no good having complete control of one important host and thinking that you are secure. An intruder who can get into any host is almost certain to get into the ones that matter, especially if you are not looking at all of them. Using cfengine is a good way of forcing yourself to formulate a configuration/security policy and then stick to it. Why cfengine? Three reasons:

• It forces a discipline of preparation that focuses you on problems at the right level of detail.

• It provides you with "secure" scalable automation and a common interface to all your hosts.

• It scales to any number of hosts without additional burdens.

The first step in security management is to figure out a security policy. That way, you know what you mean by security and what you will do if that security is breached. In many cases you can formulate a large part of your security policy as cfengine code. That makes it formal and accurate, and the robot will do it without requiring any more work on your part.

As an immune system, cfengine will work fine even in a partially connected environment because it makes each host responsible for its own state. It does not rely on network connectivity for remote-method invocations or CORBA-style object requests as does, say, Tivoli. All it needs is an authentic copy of the network-configuration document stored locally on each host. If this is the case, a detached host will not be left unprotected; at worst it might lag behind in its version of the network configuration.

Trust

There are many implicit trust relationships in computer systems. It is crucial to understand them. If you do not, your trust can be exploited by attackers who have thought more carefully than you have.

For example, any NFS server of users' home directories trusts the root user on the hosts that mount those directories. Some bad accidents are prevented by mapping root to the user "nobody" on remote systems, but this is not security, only convenience. The root user can always use su to becomes any user in its password file and access or change any data within those filesystems. The .rlogin and hosts.equiv files on UNIX machines grant root (or other user) privileges to other hosts without the need for authentication.

If you are collecting software from remote servers, you should make sure that it comes from a machine that you trust, particularly if it includes files that could lead to privileged access to your system. Even checksums are no good unless they also are trustworthy. For example, it would be an extremely foolish idea to copy a binary program such as /bin/ps from a host you know nothing about. This program runs with root privileges. If someone were to replace that version of ps with a Trojan-horse command, you would have effectively opened your system to attack. Most users trust anonymous FTP servers from which they collect free software. In any remote copy you are setting up an implicit trust relationship. You trust the integrity of the host you are collecting files from, and you trust that it has the same username database with regard to access control. The root user on the collecting host has the same rights to read files as the root user on the server. The same applies to any matched user name.

Why Trust Cfengine?

Cfengine has a very simple trust model. It trusts the integrity of its input file and any data that it explicitly chooses to download. Cfengine places the responsibility on root@localhost, not on any outsiders. You can make cfengine destroy your system, just as you can destroy it yourself, but no one else can. As long as you are careful with the input file, you are trusting essentially no one. (I'll qualify this below for remote file copying.)

Cfengine assumes that its input file is secure. Apart from that input file, no part of cfengine accepts or uses any configuration information from outside sources. The most one could do from an authenticated network connection is to ask cfengine to carry out (or not) certain parts of its model; thus in the worst-case scenario an outside attacker could spoof cfengine into configuring the host correctly. In short, no one except root@localhost can force cfengine to do anything (unless root access to your system has already been compromised by another route). This means that there is a single point of failure. The input file does not even have to be private as long as it is authentic. No one except you can tell cfengine what to do.

There is a catch, though. Cfengine can be used to perform remote file transfer. In remote file transfer one is also forced to trust the integrity of the data received, just as in any remote-copy scheme. Although cfengine works hard to authenticate the identity of the host, once the host's identity is verified it cannot verify the accuracy of unknown data it has been asked to receive. Also, as with all remote file transfers, cfengine could be tricked by a DNS spoofing into connecting to an imposter host. So use the IP addresses of hosts, not their names, if you don't trust your DNS service. In short, these faults are implicit in remote copying. They do not have to do with cfengine itself. This has nothing to do with encryption, as users sometimes believe; encrypted connections do not change these trust relationships — they improve the privacy of the data being transmitted, not its accuracy or trustworthiness.

In the next issue, we will look at the details of cfengine configuration.