Security threats--IP Spoofing and Sniffing

Intro

Sniffing and spoofing are security threats that target the lower layers of the networking infrastructure supporting applications that use the Internet. Users do not interact directly with these lower layers and are typically completely unaware that they exist. Without a deliberate consideration of these threats, it is impossible to
build effective security into the higher levels.

• Sniffing is a passive security attack in which a machine separate from the intended destination reads data on a network. The term “sniffing” comes from the notion of “sniffing the ether” in an Ethernet network and is a bad pun on the two meanings of the word “ether.” Sniffing may seem innocuous (depending on just how sensitive and confidential you consider the information on your
  network), some network security attacks use sniffing as a prelude to spoofing. Sniffing gathers sufficient information to make the deception believable.

• Passive security attacks are those that do not alter the normal flow of data on a communication link or inject data into the link.
  

• Spoofing is an active security attack in which one machine on the network masquerades as a different machine. As an active attack, it disrupts the normal flow of data and may involve injecting data into the communications link between other machines. This masquerade aims to fool other machines on the network into accepting the impostor as an original, either to lure the other machines into sending it data or to allow it to alter data. The meaning of “spoof” here is not “a lighthearted parody,” but rather “a deception intended to trick one into accepting as genuine something that is actually false.” Such deception can have grave consequences because notions of trust are central to many networking systems.

Sniffing

Sniffing is the use of a network interface to receive data not intended for the machine in which the interface resides. A variety of types of machines need to have this capability. A token-ring bridge, for example, typically has two network interfaces that normally receive all packets traveling on the media on one interface and retransmit some, but not all, of these packets on the other interface. Another example of a device that incorporates sniffing is one typically marketed as a “network analyzer.” A network analyzer helps network administrators diagnose a variety of obscure problems that may not be visible on any one particular host. These problems can involve unusual interactions between more than just one or two machines and sometimes involve a variety of protocols interacting in strange ways. Devices that incorporate sniffing are useful and necessary. However, their very existence implies that a malicious person could use such a device or modify an existing machine to snoop on network traffic. Sniffing programs could be used to:

• gather passwords
• read inter-machine e-mail
• examine client-server database records in transit.
  

Besides these high-level data, low-level information might be used to mount an active attack on data in another computer system.


How Sniffing is Done
In a shared media network, such as Ethernet, all network interfaces on a network segment have access to all of the data that travels on the media.

• Each network interface has a hardware-layer address that should differ from all hardware-layer addresses of all other network interfaces on the network.
  
• Each network also has at least one broadcast address that corresponds not to an individual network interface, but to the set of all network interfaces. Normally, a network interface will only respond to a data frame carrying either its own hardware-layer address or the “broadcast address” in the frame’s destination field .
  
• It responds to these frames by generating a hardware interrupt to the CPU. This interrupt gets the attention of the operating system, and passes the data in the frame to the operating system for further processing.

  Note The term “broadcast address” is somewhat misleading. When the sender wants to get the attention of the operating systems of all hosts on the network, he or she uses the “broadcast address.” Most network interfaces are capable of being put into a “promiscuous mode.” In promiscuous mode, network interfaces generate a hardware interrupt to the CPU for every frame they encounter, not just the ones with their own address or the “broadcast address.” The term “shared media” indicates to the reader that such networks broadcast all frames—the frames travel on all the physical media that make up the network.
  

At times, you may hear network administrators talk about their networking trouble spots when they observe failures in a localized area. They will say a particular area of the Ethernet is busier than other areas of the Ethernet where there are no problems. All of the packets travel through all parts of the Ethernet segment. Interconnection devices that do not pass all the frames from one side of the device to the other form the boundaries of a segment. Bridges, switches, and routers divide segments from each other, but low-level devices that operate on one bit at a time, such as repeaters and hubs, do not divide segments from each other. If only low -level devices separate two parts of the network, both are part of a single segment. All frames traveling in one part of the segment also travel in the other part.

The broadcast nature of shared media networks affects network performance and reliability so greatly that networking professionals use a network analyzer, or sniffer, to troubleshoot problems. A sniffer puts a network interface in promiscuous mode so that the sniffer can monitor each data packet on the network segment. In the hands of an experienced system administrator, a sniffer is an invaluable aid in determining why a network is behaving (or misbehaving) the way it is. With an analyzer, you can determine:

