Detecting an ARP Spoof

The best you can usually hope for is rapid detection followed by some form of intervention. When an anomaly is detected in the ARP protocol it may be legitimate, accidental, or a security breach. Policies and procedures should be in place to handle each type of incident.

Host-Level Passive Detection

As a basic precaution, when an operating system responds to an ARP broadcast, it should inspect both the sender IP address and the target IP address. It only needs to check the target address to see if the target IP address matches its own IP address. If so, it needs to send an ARP reply. However, once the operating system has been interrupted, it takes little extra work to check to see if the sender IP address matches its own. If so, another machine on the network is claiming to have the same IP address. Such an anomaly certainly indicates a serious  configuration problem and may be the result of a simplistic ARP spoof in which the attacker simply reset the IP address of the machine being used in the attack. Many Unix systems perform such a check.

Host-Level Active Detection

Another precaution to detect ARP spoofs is to arrange for hosts to send out an ARP request for their own IP address, both on system startup and periodically thereafter. If the host receives an ARP reply for its own IP address, the IP software should report the detection of an ARP spoof to the host user or administrator. Actively querying ARP with one’s own IP address will catch inadvertent IP address misconfigurations as well as an attacker who is simply using an ordinary operating system with a deliberately misassigned IP address. However, it is possible to mount a more sophisticated attack that will thwart the active query detection method.

In particular, a technically adept attacker might modify the operating system of the machine being used to mount the attack. A simple modification that thwarts the active query detection method is to not reply to ARP requests originating from the legitimate interface associated with the IP address being used. The availability of such sophisticated software may seem unlikely even to an advanced computer user.

However, freely distributed Unix-like operating systems with freely distributed source code are now very common. It is not particularly difficult for a determined attacker to obtain such an operating system. He or she could then modify its kernel at the source code level, and compile a modified kernel specifically for the purpose of mounting such an attack.

Server-Level Detection

Alternatively, a more elaborate precaution would be to verify an ARP reply by making an RARP request for the hardware address contained in the reply. RARP, the reverse address resolution protocol, uses the same format as ARP and also broadcasts requests. RARP requests ask the question “What is the IP address associated with the hardware address I have here?” Traditionally, the primary use of RARP is by diskless machines with no permanent modifiable memory. Such machines need to discover their own IP address at boot time. RARP relies on one or more RARP servers that maintain a database of hardware addresses and the corresponding IP addresses. Use of an RARP server is probably overly elaborate when an ARP server would do the same job.

Note The basic idea of checking the validity of the results to a query by making an inverse query is generically useful. That is, in many situations you are querying a system equivalent to a database. Suppose you use one value, X, as a key for a query with the database indexed on one field and get a second value, Y, from a second field as a result. Then, you can use Y as they key for a query with the database indexed on the second field and you should get X as a result. If you do not, then something is wrong with the database or its searching mechanism.

Network-Level Detection: The Motivation

The motivation for network-level detection is that host-level detection may be unable to effectively inform the network staff that a problem exists and that server-level detection probably requires modification of IP software of the operating system source code. When a host detects that it is being impersonated by another machine, it may be able to report the fact to its user, but once an attack is underway it may be unable to inform the network administrator who is presumably using another machine.

Some popular IP system software may very well take the precaution of occasionally making ARP requests for the hardware address associated with the IP address it believes is its own. The active querying precaution is well-known and is a common textbook exercise. Most corporate system staffs are unable to modify the IP software of most of the machines on their network. If that is your situation, you probably want a software detection system that can be deployed on a single machine on your network. Building the system using software already written by someone else is preferable.

Network-Level Detection via Periodic Polling

By periodically inspecting the ARP caches on machines, you should be able to detect changes in the IP address to hardware address association on those machines. It should be routine for the network staff to keep a database of hardware addresses, IP addresses, DNS names, machine types, locations, and responsible persons. At the very least, such an inspection can probably be done manually on most hosts. It could be done more often if hosts could be configured to periodically report the contents of their ARP caches to a centralized machine. A program on that machine could look for inconsistencies between hosts, changes from previous reports, and

conflicts between reported ARP cache information and the information in the manually maintained database—any of these may indicate a problem.

Standard mechanisms for periodic reporting of network configuration information from machines on an IP-based network to the network administration staff already exist. One such mechanism is SNMP—the Simple Network Management Protocol.

