Hardware Barriers

To create trustworthy segments, you must set up barriers between secure segments and insecure segments. All of the machines on a segment must mutually trust each other with the data traveling on the segment. An example of such a segment would be a segment that does not extend outside the machine room of a computing facility. All machines are under the control of a cooperating and mutually trusting systems staff. The personal trust between staff members is mirrored by the mutual trust between the systems for which they are responsible.

The opposite of this is the belief and understanding that some segments simply must be considered insecure. Insecure segments need not be trusted if those segments carry only public or non-critical data. An example of such a segment is a university laboratory used only by students. No guarantee of absolute security is made for the information stored. Possibly the students realize that for this network drive only reasonable precautions will be taken to maintain confidentiality by enforcement of password protections, file system access lists, and regular backups.

It is less clear where to draw the line in a more professional business setting. The only basis for trust between machines is for trust between the people who control the machines. Even if a person can be trusted personally in an ethical sense, he or she may not be trustworthy technically to administer a machine in such a way that an attacker could not abuse the machine under his or her control.

Suppose a set of machines has a set of trust relationships as shown in figure 5.5 (an arrow points from the trusting machine to the trusted machine). One needs to connect them to the network in such a way that two machines that do not trust each other are on the same segment and provide appropriate physical security to avoid tampering with a trusted machine. One such partitioning is shown in figure 5.6 (the lines between segments indicate that the segments are connected by a device that limits data flow, such as a bridge).

Figure 5.5  A simple set of trust relationships between machines. An arrow points from the trusting machine to the trusted machines.

Figure 5.6  A partitioning into network segments of the machines in figure 5.5 that satisfies the lack of trust between machines.

Secure User Segments

Security is a relative thing. How secure you make a segment is related to how much control you take away from the technically untrustworthy end user who uses the network in a location with limited physical security.

In some settings, you may consider it appropriate to remove control of a machine from the end user because you cannot trust the end user from a technical standpoint. However, to actually remove control from the end user and prevent the end user machine from being used for sniffing, the machine on the end user’s desk essentially becomes a terminal. This may seem disheartening, but keep in mind that terminals such as X Window System terminals provide the user with all the functionality of a workstation for running most Unix application software—they also have no moving parts and are virtually maintenance free.

If the end user cannot be trusted or if the software on a desktop machine could be altered by the authorized end user because of the machine’s physical location, then the machine should not be a personal computer. For the purposes of this discussion, a personal computer is one that runs an operating system such as DOS, Windows 3.1, Windows 95, or the MacOS. These operating systems lack the notion of a privileged user in the sense that any user can run any program without interference from the operating system. Hence, any user can run a sniffer on such a system. PCs have always been popular because they can be customized by the end user. No system administrator can restrict what the end user can and cannot do with one of these machines. In highly secure settings, machines that use these operating systems are set up without local disks to prevent installation of unauthorized software such as a sniffer. Essentially, they become terminals that offload some of the work from the central, physically secure server. There are trade-offs in performance and productivity to consider. Operating systems such as Novell NetWare, Windows NT, Unix, or VMS provide an extra degree of protection because these systems include privileged users, also known as superusers (“admin” or “supervisor” in NetWare, “administrator” in NT, “root” in Unix, and “system” in VMS) who must know a special password. These operating systems only allow access to certain hardware level operations to superusers. If the end user has ordinary user access to the machine on his or her desk but does not have superuser privileges, then the machine can be trusted to a larger degree than the user. It is still possible to bring alternative boot media to most workstation-class operating systems and obtain superuser privileges without knowing the superuser password. The more secure systems, however, limit the user’s ability to install software. Usually the only software that can be installed by the user is the operating system. For dedicated enterprise and work group servers, physical security is required. Servers should be kept in locked rooms not on or under users’ desks. The following example demonstrates a simple physical security rule—if you can touch it, you can own it.

---

Note:  I once had to review the security arrangements on a set of (DECstation 3100) workstations. The system administrator in charge of the local network had designated the workstations secure enough to be trusted by the file server to NFS mount a file system containing mission-critical data directories. I turned one of the workstations off, waited a second and turned it back on. After a self-test, it came up with a boot monitor prompt. I was familiar with similar machines and knew I had two alternatives, but was unsure what the effective difference would be on this particular model of workstation. As it turned out, one command (auto) would boot the workstation directly into Unix multiuser mode, which is what the system administrator had always done. The system administrator was unaware of the results of trying the alternative command. When I tried the alternative command (boot), the workstation booted directly into Unix single-user mode and gave the person at the keyboard superuser privileges without being required to issue a password.

These workstations clearly were not sufficiently secure to be trusted to NFS mount the mission-critical disks. The documentation supplied with the workstations did not mention it. However, it turned out that the single-user mode can be password protected with a password stored in non-volatile RAM under the control of the boot monitor. Password protection made these workstations sufficiently secure to be trusted to mount the mission-critical disks. Absolute security is out of the question, since one can still reset the non-volatile RAM by opening the system box. On other systems, the password may be circumvented with other methods.

Although this story has little to do with sniffing, it illustrates how trust can often lead to unexpected risks on machines outside the server room. By obtaining superuser privileges, a user could not only sniff data, but do much more serious damage.

---