• how much of the traffic is due to which network protocols
• which hosts are the source of most of the traffic, and which hosts are the destination of most of the traffic.
  
• You can also examine data traveling between a particular pair of hosts and categorize it by protocol and store it for later analysis offline.With a sufficiently powerful CPU, you can also do the analysis in real time.
  

Most commercial network sniffers are rather expensive, costing thousands of dollars. When you examine these closely, you notice that they are nothing more than a portable computer with an Ethernet card and some special software. The only item that differentiates a sniffer from an ordinary computer is software. It is also easy to download shareware and freeware sniffing software from the Internet or various bulletin board systems.

The ease of access to sniffing software is great for network administrators because this type of software helps them become better network troubleshooters. However, the availability of this software also means that malicious computer users with access to a network can capture all the data flowing through the network. The sniffer can capture all the data for a short period of time or selected portions of the data for a fairly long period of time. Eventually, the malicious user will run out of space to store the data—the network I use often has 1000 packets per second flowing on it. Just capturing the first 64 bytes of data from each packet fills up my
system’s local disk space within the hour.
Note

• Esniff.c is a simple 300-line C language program that works on SunOS 4.x. When run by the root user on a Sun workstation, Esniff captures the first 300 bytes of each TCP/IP connection on the local network. It is quite effective at capturing all usernames and passwords entered by users for telnet, rlogin, and FTP.
• TCPDump 4.0.0 (October 27, 2008) is a common, more sophisticated, and more portable Unix sniffing program written by Van Jacobson, a famous developer of high-quality TCP/IP software. It uses the libpcap library for portably interfacing with promiscuous mode network interfaces. The most recent version is available via anonymous FTP. Warning On some Unix systems, TCPDump comes bundled with the vendor OS. When run by an ordinary, unprivileged user, it does not put the network interface into promiscuous mode. With this command available, a user can only see data being sent to the Unix host, but is not limited to seeing data sent to processes owned by the user. Systems administrators concerned about sniffing should remove user execution privileges from this program.
• NetMan contains a more sophisticated, portable Unix sniffer in several programs in its network management suite. The latest version of NetMan is available here.
  
• EthDump is a sniffer that runs under DOS
  
• Wireshark (formerly Ethereal) is also a very good sniffer
  

How Sniffing threatens Security
Sniffing data from the network leads to loss of privacy of several kinds of information that should be private for a computer network to be secure. These kinds of information include the following:

• Passwords
• Financial account numbers
• Private data
• Low-level protocol information
  

The following subsections are intended to provide examples of these kinds.


Sniffing Passwords
Perhaps the most common loss of computer privacy is the loss of passwords. Typical users type a password at least once a day. Data is often thought of as secure because access to it requires a password. Users usually are very careful about guarding their password by not sharing it with anyone and not writing it down anywhere. Passwords are used not only to authenticate users for access to the files they keep in their private accounts but other passwords are often employed within multilevel secure database systems. When the user types any of these passwords, the system does not echo them to the computer screen to ensure that no one will see them. After jealously guarding these passwords and having the computer system reinforce the notion that they are private, a setup that sends each character in a password across the network is extremely easy for any Ethernet sniffer to see. End users do not realize just how easily these passwords can be found by someone using a simple and common piece of software.


Sniffing Financial Account Numbers
Most users are uneasy about sending financial account numbers, such as credit card numbers and checking account numbers, over the Internet. This apprehension may be partly because of the carelessness most retailers display when tearing up or returning carbons of credit card receipts. The privacy of each user’s credit card numbers is important. Although the Internet is by no means bulletproof, the most likely location for the loss of privacy to occur is at the endpoints of the transmission. Presumably, businesses making electronic transactions are as fastidious about security as those that make paper transactions, so the highest risk probably comes from the same local network in which the users are typing passwords. However, much larger potential losses exist for businesses that conduct electronic funds transfer or electronic document interchange over a computer network. These transactions involve the transmission of account numbers that a sniffer could pick up; the thief could then transfer funds into his or her own account or order goods paid for by a corporate account. Most credit card fraud of this kind involves only a few thousand dollars per incident.