In SNMP, each machine using IP runs an SNMP agent which both responds to information and configuration requests as well as reports certain conditions to the network management staff. Virtually all current systems provide bundled SNMP agents. To take advantage of SNMP, the network management staff must have SNMP management software to query the agents and react to the agent reports. Finding good SNMP management software may be difficult and expensive to purchase and deploy.

If your network is already employing SNMP for other purposes, including a check on ARP caches may be simple and inexpensive depending on the sophistication of your SNMP management software. The standard SNMP MIB-I contains the address translation group that contains a single table named “at.atTable,” which contains the IP address and hardware address of each interface being monitored by the SNMP agent. The address translation group has to be deprecated in SNMP MIB-II to allow for greater flexibility because IP is now no longer the only protocol being controlled with SNMP. For SNMP agents that use MIB-II, you should look in the IP address translation table in the IP group named ip.ipNetToMediaTable.

Hardware Barriers

The use of bridges or switches removes the threat of sniffing between network segments; likewise, the use of routers removes the threat of ARP spoofing between IP subnets.

You can separate the trusted hosts (those with IP addresses that might benefit an attacker using ARP spoofing) from subnets on which an attacker might obtain access. Subnetting for security is helpful if physical security prevents attachment to the subnet of the trusted machine. Such subnetting prevents a spoofer from powering down one of the trusted machines and attaching to the subnet on which ARP requests from the trusting machine are broadcast.

A temptation when considering using subnetting to protect from ARP spoofing is to place the machine extending trust on a separate subnet from the machines to which it is extending trust.

However, this setup simply places the router in the position of being deceived by an ARP spoof.

If trust is extended on the basis of IP addresses, the machine extending the trust is in turn trusting the routers to deliver the IP datagrams to the correct machine. If the trusted machines are on a separate subnet that is susceptible to ARP spoofing, the router for that subnet must bear the burden of ensuring that IP datagrams get to their legitimate destination. With this setup, you might need to place permanent ARP cache entries for the trusted machines in the router itself.

Finally, it is also important that trusted machines be protected from an ARP spoofer that is attempting to masquerade as the router. Fortunately, routers are typically physically secure  and crash rarely or for very little time, which makes them difficult to impersonate.

Spoofing

Spoofing can occur at all layers of the IP system. The hardware layer, the data link layer, the IP layer, the transport layer, and the application layer are susceptible. All application layer protocols are at risk if the lower layers have been compromised.

Hardware Address Spoofing

At the hardware layer, any network interface for a shared-media network will have a hardware interface address. As we already know sniffing, most network interfaces can be put into promiscuous mode and receive frames with any destination address.

A much more serious problem occurs if the network interface can alter the source address and send data that appears to come from various source addresses. In the IEEE 802 standards for networking (of  which Ethernet is a variant), each network interface has a 48-bit hardware address. It uses this hardware address to match the variety of destination addresses of the frames it sees. The interface copies frames with matching destination addresses into its internal buffer and notifies the operating system that they are available for further processing. Packets coming from the operating system to the interface do not typically specify a source address; the interface always puts its hardware address in the source field.

Most software does not typically control the source field of frames leaving an Ethernet interface. When another host examines a packet containing a hardware source address associated with an interface of a particular machine, it assumes that the packet originated on that machine and accepts it as authentic. An IEEE standards committee assigns each network interface manufacturer a unique 24-bit prefix for the 48-bit hardware address; the manufacturer assigns a unique 24-bit suffix to each interface it makes. Regardless, many interface cards are configurable and allow host software to specify a source address other than the one assigned by the manufacturer. This configurability makes it possible to use them to spoof the source address.

To see how common it is for a network interface to be able to spoof the source address, however, recall how a bridge works. A bridge not only puts its interfaces into promiscuous mode, but it also sets the hardware source address of packets sent out on its interfaces to match the hardware source address of the originating interface. A PC with two software configurable interfaces can be configured to be used as a bridge. Clearly, such software configurability has a variety of malicious uses. The drawbridge software mentioned in the previous section on hardware barriers to prevent sniffing is compatible with most Ethernet boards which means most Ethernet boards will permit source address spoofing.

As you can see, it is not entirely safe to base the authenticity of a packet on the hardware source address. Unfortunately, there is very little you can do to protect yourself against such deviousness. One solution is to use digital signatures at the application layer. Unfortunately, currently there are no protections in the IP network layer that will prevent a hardware address spoofer from disguising one machine as another.

If the victim machine is trusted (for example, is allowed to NFS mount filesystems from another machine), the spoofer will be able to take advantage of that trust and violate security without being detected.

