Local area networks (LANs) are small networks connected (generally) via ethernet. Data is transmitted from one machine to another via cable.

Data travels along the cable in small units called frames. These frames are constructed in sections, and each section carries specialized information. For example, the first 12 bytes of an ethernet frame carry both the destination and source MAC address. These values tell the network where the data came from and where it’s going. Other portions of an ethernet frame carry actual user data, TCP/IP headers, IPX headers, and so forth.

Frames are packaged for transport by special software called a network driver. The frames are then passed from your machine to cable via your Network Interface Card (NIC). From there, they travel to their destination. At that point, the process is executed in reverse: The recipient machine’s NIC picks up the frames, tells the operating system that frames have arrived, and passes those frames on for processing.

Sniffers pose a security risk because of the way frames are transported and delivered. Let’s briefly look at that process.

Each workstation in a LAN has its own hardware address or Media Access Control (MAC) address. This address uniquely identifies that machine from all others on the network. (This is similar to the Internet address system.) When you send a message across the LAN, your packets are sent to all connected machines.

Under normal circumstances, all machines on the network can “hear” that traffic going by, but will only respond to data addressed specifically to them. In other words, Workstation A will not capture data intended for Workstation B. Instead, Workstation A will simply ignore that data.

If a workstation’s network interface is in promiscuous mode, however, it can capture all packets and frames on the network. A workstation configured in this way (and the software on it) is a sniffer.

The sniffers in this section are commercial, but many of these companies offer demo versions. Prices range from $200 to $2,000.

Many freeware and shareware sniffers are also available. These are perfect if you want to learn about network traffic without spending any money. Unfortunately, some are architecture-specific, and the majority are designed for Unix.

Sniffers are extremely difficult to detect because they are passive programs. They don’t generate an audit trail, and unless their owner is very stupid, they use up no network resources. Some operating systems provide a mechanism to determine whether a network interface has been placed in promiscuous mode, which can aid greatly in determining if a sniffer is running on a specific host.

On a single machine, it is theoretically feasible to determine whether a sniffer has been installed. For example, you could rely on the MD5 algorithm (see Chapter 18, “Trojans,” for more on MD5), provided you have a decent database of original installation files (or a running database of installed files). If you intend to use MD5 and search by checksum, you should obtain md5check, an awk script that automates the process. md5check was originally distributed by CERT and works well for SunOS. md5check can be found at http://lvl.sourceforge.net/md5check.php. Another alternative is Tripwire (http://www.tripwire.org), or see Chapter 21, “Unix,” for more on Tripwire.

Certainly, searching by checksum on a single box is effective enough. However, finding a sniffer on a large network is difficult. The question of detecting sniffers on diverse architecture is a bitter debate in the security community. (You can see folks arguing this issue for weeks at a time without resolution.) However, there are several tools that can help—if you have the right architecture:

Detecting a sniffer in heterogeneous networks is more difficult—difficult, that is, without physically checking each machine. For example, suppose your network is made up exclusively of AIX systems. Suppose further that someone goes into an empty office, unplugs a RS/6000, and hooks up a PC laptop, which they use as a sniffer. This is difficult to detect unless you are using network topology maps (tools that red-flag any change in topology) and check them daily. Otherwise, the network appears just as it did, with no indication of trouble. After all, the PC has the same IP as the RS/6000 did. Unless you run daily scans, you would probably never detect the PC.

A more complicated situation occurs when intruders attach physical devices that sniff. (For example, they can splice themselves in at points not visible to the naked eye. I’ve seen offices that run their coax wire overhead, in the space above the ceiling. This allows anyone in an adjacent office to snag the wire and patch themselves in.) Other than physically checking each wire lead throughout the network, there is no easy way to identify a spliced connection. (Although, again, network topology mapping tools would warn that an extra IP had been added to your subnet. Unfortunately, however, most small businesses can’t afford such tools.)

At day’s end, however, proactive solutions are difficult and expensive. Instead, you should take more defensive measures. There are two chief defenses against sniffers:

Let’s quickly cover both defenses.

Sniffers can only capture data on the instant network segment. This means that the tighter you compartmentalize your network, the less information a sniffer can gather. This used to be expensive, but switches have dropped in price so much that a low-end switch does not cost much more than a hub. There are three network interfaces that a sniffer cannot easily cross:

You can create tighter network segments by strategically placing these devices on the network. You could possibly compartmentalize 20 workstations at a crack—this seems like a reasonable number. Once a month you could physically check each segment (and, also perhaps once a month, you could run MD5 checks on random segments). It should be noted that programs such as macof have been developed to flood switches in the hope that they would fail open. This would then eliminate the protection that switching might otherwise have provided.

Encrypted sessions provide a different solution. Instead of worrying about data being sniffed, you simply scramble the data portion of the packet beyond recognition. The advantages to this approach are obvious: Even if an attacker sniffs data, it will be useless to him. However, the disadvantages are weighty. There are two chief problems with encryption. One is a technical problem, and the other is a human problem.

Technical issues include whether the encryption is strong enough, and whether it’s supported. For example, 40-bit encryption might be insufficient, and not all applications have integrated encryption support. Furthermore, cross-platform encryption solutions used to be rare and typically available only in specialized applications. Recently, cross-platform and generalized encryption services are becoming more common and will continue to do so.

Moreover, human users can resist using encryption. They might find it too troublesome. (For example, can you imagine forcing Macintosh users to use S/Key every time they logged in to the server? These folks are accustomed to ease-of-use, not generating one-time passwords for every new session.) Users might initially agree to such policies, but they rarely adhere to them.

In short, you must find a happy medium—applications that support strong, two-way encryption and also support some level of user-friendliness. That’s why I like Secure Shell.

Secure Shell (SSH) provides secure communications in an application environment like Telnet. SSH binds to port 22, and connections are negotiated using RSA. All subsequent traffic is encrypted using IDEA after authentication is complete. This is strong encryption, and is suitable for just about any nonsecret, nonclassified communication.

Secure Shell is a perfect example of an application that meets user and administrative standards.

Versions of SSH and OpenSSH (a free version of SSH) exist for just about all of the major operating systems. Check out Secure Shell at http://www.ssh.com/ or http://www.openssh.com.