Sniffing Private Data
Loss of privacy is also common in e-mail transactions. Many e-mail messages have been publicized without the permission of the sender or receiver. Remember the Iran-Contra affair in which President Reagan’s secretary of defense, Caspar Weinberger, was convicted. A crucial piece of evidence was backup tapes of PROFS e-mail on a National Security Agency computer. The e-mail was not intercepted in transit, but in a typical networked system, it could have been. It is not at all uncommon for e-mail to contain confidential business information or personal information. Even routine memos can be embarrassing when they fall into the wrong hands.


Sniffing Low-Level Protocol Information
Information network protocols send between computers includes

• hardware addresses of local network interfaces
• the IP addresses of remote network interfaces
• IP routing information
• and sequence numbers assigned to bytes on a TCP connection.
  

Knowledge of any of this information can be misused by someone interested in attacking the security of machines on the network. A sniffer can obtain any of these data. After an attacker has this kind of information, he or she is in a position to turn a passive attack into an active attack with even greater potential for damage.


Protocol Sniffing: A Case Study
At one point in time, all user access to computing facilities in the organization under study (i.e. a university) was done via terminals. It was not practical to hardwire each terminal to the host, and users needed to use more than one host. To solve these two problems, Central Computing used a switch (an AT&T ISN switch) between the terminals and the hosts. The terminals connected to the switch so that the user had a choice of hosts. When the user chose a host the switch connected the terminal to the chosen host via a very real, physical connection. The switch had several thousand ports and was, in theory, capable of setting up connections between any pair of ports. In practice, however, some ports attached to terminals and other ports attached to hosts. Figure 6.1 illustrates this setup. To make the system more flexible, the central computing facility was changed to a new system that uses a set of (DEC 550) Ethernet terminal servers with ports connected to the switch, rather than the old system, which used a fixed number of switch ports connected to each host. The new terminal servers are on an Ethernet segment shared by the hosts in the central machine room.

Offices have a cable running from a wallplate to a wiring closet punchdown block. The punchdown block has cables running to multiplexers which in turn connect to the switch. The multiplexers serve to decrease the number of cables that need to be long. With this arrangement sniffing or other forms of security problems are not an issue. No two offices share any media. The switch mediates all interaction between computers, isolating the flow of data away from the physical location of the end users (see fig. 6.2).

Rather than using simple terminals, however, most computer users have a computer on their desktop that they use in addition to the Central Computing computers. The switch services these computers as well as simple terminals. The number of computer users, however, has grown rapidly over the past decade and the switch is no longer adequate. Terminal ports are in short supply, host ports are in even shorter supply, and the switch does not supply particularly high-speed connections.
To phase out the switch, Central Computing installed an Ethernet hub in the basement of each building next to the punchdown block used to support both the switch multiplexer and the telephone lines. The hubs in the basements connect to the central facility using fiberoptic cables to prevent signal degradation over long distances. Hubs also were placed in the wiring closets on each floor of each building that connected to the basement hub. Now the cables leading to the wallplates in the offices are being moved from the punchdown block that leads to the multiplexer to a punchdown block that leads to one of these hubs. The new wiring scheme neatly parallels the old and was changed relatively inexpensively. Figure 6.3 illustrates
the system after the networking of user areas. Figure 6.4 shows the user area networking detail. Although the new wiring scheme neatly parallels the old, the data traveling on the new wiring scheme does not neatly parallel its previous path. From a logical standpoint, it can get to the same places, but the data can and does go to many other places as well. Under this scheme, any office can sniff on all the data flowing to Central Computing from all of the other offices in the building. Different departments are located in the same building. These departments compete for resources allocated by upper management and are not above spying on one another. Ordinary staff, the managers that supervise them, and middle management all are located in the same building. A fair amount of potential exists for employees to want to know what other people are sending in e-mail messages, storing in personnel files, and storing in project planning files. In addition to nosiness and competition, a variety of people sharing the same physical media in the new wiring scheme, could easily misuse the network. Since all occupants of a building share a single set of Ethernet hubs, they broadcast all of their network traffic to every network interface in the entire building. Any sensitive information that they transmit is no longer limited to a direct path between the user’s machine and the final destination, anyone in the building can intercept the information with a sniffer. However, some careful planning of
network installation or a redesign of an existing network should include security considerations (as well as performance issues) to avoid the risks inherent in shared media networking. The network in the case study fails miserably in the prevention of sniffing. Any computer in a building is capable of sniffing the network traffic to or from any other computer in the building. The following section describes how to design a network that limits the sharing of media to prevent sniffing by untrustworthy machines.