Fortunately, hardware address spoofing is difficult (relative to many other spoofing methods) and requires penetration of physical security.

Countering hardware level spoofing is difficult because it is virtually undetectable without tracing the physical wiring. You need to trace the wiring to be certain no one has connected an unauthorized machine and you also need to check to see if the authorized machines are using the hardware address they should. The latter can be checked using sufficiently “intelligent” hubs in secure locations.

ARP Spoofing

A more common form of spoofing that is accidental is ARP spoofing. ARP (Address Resolution

Protocol) is part of Ethernet and some other similar protocols (such as token-ring) that associate hardware addresses with IP addresses. ARP is not part of IP but part of these Ethernet-like protocols; ARP supports IP and arbitrary network-layer protocols. When an IP datagram is ready to go out on such a network, the host needs to know the hardware destination address to associate with the given IP destination address. For local IP destinations, the hardware address to use will be the hardware address of the destination interface. For non-local destinations, the hardware address to use will be the hardware address of one of the routers on the local network.

How ARP and ARP Spoofing Work

To find the hardware address, the host sends out an ARP request using the hardware broadcast address. A frame with the hardware broadcast address reaches every network interface on the local network, and each host on the local network has its operating system interrupted by the network interface. The ARP request is essentially asking the question, “What is the hardware address corresponding to the IP address I have here?” Typically, only the host with the matching IP address sends an ARP reply and the remaining hosts ignore the ARP request. The ARP request contains the IP address of the sender of the request and reaches all hosts via a broadcast.

Other hosts could potentially store the association between hardware address and IP address of the sender of the request for future reference. The target of the request certainly would store the association. It will almost certainly send an IP datagram in reply to the IP datagram it is about to receive. The reply will require knowing the association between the IP address and the hardware address of the sender of the ARP broadcast.

The association between the hardware address and the IP address of other machines on a network is stored in an ARP cache on each host. When an IP datagram is about to leave a host, the host consults the ARP cache to find the destination hardware address. If the host finds an entry for the IP destination address, it need not make an ARP request. The entries in an ARP cache expire after a few minutes.

Thus, when the ARP cache entry for a machine expires, an ARP request goes out to refresh the entry. No reply comes back if the target machine goes down. The entries for its interface’s hardware will disappear from the ARP caches in the other machines on the network. The other machines will be unable to send out IP datagrams to the downed system after the ARP cache entries expire. Before that point in time, IP datagrams are sent out but are not received. When the machine comes back up, it will again be able to reply to ARP requests. If someone replaces its interface, the now up and running machine will have a new hardware address and will use that new hardware address in ARP replies. ARP caches throughout the network will reflect the change, and IP datagrams go out using the new hardware address.

Because you expect the IP address to hardware address association will change over time, the potential exists that the change may be legitimate. Sometimes it is purely accidental. Someone may inadvertently assign a machine the same IP address held by another machine. On personal computers or special purpose devices such as network printers or X Window System terminals,

the end user typically has access to a dialog box, command, or text file that sets the IP address.

On multiuser systems, the system administrator is typically the only one who can set the IP addresses of the network interface(s). This arrangement is changing, however, as more inexperienced IP-based end users with PCs set addresses. In addition, bureaucracies often separate system administrators and network administrators that use the same network. Under such circumstances it is common for two machines to end up with the same IP address. Duplication can occur either by copying the network configuration from one personal computer to another without the end user knowing the need for IP addresses to be unique. Duplication can also occur if system administrators on a network do not work together when configuring system addressing.

When two machines end up with the same IP address, both of them will naturally reply to an ARP request for that address. Two replies to the request come back to the host that originated the request. These replies will arrive in rapid succession, typically separated by at most a few milliseconds. Some operating systems will not realize anything is wrong and simply file each reply in the ARP cache with the slowest response remaining in the ARP cache until the entry for  that IP address expires. Other operating systems will discard ARP replies that correspond to IP  addresses already in the cache. These may or may not bother to check if the second reply was a harmless duplicate or an indication an ARP spoof may be underway.

