Security Training
Security Certification
Cyber Security Graduate School
Internet Storm Center
Security Awareness Training
Computer Forensics
Penetration Testing
IT Audit
Software SecurityIntrusion Detection FAQ: Why your switched network isn't secure.
| Steven Sipes September 10, 2000 The arsenal of tools available for both protecting and penetrating our environments is daunting in both quantity and ability. Some of these tools are highly specialized in purpose while other are multipurpose and serve as building blocks for a larger toolkit. One such tool is the network sniffer. Network sniffing, in its most general form, consists of intercepting frames from the network and viewing their contents. The ability to do this has been widespread for some time and was used by everyone from network administrators (who were troubleshooting problems) to crackers (who were pulling passwords and files from the wire). If we gauge our timeframe by the release dates of some of the more recent sniffing tools, it was only recently that network sniffing was publicized to be possible on a switched network. This delay in information dissemination led to the, still prevalent, train of thought that migrating your environment to a switched network would prevent anyone from sniffing your network traffic (unless, of course, they could connect to the backplane/uplink port on your switch). Needless to say, through the efforts of the security community (or the anti-security community, depending on your point of view), tools have surfaced which allow for network sniffing on switched networks. To gain a better understanding of this, we need a brief explanation of how non-switched networks work and how they are sniffed. I'll then move on to show how switched networks work and show how they are sniffed. I'll finish with a discussion of how to protect your traffic in both non-switched or switched environments. In the non-switched network environment, we carry the concept of a network segment. A segment1 is a network architecture that resides behind a router, bridge, hub or switch in which every node is directly addressable from every other node. In the non-switched environment, frames are handled in a broadcast manner. That is, when one node transmits a frame, it is 'seen' by every node on the segment. Each node, in turn, will briefly exam the frame to see if it is addressed to them. If not, it is discarded. However, if they are the intended recipient, they accept the frame for processing. I liken this to a (now uncommon) party-line phone call where a single phone call can simultaneously ring multiple phones. Everyone answers and, after determining that the call is not for them, hangs up (at least, they hang up if they respect the privacy of others sharing the party-line). For the purposes of this paper, Node B will be designated as the host to be used as a sniffing agent. Node A and Node C will represent the 'innocents' who are merely trying to communicate with each other. This is shown in Figure 1. 
The normal flow of traffic in a non-switched network is as follows:
In order for a host to be used as a sniffing agent, the network interface must be set to 'promiscuous' mode. Setting this mode requires root or administrator access. After this mode is set, the network interface will no longer drop network frames which are addressed to other hosts. Rather, it will pass them up to the higher network layers with the expectation that some software at a higher layer will process them. In referencing Figure 1, the steps of this process would be as follows:
You can see that the non-switched environment lends itself quite nicely to sniffing. It requires little extra effort on the part of the sniffing agent since the hub broadcasts the frames to all active ports. Several sniffing utilities exist. Some of the publicly available tools used to sniff non-switched networks include:
In the switched network environment, we still carry the concept of a network segment, but the segment includes only the node and the switch. Data frames are handled in a direct manner. That is, frames from Node A to Node C are only sent across the circuits in the switch that are necessary to complete a connection between Node A and Node C. I liken this to a common person-to-person call in which Person A calls Person C. This is shown in Figure 2. 
This mode of operation carries some intrinsic benefits:
One of the basic operations of the Ethernet protocol revolves around ARP (Address Resolution Protocol) requests and replies. In general, when Node A wants to communicate with Node C on the network, it sends an ARP request. Node C will send an ARP reply which will include the MAC address. Even in a switched environment, this initial ARP request is sent in a broadcast manner. It is possible for Node B to craft and send an unsolicited, fake ARP reply to Node A. This fake ARP reply will specify that Node B has the MAC address of Node C. Node A will unwittingly send the traffic to Node B since it professes to have the intended MAC address. Some available tools are specialized for sending fake ARP replies to classes of machines (i.e., NFS servers, HTTP servers, etc). One such tool is dsniff5 and it works well to sniff for specific types of traffic. Other tools listen for the general ARP request and send the fake ARP reply at that time. The parasite4 program falls into this category and it serves well to sniff the entire network. For this type of attack to work, we need the ability to forward on the frames we receive to their intended host. This is most commonly achieved through some type of IP forwarding, either at the kernel or application level. Since switches are responsible for setting up the virtual circuits from one node to another, they must keep a translation table that tracks which addresses (specifically, which MAC addresses) are on which physical port. The amount of memory for this translation table is limited. This fact allows the switch to be exploited for sniffing purposes. On some switches, it is possible to bombard the switch with bogus MAC address data. The switch, not knowing how to handle the excess data, will 'fail open'. That is, it will revert to a hub and will broadcast all network frames to all ports. At this point, one of the more generic network sniffers will work. It's not difficult to imagine that, since all frames on the network are routed based on their MAC address, that the ability to impersonate another host would work to our advantage. That's just what MAC duplicating does. You reconfigure Node B to have the same MAC address as the machine whose traffic you're trying to sniff. This is easy to do on a Linux box if you have access to the 'ifconfig' command. This differs from ARP Spoofing because, in ARP Spoofing, we are 'confusing' the host by poisoning it's ARP cache. In a MAC Duplicating attack, we actually confuse the switch itself into thinking two ports have the same MAC address. Since the data will be forwarded to both ports, no IP forwarding is necessary. There are several methods to protect again these attacks. Some of these methods are applicable to both the non-switched and switched environments. By enabling IP filtering on your switch, you directly specify which traffic is allowed to flow to and from each port. This can be a monumental effort to put in place and manage, especially if your environment is dynamic. If your hub or switch has the ability to enable port security, this will help to protect you from both the MAC Flood and MAC Spoofing attacks. These feature effectively prevents the hub or switch from recognizing more than 1 MAC address on a physical port. This, like many security procedures, restricts the environment and amplifies the need for a management process as well as a auditing process. Routing should only be performed by the designated routers. That is, no workstations should be allowed to run a routing protocol as they may be compromised. Also, it goes without saying that management of any of your network gear should be through a secure connection and not through telnet which passes the administrative login/password in cleartext. I believe this examination provides another justification for 'defense-in-depth'. Networks are an infrastructure enabler for us to perform our daily functions. The general networks we use were never meant to be used as a security feature; although, they continue to be used in this manner. Providing a managed network infrastructure is a key component of any good defensive position. While compromising a single host may gain the attacker access to a few systems, the ability to sniff userids and passwords for several machines will effectively give away the keys to the kingdom. Network managers must be aware that they have 2 realistic options. They can either manage the network appropriately and be part of the team trying to protect the environment, or they can configure the environment so that it is 'hands-off' or 'self-maintaining' which, traditionally, translates into lax security. "Webopedia" http://webopedia.internet.com/TERM/s/segment.html "AntiCode Website" http://www.AntiOnline.com/cgi-bin/anticode/anticode.pl "Insecure Website" http://www.insecure.org/ van Hauser. "Parasite 0.5" http://thc.inferno.tusculum.edu/files/thc/parasite-0.5.tar.gz Song, Dug. "Dsniff" http://www.monkey.org/~dugsong/dsniff/ Dsniff mailing list: Send an email to dsniff-request@monkey.org with 'subscribe' as the subject |
Check Them Out!
This was by far the best course I have ever taken.
-Peter Lombars, Intrucom Inc.