How to Prevent Sniffing
To be able to prevent a sniffing attack, you first need to understand the network segments and trust between computer systems.


Network Segmentation
A network segment consists of a set of machines that share low-level devices and wiring and see the same set of data on their network interfaces. The wires on both sides of a repeater are clearly in the same network segment because a repeater simply copies bits from one wire to the other wire. An ordinary hub is essentially a multiport repeater; all the wires attached to it are part of the same segment.

In higher-level devices, such as bridges, something different happens. The wires on opposite sides of a bridge are not part of the same segment because the bridge filters out some of the packets flowing through it. The same data is not flowing on both sides of the bridge. Some packets flow through the bridge, but not all. The two segments are still part of the same physical network. Any device on one side of the bridge can still send packets to any device on the other side of the bridge. However, the exact same sets of data packets do not exist on both sides of the bridge. Just as bridges can be used to set up boundaries between segments, so can switches.

Switches are essentially multiport bridges. Because they limit the flow of all data, a
careful introduction of bridges and switches can be used to limit the flow of sensitive information and prevent sniffing on untrustworthy machines. The introduction of switches and bridges into a network is traditionally motivated by factors other than security. They enhance performance by reducing the collision rate of segments, which is much higher without these components. Switches and bridges overcome the time delay problems that occur when wires are too long or when simple repeaters or hubs introduce additional time delay. As one is planning the network infrastructure one should keep these other factors in mind as well. One can use these factors to sell the introduction of additional hardware to parties less concerned with security. A segment is a subset of machines on the same subnet.

Routers are used to partition networks into subnets. Hence, they also form borders between segments in a network. Unlike bridges and switches, which do not interact with software on other devices, routers interact with network layer software on the devices in the network. Machines on different subnets are always part of different segments. Segments are divisions within subnets, although many subnets consist of a single segment in many networks. Dividing a network into subnets with routers is a more radical solution to the sniffing problem than dividing subnets into segments. However, as you will see in a later section, it may help with some spoofing problems.

Segmentation of a network is the primary tool one has in fighting sniffing. Ideally, each machine would be on its own segment and its interface would not have access to network data for which it is not the destination. This ideal can be accomplished by using switches instead of hubs to connect to individual machines in a 10BASE-T network. As a matter of practicality and economics, however, one must often find a less ideal solution. Such solutions all involve the notion of trust between machines. Machines that can trust each other can be on the same segment without worry of one machine sniffing at the other’s data.


Understanding Trust
Typically, one thinks of trust at the application layer between file servers and clients. Clearly, the file server trusts its clients to authenticate users. However, this notion of trust extends to lower-level network devices as well. For example, at the network layer, routers are trusted to deliver datagrams and correct routing tables to the hosts on their networks. Hosts are trusting of routers and routers are trusted machines. If you extend the concept of trust down to the data link layer one gets to sniffing. A machine sending data considered private on a particular network segment must trust all machines on that network segment. To be worthy of that trust, the machines on the segment and the wiring between them must have sufficient physical security (locks on doors, armed guards, and such) to ensure that an attacker cannot install a sniffer on that segment.

The threat of sniffing comes from someone installing sniffing software on a machine normally on the network, someone taking a sniffer into a room and jacking it into the network connections available there, or even installing an unauthorized network connection to sniff. To counter these options, you must rely on the security of the operating system itself to prevent the execution of unauthorized sniffing, the personal trustworthiness of the people who have access to the rooms in which network components are located, and physical security to prevent untrustworthy people from gaining access to these rooms.


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 privacy 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 6.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 6.6 (the lines between segments indicate that the segments are connected by a device that limits data flow, such as a bridge).


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, or Windows 9x. 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(diskless) 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.