Thus, depending on the mechanism used to process duplicate ARP replies, if a spoofer wants to be the target of the IP datagrams being sent to a particular IP address from a particular host, it needs to make sure it is either the first or the last to reply to ARP requests made by that particular host. An easy way to be first or last is to have the only machine that replies to the ARP requests. An attacker can simply use a machine assigned, via the normal operating system configuration mechanisms, the same IP address as a machine that is currently not working. An attacker attempting to masquerade his or her machine can simply turn the legitimate machine off. The attacker does not need to have direct access to the power switch on the machine. The machine can be turned off either by unplugging it or flipping the appropriate circuit breaker. An alternative to disconnecting its power is to disconnect it from the network at some point in the network wiring scheme. Third, the attacker can change the legitimate machine’s IP address and leave it turned on if he or she can reconfigure the machine. Doing so is less likely to draw attention or result in confusion from the machine’s user or administrator.

Zero-Knowledge Authentication

Another mechanism for secure authentication without passwords is zero-knowledge proofs.

Networks that use this system have a client and a server that share what is in essence a very long sequence of digits. When the client connects to the server, the server queries the client about a set of digits in a small set of positions in the sequence. Because the number of digits in the sequence is very long, knowledge of a few digits by a sniffer is not sufficient. The server will query for a different set of positions each time the client connects.

This type of authentication is growing in popularity. You store the digit sequence held by the client on a credit card sized device or even in a ring worn by the user. No computer needs to be carried by a mobile user of this technique; only a few kilobytes of data storage.

RFC 1704 and RFC 1750 provide a good background in the principles of authentication and the current state of encryption technology for the Internet.

DESlogin 1.3 uses a challenge / response technique in conjunction with DES encryption for authentication. The latest version is available via anonymous FTP from ftp.uu.net/pub/security/des.

S/KEY from Bellcore uses the response / challenge technique as well. S/Key is available via anonymous FTP to thumper.bellcore.com in the /pub/nmh directory. S/Key has support for a variety of platforms, including Unix, Macintosh, and Windows, to generate the onetime password used as a response to a challenge. It also includes a replacement for /bin/login and the FTP daemon on the Unix host.

RFC 1760 describes the system in technical detail.

Using Encrypted Passwords

Another solution is to use encrypted passwords over the network. You must use caution, however, when simplifying this technique. Even with encryption, a sniffer can still record the encrypted password and decipher the encrypted password at his or her leisure. One way  round

this is to use an encryption key that involves the current time. If the sender and receiver are closely synchronized, the sniffer must replay the encrypted password within one tick of the two machines’ shared clock. If the sender and receiver are widely separated, however, this  technique becomes less practical and effective because shared clocks will lack sufficient time resolution to prevent an attacker from using a quick replay. One way around this lack of close synchronization is to set a limited number of attempts at typing the password correctly.

It also does not suffice to simply encrypt the password with an algorithm using a key that allows an attacker to determine the encryption key. The attacker would decrypt it for repeated use at a later time. Some protocols use an encryption technique equivalent to the one used by the Unix password program when it stores passwords in the password file. This encryption technique is no longer considered particularly secure against brute force cryptographic attacks where all likely passwords are encrypted with the same algorithm used by the password file.

Any two words that encrypt the same must be the same. Hence, poorly chosen (for example, dictionary words) or short passwords are particularly easy to crack by brute force. What is required is the use of public key cryptography such as PGP. In public key cryptography (also called asymmetric cryptography), you use separate keys for encryption and decryption—the decryption key is not computable from the encryption key. The server can send the client its public key and the client can use that key to encrypt the user password.

The server then decrypts the password to verify the authenticity of the user. This is a variation on the classic public key system in which a trustworthy third party holds the public keys, but it simplifies the case when no mutually trusted third party is available. It also allows the server to use a time-dependent public key to prevent password replay or brute force decryption of a relatively short password.

The use of Kerberos also prevents cleartext passwords from being sent across the network. Kerberos is a comprehensive authentication system using a sophisticated time varying encryption algorithm and requires that both systems at the ends of a communication connection trust a separate security server to negotiate the authentication. This avoids having servers trust clients to do the authentication, as the rlogin protocol must do. See Chapter 9 for more information on Kerberos.

The rlogin Family of Protocols

The rlogin protocol, originally used with Unix-to-Unix terminal sessions, uses end-to-end mutual trust to avoid the transmission of any form of password. The protocol requires that the server trust the client to authenticate the user. The user places a file on the server indicating what combinations of username and hostname may connect to a particular account on machines using the server. The user may connect from these without presenting any further credentials such as a password.