A workstation running an operating system such as Windows NT, Unix, or VMS provides an extra degree of protection because these systems include privileged users, also known as superusers (“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.

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.

Segments with Mutually Trusting Machines
Some research at academic and industrial departments requires that the end user have complete access to the machine on the desktop. In these cases, a secure segment is probably out of the question unless the end users are impeccably ethical and technically competent to maintain system security on the machines they control (a machine administered by someone without security training is likely to be broken into by an attacker and used as a base of operations to attack other machines, including sniffing attacks). If you assume the end users are indeed competent to ensure the security of their own desktop system, all machines on the segment can be considered mutually trusting with respect to sniffing. That is, while any of the machines on the segment could be used as a sniffer, the users trust that they will not be based on the following:

• The physical security of the machines
• The technical competence of the other users to prevent outsiders from gaining control of one of the machines remotely
• The personal integrity of the other users
  

It is possible to build a secure subnet or local area network out of a set of segments that each have mutually trusting machines. You must locate machines that are not mutually trusting on separate segments. Machines that need to communicate across segment boundaries should only do so with data that is not private. You can join mutually trusting segments by secure segments. Such an arrangement presumes that the end users trust the staff operating these central facilities. However, from a practical standpoint all but the most paranoid end users find this acceptable.


Connecting Segments of One-Way Trust
Consider, for example, the simple situation of two segments of mutual trust. Mutual trust exists between the machines on the first segment and mutual trust exists between the machines on the second segment. However, the machines in the first segment are communicating less sensitive information than those in the second segment. The machines in the first segment may trust those in the second segment but not vice versa. In this case, it is allowable for the data from the first segment to flow through the second segment. However, you must use a barrier such as a bridge to prevent the flow of data in the opposite direction.

• One-way trust is fairly common between secure segments and other types of segments. The less secure machines must trust the more secure machines, but not vice versa.
  
• Similarly, one way trust may exist between a segment of mutual trust and an insecure segment.
  
• Connecting segments with one way trust via bridges and routers leads to a hierarchy of segments. Tree diagrams represent hierarchies graphically. In this case, the parent-child relationship in the tree associates the parent with a more secure segment and the child with a less secure segment. Thus, the more secure segments are closer to the root of the tree and less secure segments are closer to the leaves—insecure segments are leaves in the tree representing the one-way trusthierarchy.
  

Insecure Segments
In many cases, it is not practical to construct the segment boundaries between machines that are not mutually trusting. The reason for this is that such a setup isn’t safe from sniffing. Insecure segments might be acceptable in areas where security requirements are also low. However, most users expect a higher level of security than any such setup could provide. If you must use an insecure segment and still expect a higher degree of security, your only solution is software-based techniques rather than hardware-based techniques, such as encryption technology.


Case Study: A Small Department Subnet
A good case study of a network system at risk is in building at a university. Computer Science shares two floors of the building with Mathematics and English. On the lower floor are several rooms with computers that are accessible by clients of Computer Science, offices for professional staff members in each of the three departments, and the Computer Science machine room. On the upper floor are offices for professional staff members of Computer Science and Mathematics and the office suites for the managers and secretarial staff of each. The rooms in which clients access the network are not secure. Professional staff members in each department are mutually trusting of each other. They are not mutually trusting of all
members of other departments. The two management suites cannot trust each other. They cannot trust the professional staff they supervise because they work with sensitive employee records dealing with performance reviews, salary recommendations, and compete for resources provided by higher levels of management.

In fact, the management suites are equipped with a higher level of physical security than the professional staff offices. These suites may be considered secure relative to the offices of the staff they supervise. The machines in each suite can be considered mutually trusting of other machines, because the personnel share sensitive information with each other anyway (see fig. 6.7). Finally, the Computer Science machine room is secure. To satisfy the constraints of these trust relationships, the staff members of Computer Science, Mathematics, and English must each be placed on a separate segment. The Mathematics management suite must be placed on a separate segment. However, data to and from the Mathematics staff may flow through the Mathematics management suite without violating the trust constrains. In an exact parallel, the Computer Science management suite can have a segment with data flowing through it to and from the Computer Science staff segment. The machines used by Computer Science clients may transmit through staff and management segments. Notice the fact that we have a hierarchy of trust being in effect here. At the top end of the hierarchy is the Computer Science machine room, which must be on its own segment as well.

Now consider the wiring system available to service these two floors. The lower floor has a single communication closet that contains the connection to the central computing facility. The upper floor has a primary communication closet immediately above it connected by a conduit through the flooring. This primary communication closet on the upper floor is close to the Mathematics management suite. The primary closet connects, via a wiring conduit, to a secondary communication closet on the opposite side of the upper floor close to the Computer
Science management suite.

If you do not consider security, you will design the network by looking purely at cost and performance. The minimum cost solution is simply to locate a set of hubs in each communications closet and connect all the hubs together to form a single segment. From a performance standpoint the management personnel do not want to have their network activity slowed by the activity of the staff they supervise or by people from a different department, so one can argue to segment the network on the basis of performance in a way that is close to what is needed for security purposes. If cost is not an issue, each of the proposed segments can simply be connected by a switch. A realistic solution needs to do the following:

• Balance the issues of cost and performance
• Take into consideration the physical layout of the building
• Maintain security by not violating the trust constraints
  

Figure 6.8 shows such a solution. Mathematics places all of its staff on a single segment by connecting hubs in the upper and lower floor communication closets. The Mathematics management suite has a segment that bears the burden of traffic from the staff segment. While Mathematics has a lower cost solution, Computer Science has a higher performance solution. Computer Science has five separate segments joined by a switch. Computer Science staff are placed on two separate segments, one for the upper floor and one for the lower floor, not to satisfy any security concern, but because separate hubs on each floor simplified the wiring and
provide a low-cost opportunity to enhance performance. Computer Science, Mathematics, and English each have a separate subnet. These three subnets are joined into a single network by a router located in the communication closet on the lower floor.

The solution shown in figure 6.8 provides for reasonable security against sniffing. Absolute ecurity is not provided since it is still possible for anyone to hook up a sniffer on any of the segments. However, data from areas where more security is needed do not flow through areas where less security is needed. The areas where more security is needed have higher levels of physical security as well. Hence, it is increasingly difficult to physically get to a location where sensitive data is flowing on the wires. Also, except on the insecure Computer Science client segment, there is trust between the authorized users of the machines sharing a segment. Hence, an authorized user of a machine cannot use it to sniff data going to or from someone who does not trust the user.

You can learn several things from looking at the case study and its solution:

• A minimum cost solution is not likely to provide for security
• A totally secure system is prohibitively expensive, but a reasonably secure system is not.
• Different approaches to cost and performance trade-offs may be combined in a secure system. Mathematics and Computer Science have different budgets for equipment and needs for network performance.
• A single solution may provide both security and enhance performance as in the solution shown for Computer Science.
• A solution that provides for security adds significantly to cost. There is almost no cost difference between having a single segment for Mathematics and the solution shown. An extra wire run from the lower floor staff hub to the upper floor staff hub is one extra cost item as is the bridge separating the two segments.

Tip A simple hardware barrier that is inexpensive and has the potential for increasing network performance is the installation of a bridge between your machine room and the rest of your facility. In many cases, a great deal of traffic occurs between the computers in the machine room. A bridge placed between the machine room and the rest of the facility prevents this traffic from escaping to less secure areas and reduces the collision rate outside the machine room. Bridges are much less expensive than a router or a switch. In fact, a low-cost personal computer may be configured for this purpose with free software such as Drawbridge.

Drawbridge is a free software package that turns an ordinary PC with a pair of standard Ethernet interfaces into a bridge. Drawbridge is also capable of filtering operations and can act as a cheap alternative to a firewall in small networks. In some cases, you may be able to recycle a used PC considered obsolete for this purpose as the memory and disk requirements of Drawbridge are quite modest.
So far, this section has covered how to avoid sniffing of data from the local part of the Internet. Such an action seems directed toward protection against internal personnel rather than external threats. However, many security breaches are aided either knowingly or unknowingly by internal personnel. In such cases, the hardware barriers described in this section will limit what an intruder, physically present or remote, can do with a sniffer. Not only is physical security greater for the more trusted segments, but so is the technical competence of those in charge of the computer systems. The least technically competent to protect a system from remote
intruders must be given systems that cannot be given commands from a remote location (such as a simple personal computer). Systems that can accept commands from remote locations must be administered by those technically competent enough to prevent remote intruders by not making mistakes that will allow remote intruders to gain access to the systems.


To be continued...