The user must trust that the server is sufficiently secure, that no one else can alter the rhosts file and that no one else can read the rhosts file. The requirement that the rhosts file not be altered is obvious—if someone modified the rhosts file, he or she could connect to the account via the rlogin protocol without the permission of the legitimate user. The requirement that no one else can read the rhosts file is a bit more obscure, but learned from painful experience. If an attacker gains access to another account on the machine hosting the rlogin server, the attacker can read the rhosts file of a user and target the user for an indirect attack. In an indirect attack, the attacker attempts to gain access to an account listed in the rhosts file on another machine and use it to obtain access to the machine hosting the rlogin server.

Another file used by some servers for the rlogin protocol is called the host equivalence file, which is named “/etc/hosts.equiv” in the original Unix implementation. Any user of any host listed in the host equivalence file may access an account with the same username on the machine on which the host equivalence file exists without presenting a password. The use of a host equivalence file adds convenience for the user by relieving individual users from the need to create their own rhosts file. However, it opens up users to the risks of ARP spoofing and name server spoofing (both covered later in this chapter) without the implicit consent they give to that risk when creating their own rhosts file. System administrators are strongly urged not to use a host equivalence file because of those risks. Users without the network savvy to create an rhosts file are being put at risk from a threat they have no possibility of understanding.

The rlogin protocol remains vulnerable to ARP spoofing and DNS spoofing

It also does not completely protect a user who uses machines that he or she does not control. For example, when you start an rlogin terminal session from a client’s or colleague’s office, the client’s or colleague’s machine is not listed in your rhosts. In these cases, you must remember my password and have it transmitted across the network in plain sight of any sniffers that may be out there.

Problems with rlogin

As mentioned earlier, on a machine with any server for programs in the rlogin protocol family it is critical that only the user can modify his or her rhosts file. If it is possible for someone else to modify it then the ability to modify it can be leveraged into the ability to obtain full access to the account. Note that if your home directory is on an NFS mounted file system exported to someone else’s machine your rhosts file is vulnerable to simple attacks on NFS. A standard attack for the superuser of another machine is to give you an account on the other machine and then use the su command to gain access to your account on the other machine. The NFS server is fooled into believing you are accessing your files because it trusts the other machine to authenticate its users. So far, the attacker is limited to accessing your files, but when he alters your rhosts file the attacker can begin to run programs that execute with your privileges and do greater harm.

If an attacker is able to modify the superuser rlogin file or gain access to any account listed in it, such access can be leveraged into a very serious attack. In particular, an attacker can use rsh to subvert the requirement that Unix superuser logins occur from secure terminals. Unlike rlogin or telnet, rsh does not require a pseudo-tty. If protection of your superuser login account involves restricting insecure terminals, you may want to disable or alter the rsh program.

Do not confuse the rexec commands (rexec and rcmd) with the r-commands. The rexec daemon waits for a username and cleartext password to authenticate a client. It will then execute a single shell command. Although this is similar to rsh, rexec requires the transmission of a cleartext password to be sniffed. Also, it provides two distinct error conditions, one for an invalid username and one for an invalid password. Hence, a brute-force attack can be mounted by attempting all possible usernames to both determine what usernames are valid and which users have no password. A standard login program will not provide this distinction and provide a mechanism to prevent rapid-fire attempts to log in. Security conscious system administrators often disable the rexec daemon and rexec commands are so seldom known about by users as not to be missed.

Avoiding Transmission of Passwords

In some sense, the prevention of sniffing by installing hardware barriers may be considered the last line of defense in a security system. When building medieval fortresses, the last line of defense was typically the most formidable but could only protect those who would be left inside after the outer defenses had been breached.

In dealing with sniffing, the first line of defense is simply not to transmit anything sensitive on the network in the first place. 

The local hardware defenses may limit intrusion into the local systems. 

However, if authorized users may access those systems from remote locations, one must not transmit sensitive information over remote parts of the Internet lest the information be sniffed somewhere along the way. One extreme that preserves security is simply not to permit access from remote locations. 

Also, the most formidable defenses against inward directed attack do nothing to provide for the security of one leaving the area being protected. Legitimate Internet sessions initiated inside a network with those outside must also be protected.

The most glaring security hole beyond simple loss of privacy is the opportunity for a sniffer to gather passwords. The best way to deal with this problem is simply not to transmit cleartext passwords across the network. Simply transmitting an encrypted password that could be captured and replayed by a sniffer is also not acceptable. Several different methods are in use to provide this kind of protection:

• The rlogin family of protocols
• Using encrypted passwords
• Zero knowledge authentication

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.

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.

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

Figure 1

 

Figure 2

Sniffing How to Prevent It

Sniffing How to Prevent It

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.

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.