Layer 2 Security Considerations
As you learned in Chapter 3, "Secure Networking Threats," certain attacks run at Layer 2 (L2) of the OSI model. Oftentimes, your posture toward L2 attacks depends on the physical security of the location and the amount of trust you have in users, as defined by your security policy. This section discusses some common design considerations for L2 protocols. The discussion is focused on Ethernet, but most of these issues apply to wireless networks as well.
L2 Control Protocols
Control protocols are usually at the core of any L2 security issue. This section discusses design considerations around L2 control protocol usage. Basic understanding of these protocols is assumed. There are two main topics in this section: the first covers industry-standard protocol considerations; the second covers Cisco-specific protocols.
General Protocol Considerations
This section covers the standard protocols 802.1q, Spanning-Tree Protocol (STP), and briefly mentions 802.1x.
802.1q
The 802.1q standard specifies a standard mechanism for Ethernet switches to exchange virtual LAN (VLAN) information. It adds a 4-byte tag after the source and destination Media Access Control (MAC) addresses. The first 2 bytes act as an Ethernet tag protocol identifier. The second 2 bytes contain all the interesting information. Twelve bits are used as a VLAN identifier (yielding 4096 choices), and 3 bits are used as a priority identifier (in the 802.1p standard). The addition of 4 bytes to the Ethernet packet increases the maximum size of an Ethernet frame from 1518 bytes to 1522 bytes.
When designing a network to take advantage of 802.1q tagging, there are a few security concerns that must be addressed:
802.1q has had several implementation flaws in various vendors' equipment over the years. Details of an old Cisco vulnerability can be found here: http://www.sans.org/resources/idfaq/vlan.php. Many of these problems have been fixed, and vendors are beginning to pay more attention to security, particularly as VLANs play a greater role in any network design.
When using VLANs, the potential for human error increases because the operator must keep track of "virtual" LANs that might not have distinct cable plants associated with them. This can get particularly nasty when you try to remember which VLAN number is the outside of your firewall as opposed to the inside. Good management tools can mitigate the impact of this concern.
Some attacks that use 802.1q as an attack method are detailed in a later section of this chapter titled "VLAN Hopping Considerations."
STP
Spanning-Tree Protocol (STP) is a L2 loop avoidance mechanism. Without STP, redundant L2 links would cause large forwarding loops and massive performance problems. From a security standpoint, STP has a few design characteristics of interest.
First, STP has no provisions for authentication of the bridge protocol data units (BPDUs) that are sent from switches and bridges as they exchange STP information. These BPDUs could easily be sent from an unauthorized device that could have any number of undesirable effects.
To start with, if the attacker can cause a failure of a link in the forwarding state, it generally takes 30 to 45 seconds for STP to deal with the failure and reconverge the topology. Some switches now include features to deal with this problem. On Cisco devices, the features are called port fast and uplink fast.
Second, for there to be some "authority" in the STP network, the participating switches elect a root bridge. It is from this bridge that the loop-free topology is built. The method for determining the root bridge is generally through STP configuration messages, which indicate the bridge priority of a given switch. The lowest number becomes the root bridge. If an attacker is able to send out BPDUs from his station, he can send out a configuration message with a bridge priority of zero. This will likely make his system the root bridge and will often change which links are active on a given network (since the topology is redetermined from the perspective of the new root bridge). No special tools are needed to do this; some UNIX implementations come with Ethernet bridging utilities that allow them to configure their system as a bridge with full participation in the STP process. As an example, consider the following topology in Figure 6-1.
)
Figure
6-1 Starting Topology
In the figure, you can see that the attacker has established two links to two different L2 switches. F denotes a link that is forwarding; B is a link that is blocked because of STP. This could easily be done by walking a long cable to another jack in a building or by using a WLAN network (if it was poorly designed). From here, you can see that one of the attacker's links is in the blocking state. This is exactly what STP should do to prevent loops. However, the attacker then sends BPDUs advertising himself as bridge priority zero. This causes STP to reconverge and the attacker to become the root bridge. A topology that looks like the one in Figure 6-2 results.
)
Figure
6-2 Resulting Topology
Because the topology is built from the perspective of the attacker, you can see that all traffic that must pass between the switches flows through the attacker's PC. This allows an attacker any number of options, as outlined in Chapter 3. The most obvious are sniffing traffic, acting as a man-in-the-middle, or creating a denial of service (DoS) condition on the network. The DoS condition is achieved because the attacker can make his links much slower than the links between the two access switches, which could very likely be connected by gigabit Ethernet.
NOTE
You might ask, "Doesn't STP take into account bandwidth speed when determining the topology?" It does but always from the perspective of the root bridge. While testing in the lab, I was able to take a full-duplex gigabit link between two access switches and reduce it to a half-duplex 10 megabit (Mb) connection between those access switches and the attacking PC. This is never good for a production network.
Fortunately, mitigating this attack is fairly straightforward. First, some advocate disabling STP in all cases in which you don't have network loops. Although this sounds like a good idea, the attacker could instead introduce a loop into your network as a means of attack. A better option is to filter which ports are allowed to participate in the STP process. Some switches offer the ability to do this today. On Cisco devices, the two principal options are BPDU Guard and Root Guard.
BPDU Guard
BPDU Guard can be globally enabled on some Cisco switches and is in effect on any port configured with the port fast option. Port fast ports are generally user ports. What BPDU Guard does is disable any port fast port that receives a BPDU message. Because these are user ports, there should be no reason for BPDU messages to be sent to them. The syntax is as follows:
CatOS> (enable)set spantree portfast bpdu-guard enable IOS(config)#spanning-tree portfast bpduguard
Root Guard
The other option you have is Root Guard. Root Guard can be enabled or disabled on any port and works by disabling a port that would become the root bridge as a result of its BPDU advertisement. This is less restrictive on users because it allows them to plug in an Ethernet switch in their workspace (in case they have more than one PC). The syntax for Root Guard is as follows:
CatOS> (enable) set spantree guard root 1/1 IOS(config-if)#spanning-tree guard root (or rootguard)
NOTE
I learned about BPDU Guard the hard way. I was setting up a small lab in my office to do some testing, and I needed more ports than I had available. I plugged in an Ethernet switch and promptly lost link on my connection. Puzzled, I went to the IT staff, who informed me that BPDU Guard was running to prevent unauthorized STP advertisements. After getting my port reset, I went back to my office and turned off STP on my small switch. Problem solved.
802.1x
The standard 802.1x specifies a mechanism to do port-based access control in an Ethernet network. For example, before granting access to a user who connected to a port in one of your conference rooms, you could have 802.1x require authentication first. Upon authentication, the user could be assigned to a specific VLAN based on the user's access rights. The 802.1x standard could be used in the future to perform additional security checks, perhaps enforcing an access control list (ACL) for the user or a quality of service (QoS) policy. The 802.1x standard is covered further in Chapter 9.
Cisco-Specific Protocols
Over the years, Cisco Systems has developed a number of proprietary protocols that have been used to perform different functions on an L2 network. Most of these protocols use an IEEE 802.3 frame format with an 802.2 SNAP encapsulation. Most have a Logical Link Control (LLC) of 0xAAAA03 (indicating SNAP) and the Cisco Organizational Unit Identifier (OUI) 0x00000c. The majority use a multicast destination MAC address to communicate. This is generally a variation on 0100.0ccc.cccc. The SNAP protocol type varies and generally is included in each protocol discussion where appropriate. Knowing the specifics of these protocols should make it easier to identify them on the network when troubleshooting using a sniffer. Figure 6-3 shows in detail the frame format of most Cisco L2 protocols.
)
Figure
6-3 802.3 with 802.2 SNAP Frame Format
Of special note is the unique relationship two of these protocols have with VLAN 1 on Cisco switches. Cisco Discovery Protocol (CDP) and VLAN trunking protocol (VTP) are discussed in more detail later. Both of these protocols communicate over VLAN 1 only. Even if VLAN 1 is not used on a trunk port, these protocols continue to pass information on VLAN 1. For this reason, and the fact that VLAN 1 cannot be deleted, it is not recommended to use VLAN 1 for user or trunk ports. More information on this topic can be found here: http://www.cisco.com/warp/public/473/103.html.
Interswitch Linking (ISL)
Long before 802.1q, Cisco switches were capable of trunking multiple VLANs over a single link using ISL. ISL use is in decline because there is now an adequate standard to replace it. Instead of using a 4-byte field in the Ethernet frame, ISL reencapsulates the packet with a new Ethernet header, adding 26 bytes to the packet (10 bits is used for the VLAN ID). If you remember, 802.1q adds only 4 bytes to each packet (including priority by 802.1p) and, as such, is a more efficient protocol. Although it is not recommended to build a new network from scratch using ISL, many existing networks run ISL. The security issues around ISL are virtually identical to those of 802.1q.
Dynamic Trunking Protocol (DTP)
To help switches determine whether they should be trunking, Cisco developed DTP. DTP exchanges information between switches, notifying each other of their preferences regarding trunking for a given link. Settings such as auto, on, off, desirable, and non-negotiate determine whether a given L2 switch will trunk on a given link. DTP uses a destination MAC address of 0100.0ccc.cccc and a SNAP protocol type of 0x2004. Cisco Catalyst 2900XL and 3500XL switches do not support DTP.
DTP is important from a security perspective because the default DTP state of many switches is auto. This means that they will happily trunk (pass traffic on multiple VLANs) with anyone who notifies them that they would like to do so. DTP spoofing is a part of the attacks described in the "VLAN Hopping Considerations" section later in this chapter. To mitigate attacks that use DTP, it is recommended that you set all ports without a need to trunk into the DTP off state. The syntax for these commands is as follows:
CatOS> (enable) set trunk <mod/port> off IOS(config-if)#switchport mode access
If you aren't sure whether your switch defaults to autotrunking or not, you can check the trunk status of your ports with the following commands:
CatOS> (enable) show trunk [mod|mod/port] IOS#show interface type number switchport
VLAN Trunking Protocol (VTP)
Oftentimes, it can be a burden to manage a large L2 network with lots of VLANs spread around different switches. To ease this burden, Cisco developed VTP. VTP allows an administrator to configure a VLAN in one location and have its properties automatically propagated to other switches inside the VTP domain. VTP uses a destination MAC address of 0100.0ccc.cccc and a SNAP protocol type of 0x2003. VTP uses the notion of a client and a server to determine which devices have rights to propagate VLAN information in what direction.
I'll be honest, having my VLAN information automatically propagate to my different switches doesn't fill the security part of my brain with glee. Start by strongly considering whether VTP is going to save you time or cause you headaches. If all your VLANs have similar security levels, perhaps VTP could be helpful to you. But if instead you have different security levels on your VLANs and certain VLANs should only exist on certain switches, it is probably easier, and safer, to manually configure each VLAN where you need it.
If you must use VTP, be sure to use it with the MD5 digest option. This adds a 16-byte MD5 digest of the VTP packet combined with a password and makes it much harder for an attacker to send you bogus VTP information causing your VLANs to be reconfigured. Without the MD5 authentication, an attacker could be disguised as a VTP server with all VLANs deleted. This could cause all switches in your entire network to remove their VLAN configuration. Not a good thing for security at all! The syntax for configuring a VTP password is as follows:
CatOS> (enable) set vtp [domain domain_name]
[mode {client | server | transparent | off}] [passwd passwd]
[pruning?{enable | disable}] [v2 {enable | disable}]
IOS(config)#vtp password password-value
VLAN Query Protocol (VQP)
Prior to the establishment of the IEEE 802.1x standard, Cisco developed a technology called the VLAN Management Policy Server (VMPS). VMPS works with a flat file policy database that is sent to VMPS server switches by TFTP. VMPS client switches then communicate with the VMPS server using VQP. VMPS allows a switch to dynamically assign VLANs to users based on their MAC address or user identity (if used with the User Registration Tool [URT]).
Unfortunately, VQP is a UDP-based protocol that does not support any form of authentication. This makes its use in security-sensitive environments inadvisable. An attacker who is able to spoof VQP (not hard since it runs UDP) could then try to prevent network logins or might join a VLAN unauthorized.
VQP and VMPS are rarely used for MAC-based VLAN assignment because of the management burden of maintaining the MAC address to VLAN mapping table. The URT component is also not frequently used, especially since a standards-based method of effectively doing the same thing (802.1x) is now available.
CDP
To allow Cisco devices to exchange information about one another's capabilities, Cisco developed CDP. CDP uses a destination MAC address of 0100.0ccc.cccc and a SNAP protocol type of 0x2000. By default, most Cisco routers and switches have CDP enabled. CDP information is sent in periodic broadcasts that are updated locally in each device's CDP database. Because CDP is an L2-only protocol, it (like any other L2 protocol discussed here) is not propagated by routers. Some of the types of data propagated by CDP include the following:
L2/L3 capabilities
Hostname
Native VLAN
Duplex setting
Software version
VTP domain settings
Figure 6-4 is a portion of an Ethereal packet trace showing the inside of a CDP packet.
)
Figure
6-4 CDP Example Packet
From a reconnaissance standpoint, all of the preceding information could be useful to an attacker. The software version, in particular, would allow the attacker to determine whether there were any specific security vulnerabilities with that particular version of code. Also, since CDP is unauthenticated, an attacker could craft bogus CDP packets and have them received by the attacker's directly connected Cisco device.
So, with an understanding of the security risks, why don't you just turn CDP off completely? Many network operators do, but it is important to realize that Cisco developed CDP for a reason. Some network management applications make use of it, as do Cisco IP telephones. If you must run CDP on your network, consider using it on only the ports that require its use. For example, many networks need CDP only on backbone links and not user links. This would allow you to turn off CDP on user ports, preventing many of the attacks discussed in the preceding paragraph. The syntax to disable CDP on a router or a switch is as follows:
CatOS> (enable) set cdp disable <mod>/<port> | all IOS(config)#no cdp run IOS(config-if)#no cdp enable
MAC Flooding Considerations
Every L2 switch needs some mechanism to record the port to which a given MAC address is connected. This ensures that unicast communication between two hosts can occur without other hosts seeing the traffic. One common method of recording this information is the use of a Content Addressable Memory (CAM) table. A CAM table stores the MAC addresses and VLAN assignments of various hosts connected on a switch. Think of it much like a routing table for a router, only at L2.
When a frame arrives at a switch, a number of things happen. The sequence we refer to here is specific to the CAM table and frame switching:
The frame arrives at the switch.
The source MAC address is inspected to determine whether there is already an existing entry in the CAM table. If so, the switch proceeds to the next step; if not, an entry is added to the CAM table for the source MAC address. This way, when anyone needs to talk to that MAC address again, the switch remembers which port to send the frame to reach the destination.
The destination MAC address is inspected to determine whether there is already an existing entry in the CAM table. If so, the frame is switched out of that destination port and on to the host. If not, the switch proceeds to step 4.
The switch floods the frame on all ports that are members of the same VLAN as the originating host.
When the intended recipient of the frame receives the packet, it responds (assuming the protocol is two-way), and the switch repeats this process from step 1. The switch adds an entry in the CAM table for the source MAC of this frame (the destination MAC of the previous frame). All further unicast communications between these two hosts are sent on only the port to which each host is connected.
The preceding illustrates how it is supposed to work. A security-conscious network designer must be aware of a few things:
CAM tables have a limited size. Depending on the switch, this can be anywhere from 100 or so entries to over 100,000 entries.
Entries in the CAM table have an aging timer. Each time a frame is transmitted with a source MAC address matching the current entry in the CAM table, the aging timer is reset. If a given host does not send frames on the switched network, the network eventually deletes the CAM table entry for that device. This is of particular interest for one-way protocols such as syslog. If your syslog server does nothing but receive UDP syslog messages, its CAM entry will begin to age once it responds to the original Address Resolution Protocol (ARP) query sent by a host or router. Once aged, all packets destined for it are always flooded on the local VLAN.
Attack Details
Given the previous explanation of how a CAM table works, let's look at how the CAM table design can be attacked:
An attacker connects to a switch port.
The attacker sends a continuous set of frames with random source MAC addresses and random destination MAC addresses. The attacker is really concerned with making sure steps 1 and 2 of the preceding list repeat constantly, each time with a different MAC address.
Because CAM tables have limited size, eventually the switch will run out of room and not have any more space for new MAC addresses.
A victim host (connected to the same VLAN as the attacker) tries to communicate with a host that does not currently have a CAM table entry.
Since there is no more room in the CAM table for the host without an entry, all communications to that host must be flooded.
The attacker can now see all the traffic sent from the victim host to the host without a CAM table entry. This could include passwords, usernames, and so forth, which then allows the attacker to launch the next attack.
This attack is important because Ethernet switches were originally thought to increase security because only the ports involved in a particular communication would see the traffic. Furthermore, if the attacker runs this attack continuously, even active hosts might soon start flooding as the aging timer expires during periods of inactivity. The attacker can further accelerate this process by sending an STP BPDU with a Topology Change Notification (TCN) message (such as when an attacker tries to become the root bridge). Such a message will cause the aging timer on most switches to temporarily shorten. This is needed so the switch doesn't keep stale information that is no longer valid after the STP topology change. For example, many Cisco switches have a default aging timer of 300 seconds. When a Cisco switch receives a TCN message, it automatically reduces the aging timer for every entry to 15 seconds.
As mentioned in Chapter 3, there are several popular tools that automate this attack. The most common is macof, written in 1999 by Ian Vitek in about 100 lines of Perl. This code was later ported to C by Dug Song for his dsniff tools. In a very basic lab test, I was able to generate 155,000 MAC entries per minute using a stock Linux box.
There are a few caveats to this attack that you should be aware of:
Even with a completely full CAM table, traffic is flooded only on the local VLAN, meaning traffic on VLAN 10 stays on VLAN 10, but everyone with a port on VLAN 10 will see the traffic.
Because of the flooding, this attack could also flood the CAM table on adjacent switches.
Because of the sheer quantity of traffic the attacker sends, this attack might also result in a DoS condition on the network.
Attack Mitigation
Stopping this attack isn't too difficult, but it isn't quite as simple as flipping a switch. Many switches offer the ability to do something called port security. Port security works by limiting the number of MAC addresses that can communicate on any given port on a switch. For example, say you are running switched Ethernet to the desktop in your environment. Each host has its own connection on the switch. Here, you might configure port security to allow only one MAC address per port. Just to be safe, you might allow two or three in case locations add a small hub to connect a test system. Port security works by learning the number of MAC addresses it is configured to allow per port and then shutting down the port if it exceeds the limit. In the case of the macof tool, it would be stopped dead in its tracks. You configure port security in the following way:
CatOS> (enable) set port security mod/ports... [enable | disable] [mac_addr]
[age {age_time}] [maximum {num_ of_mac}] [shutdown {shutdown_time}]
[violation{shutdown | restrict}]
IOS(config-if)#port security [action {shutdown | trap} | max-mac-count addresses]
Note that there are a lot of other options that aren't really necessary for stopping CAM table flooding. For more information on port security, you can look here: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/config/sec_port.htm.
For example, here's a configuration in Cisco CatOS to limit ports to two MAC addresses:
CatOS> (enable) set port security 3/1-48 enable maximum 2
This uses the default of a permanent shutdown in the event of a violation. There are other options, such as setting a timer on how long the port is shut off or deciding instead to leave the port operational but drop any MAC addresses that aren't in the original set allowed by the switch. This latter option is inadvisable because it can create increased load on the switch while it tries to determine which traffic to pass or drop. It is also worth noting that this attack, like all L2 attacks, requires the attacker to have local access to the network because these attacks do not cross a router.
VLAN Hopping Considerations
Since VLANs were first created, there has been debate over their use in a security role. The threat of VLAN hopping (causing traffic from one VLAN to be seen by another VLAN without first crossing a router) was and is still viewed as the major risk. Designers want to know whether it is safe to design their networks as shown in Figure 6-5 instead of using additional switches as shown in Figure 6-6.
)
Figure
6-5 Questionable VLAN Edge Design
)
Figure
6-6 Edge Design without VLANs
The short answer is, assuming your Ethernet switch vendor doesn't have any security-related bugs with VLANs, VLANs can be deployed in a reasonably secure manner. Unfortunately, the precondition of no bugs is a hard state to achieve. A number of bugs have allowed VLAN hopping over the years. The best you can hope for is that any bugs that are discovered with VLAN security are quickly fixed by your vendor. Additionally, misconfigurations can sometimes allow VLAN hopping to occur, as you'll see in the following two sections.
Basic VLAN Hopping Attack
In the basic VLAN hopping attack, the adversary takes advantage of the default configuration on most switches. As we discussed in the preceding section on DTP, most switch ports default to autotrunking. This means that an attacker that can successfully trick a switch into thinking it is another switch with a need to trunk can gain access to all the VLANs allowed on the trunk port. This can be achieved in one of two ways:
Spoof the DTP messages from the attacking host to cause the switch to enter trunking mode. From here, the attacker can send traffic tagged with the target VLAN, and the switch will happily deliver the packets to the destination.
Introduce a rogue switch and turn trunking on. The attacker can then access all the VLANs on the victim switch from the rogue switch.
This basic VLAN hopping attack can be easily mitigated by turning trunking off on all ports without a specific need to trunk. The configuration settings for this are shown in the DTP section earlier in this chapter.
Creative VLAN Hopping Attacks
This section is a catchall for various methods to achieve VLAN hopping when trunking is turned off on the port to which the attacker is connected. As these methods are discovered, they tend to be closed by the vendors affected. One tricky attack will take some time to stop on all devices. You might wish to refer to the previous section on 802.1q if you need more information. The attack works by sending frames with two 802.1q tags instead of one. The attack requires the use of two switches, and the attacker and victim must be on separate switches. In addition, the attacker and the trunk port must have the same 802.1q native VLAN. The attack works like this:
The attacker sends a double-tagged 802.1q frame to the switch. The outer header has the VLAN tag of the attacker and trunk port. (For the purposes of this attack, let's assume VLAN 10.) The inner tag is the victim VLAN, VLAN 20.
The frame arrives on the switch, which looks at the first 4-byte 802.1q tag. The switch sees that the frame is destined for VLAN 10 and sends it out on all VLAN 10 ports (including the trunk) since there is no CAM table entry. Remember that, at this point, the second VLAN tag is still intact and was never inspected by the first switch.
The frame arrives at the second switch but has no knowledge that it was supposed to be for VLAN 10. (Remember, native VLAN traffic is not tagged by the sending switch as specified in the 802.1q spec.)
The second switch looks at only the 802.1q tag (the former inner tag that the attacker sent) and sees the frame is destined for VLAN 20 (the victim VLAN).
The second switch sends the packet on to the victim port or floods it, depending on whether there is an existing CAM table entry for the victim host.
Figure 6-7 illustrates the attack. It is important to note that this attack is only unidirectional and works only when the attacker and trunk port have the same native VLAN.
)
Figure
6-7 Double-Tagged 802.1q VLAN Hopping Attack
This attack is easy to stop if you follow the best practice that native VLANs for trunk ports should never be used anywhere else on the switch. For switches to prevent this attack, they must look further into the packet to determine whether more than one VLAN tag is attached to a given frame.
Unfortunately, the application-specific integrated circuits (ASICs) that are used by most switches are only hardware optimized to look for one tag and then to switch the frame. The problem of performance versus security rears its ugly head again.
TIP
You might be wondering why the switch is accepting tagged frames on a port that isn't trunking in the first place. Refer to the section on 802.1q, where we discussed that part of the 802.1q tag is the 802.1p tag for frame priority (QoS). So, to support 802.1p, the switch must support 802.1q frames.
ARP Considerations
ARP is designed to map IP addresses to MAC addresses. It was also, like most protocols still used in IP networking today, designed at a time when everyone on a network was supposed to be reasonably trustworthy. As a result, the protocol is designed around efficiently executing its task, with no provisions for dealing with malicious use. At a basic level, the protocol works by broadcasting a packet requesting the MAC address that owns a particular IP address. All devices on a LAN will see the request, but only the device that uses the IP address will respond.
From a security standpoint, there is a major limitation in ARP. ARP has no notion of IP address ownership. This means any MAC address can masquerade as any IP address provided an attacker has the right software tool to execute the attack. Furthermore, there is a special type of ARP broadcast called a gratuitous ARP (gARP). A gARP message tells all hosts on a LAN, without having been asked, what its IP–MAC binding is.
gARP is used in several legitimate ways. The most prevalent is in high-availability situations in which two systems share the same IP address but have different MAC addresses. When the primary system changes, it must notify the rest of the LAN of the new MAC address with which to contact the primary host. ARP is also used to prevent IP address conflicts. Most modern OSs send an ARP request out for the address with which they are configured when they boot. If a machine responds, they know that another node is already using their configured IP address, and the interface should be shut down until the conflict can be resolved.
Consider the following sequence outlined in Figure 6-8.
)
Figure
6-8 Misuse of gARP
In the figure, a host that is not the router is sending gARP broadcasts claiming to be the router's IP address but using its own MAC address. Hosts 2 and 3 generally ignore such a broadcast if they haven't yet communicated with the router. When they finally do, they send an ARP request for the router's MAC address. The real router (.1) will respond, but as soon as host 4 sends the next gARP broadcast claiming to be .1, hosts 2 and 3 will update their ARP entry for .1 to reflect host 4's MAC address (MAC D).
At this point, the traffic destined off of the 10.2.3.0/24 network will go to host 4's MAC address. That host could then send it to the real router, drop the traffic, sniff the traffic, or modify the contents of a packet and send it along to the real router.
Then all traffic from the hosts flows through the attacker's machine before arriving at the actual router. If desired, the attacker could also send gARP broadcasts to the router claiming to be every host on the local LAN, which allows the attacker to see the return traffic as well.
The attack described in the preceding paragraphs is the core problem with ARP. The attack described is generally referred to as ARP redirection or spoofing. Any host on the LAN can attempt to masquerade as any other host through the use of ARP and gARP messages.
dsniff is a collection of tools written by Dug Song to launch and further take advantage of this attack. For example, after launching the ARP spoofing attack, dsniff has a special sniffer designed to find and output to a file the usernames and passwords of dozens of common protocols. It even goes so far as to execute man-in-the-middle (MITM) attacks against Secure Sockets Layer (SSL) and SSH by presenting false credentials to the user. By using this attack, it becomes possible for an attacker to learn sensitive information sent over encrypted channels. More information on dsniff can be found at the dsniff website: http://monkey.org/~dugsong/dsniff/.
Mitigating ARP redirection attacks is a bit trickier. You could use private VLANs (PVLANs) as described later in this section, but this would prevent all host-to-host communication, which isn't particularly good for a network (except in specific cases such as server farms). A feature available in some Cisco switches is called ARP inspection. ARP inspection allows VLAN ACLs (VACLs) to be applied to ARP traffic flowing across a specific VLAN on the switch. A common way these VACLs are used is to make sure the MAC address of the default gateway does not change. The following ACL restricts ARP messages for two MAC–IP bindings and prevents any other MAC address from claiming ownership for those two IPs:
CatOS> (enable) set security acl ip ACL-95 permit arp-inspection host 192.0.2.1 00-d0-b7-11-13-14 CatOS> (enable) set security acl ip ACL-95 deny arp-inspection host 192.0.2.1 any log CatOS> (enable) set security acl ip ACL-95 permit arp-inspection host 192.0.2.2 00-d0-00-ea-43-fc CatOS> (enable) set security acl ip ACL-95 deny arp-inspection host 192.0.2.2 any log CatOS> (enable) set security acl ip ACL-95 permit arp-inspection any any CatOS> (enable) set security acl ip ACL-95 permit ip any any CatOS> (enable) commit security acl ACL-95
As you can see, you must first permit the explicit binding. Then you deny any other ARP packets for that same IP. Finally, you permit all other ARP packets.
There are some caveats to ARP inspection as it is currently implemented, and the management burden of tracking MAC address and IP bindings for ACL entries probably prevents many system administrators from using this for anything other than default gateways and critical systems. For more information on ARP inspection, see the following URL: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_7_5/confg_gd/acc_list.htm#1020673.
You can also limit on a per-port basis the number of ARP packets that are processed by the switch. Excess packets are dropped and can optionally cause the port to shut down. This can stop really noisy ARP attacks, but most ARP tools are less noisy than this. Arpspoof, for example, sends less than one ARP message per second. The following example sets an inspection limit of 25 packets per second and a shutdown threshold of 50 packets per second for port 2/1.
CatOS> (enable) set port arp-inspection 2/1 drop-threshold 25 shutdown- threshold 50 Drop Threshold=25, Shutdown Threshold=50 set on port 2/1. CatOS> (enable) CatOS> (enable) show port arp-inspection 3/1 Port Drop Threshold Shutdown Threshold ------------------------ -------------- ------------------ 2/1 25 50
Keep in mind that, when systems initialize, they might send large numbers of legitimate ARP queries. Use this feature with caution, especially considering it won't stop the ARP attacks used today. If you deploy ARP inspection, be sure to use the VACLs as your primary means of defense and the ARP rate limiting to stop clearly nonstandard behavior.
Other methods that can help include hard-coding static ARP entries for key devices in your network. From a management standpoint, you'd never be able to do this for all hosts, but for key devices it might be worth the effort.
TIP
Unfortunately, some older Microsoft operating systems (OSs) allow a static ARP entry to be overwritten by a gARP broadcast.
Open source tools can be used to help as well: arpwatch is a free tool developed by Lawrence Berkeley National Lab (LBNL). It works by keeping track of IP and MAC address bindings on the network and can notify you when certain mappings change. The tool can be downloaded here: http://www-nrg.ee.lbl.gov/.
Last, some IDS tools have the ability to detect certain types of ARP attacks. Some look for large quantities of ARP traffic, while others operate in much the same way as arpwatch.
DHCP Considerations
Dynamic Host Configuration Protocol (DHCP) allows hosts to request IP addresses from a central server. Additional parameters are usually passed as well, including DNS server IP address and the default gateway.
DHCP can be attacked in two ways:
Attackers could continue to request IP addresses from a DHCP server by changing their source MAC addresses in much the same way as is done in a CAM table flooding attack. A tool to execute such an attack is available here: http://packetstormsecurity.org/DoS/DHCP_Gobbler.tar.gz. If successful, the attack will cause all the leases on the DHCP server to be allocated.
The second attack is a bit nastier. Here, the attacker introduces a rogue DHCP server into the network. The server then attempts to offer DHCP addresses to whomever requests them. The fields for the default gateway and DNS server are set to the attacker's host, enabling all sorts of sniffing and MITM attacks much like dsniff. Even if your real DHCP server is operational, it doesn't mean you won't get a rogue address. What happens to you depends on the host OS you are running. Here is the relevant bit from the DHCP RFC 2131:
The client collects DHCPOFFER messages over a period of time, selects one DHCPOFFER message from the (possibly many) incoming DHCPOFFER messages (e.g., the first DHCPOFFER message or the DHCPOFFER message from the previously used server) and extracts the server address from the "server identifier" option in the DHCPOFFER message. The time over which the client collects messages and the mechanism used to select one DHCPOFFER are implementation dependent.
I tested a number of different OSs and all accepted the first DHCP offer they received, whether it was for their old IP address or not.
The method used to stop the first attack is identical to how you stop the CAM table flooding attack: use port security. The second attack is more difficult to stop. DHCP Authentication (RFC 3183) will help but has not yet been implemented (and also has some nasty key management implications). Both DHCP snooping and specific VACLs can help and are defined in the next sections.
DHCP Snooping
Some Cisco switches offer the ability to suppress certain types of DHCP information on certain ports. The primary feature enabling this functionality is DHCP snooping. DHCP snooping works by separating trusted from untrusted interfaces on a switch. Trusted interfaces are allowed to respond to DHCP requests; untrusted interfaces are not. The switch keeps track of the untrusted port's DHCP bindings and rate limits the DHCP messages to a certain speed. The first task in configuring DHCP snooping is to enable it:
Switch(config)#ip dhcp snooping
From here, DHCP snooping must be enabled for specific VLANs:
Switch(config)#ip dhcp snooping vlan number [number]
WARNING
As soon as you enter the VLAN-specific DHCP command, all DHCP stops working until you trust the ports for the DHCP server with the DHCP snooping trust command. You should enter the trust command first if deploying to a production network.
To set up the trusted ports at the interface level, ports must be defined as trusted or untrusted using the following command:
Switch(config-if)# ip dhcp snooping trust
Untrusted ports can be optionally configured with a rate limit on the amount of DHCP messages allowed per second:
Switch(config-if)# ip dhcp snooping limit rate rate
WARNING
Do not enable rate limiting on a trusted port because, when the rate is exceeded, the port is shut down. Rate limiting is designed more to protect the DHCP snooping process on the switch than to stop any DHCP attacks. Most DHCP attacks have a very low packet per second (pps) count.
DHCP snooping is not particularly useful if there are multiple systems behind a port on a switch (through either a hub or another switch). In these environments, the rouge DHCP server could sit off of this switch or hub and attack the local systems. For more information on other options for DHCP snooping, see the following: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12_1_13/config/dhcp.htm.
DHCP VACLs
Not all switch deployments are able to take advantage of DHCP snooping. A lower-tech solution to this problem can be partially achieved with DHCP VACLs. The VACL can specify which addresses are able to send DHCP replies. These replies will come from the unicast IP address of the DHCP server offering the lease. By filtering these replies by source address, rogue DHCP servers can be properly filtered. Consider the typical DHCP deployment depicted in Figure 6-9.
)
Figure
6-9 Common DHCP Deployment
Here, a local LAN is being served by a remote DHCP server. This server receives DHCP requests by DHCP relay configured on the default router. When the default router receives the DHCP lease offer back from the DHCP server, it passes it on to the client directly. Here is a VACL to protect against rogue DHCP servers in this example:
set security acl ip ROGUE-DHCP permit udp host 192.0.2.1 any eq 68 set security acl ip ROGUE-DHCP permit udp host 10.1.1.99 any eq 68 set security acl ip ROGUE-DHCP deny udp any any eq 68 set security acl ip ROGUE-DHCP permit ip any any
From the point at which the user PC requests an initial lease, here is what happens:
The user PC boots up and sends a DHCP request with source 0.0.0.0 and destination 255.255.255.255.
Both the default router and the rogue DHCP server see this request.
The rogue DHCP server replies, but since the source IP address is not 192.0.2.1, the reply is dropped by the access switch.
The default router passes the DHCP request to the real DHCP server, receives a reply, and passes this information on to the client.
The client connects and uses the network.
WARNING
Using VACLs to stop rogue DHCP servers is far from comprehensive protection. The rogue server could still spoof the IP address of the legitimate DHCP server. However, using VACLs will certainly stop all accidental DHCP servers put on the network and will thwart most common attackers.
Private VLANs
PVLANs offer further subdivision within an existing VLAN, allowing individual ports to be separated from others while still sharing the same IP subnet. This allows separation between devices to occur without requiring a separate IP subnet for each device (and the associated IP addresses that would waste). In its simplest form, PVLANs support isolated ports and promiscuous ports. Isolated ports can talk only to promiscuous ports, while promiscuous ports can talk to any port. In this deployment, the members of a subnet are isolated ports, and the gateway device is connected to a promiscuous port. This enables the hosts on a subnet to offer services to other subnets and to initiate requests of other subnets but not to service the requests of members of the same subnet.
A further PVLAN option available on some switches is community ports. In this model several isolated ports can be considered part of a community, enabling them to communicate with each other and the promiscuous port but not with other communities or isolated ports. Figure 6-10 summarizes these options.
)
Figure
6-10 PVLANs
The most common security-related deployment of PVLANs is in a public services segment or demilitarized zone (DMZ) connected to a firewall. In this deployment, PVLANs prevent the compromise of one system from leading to the compromise of other systems connected to the same subnet. Without PVLANs, an attacker could go after other vulnerable systems on any port or protocol because the attacker is already past the firewall. For example, a server segment off of your main corporate firewall might have FTP, SMTP, and WWW servers. There probably isn't much need for these devices to communicate with one another, so PVLANs can be used.
Configuring PVLANs varies from platform to platform. The simplest configuration method (available on entry-level Cisco IOS switches) uses the command port protected entered at the interface configuration level as a way to denote isolated ports. Ports without the port protected command are promiscuous.
On higher-end switches, the configuration is more complex. The following Cisco CatOS example sets ports 3/2–48 as isolated ports and port 3/1 as the promiscuous port. Note the need to create two VLANs and map them together, creating the single functional PVLAN.
CatOS (enable) set vlan 31 pvlan primary VTP advertisements transmitting temporarily stopped, and will resume after the command finishes. Vlan 31 configuration successful CatOS (enable) show pvlan Primary Secondary Secondary-Type Ports ------- --------- ---------------- ------------ 31 - - CatOS (enable) set vlan 32 pvlan isolated VTP advertisements transmitting temporarily stopped, and will resume after the command finishes. Vlan 32 configuration successful CatOS (enable) set pvlan 31 32 3/2-48 Successfully set the following ports to Private Vlan 31,32:3/2-48 CatOS (enable) set pvlan mapping 31 32 3/1 Successfully set mapping between 31 and 32 on 3/1
There are many more options for PVLAN configuration. For more details see the following URL: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_7_1/conf_gd/vlans.htm#xtocid854519.
TIP
PVLANs have different functionalities depending on the switch. On some switches, PVLANs are referred to as PVLAN edge. Check the documentation for your switch to understand the specific PVLAN capabilities.
PVLAN Security Considerations
PVLANs work fine unless the attacker does some creative things with ARP to try to get past them. The basic attack is to create a static ARP entry on the compromised machine showing that the victim machine is reachable by the router's MAC address. When the frame arrives at the router, the router will notice that the packet is really destined for the victim and will happily rebuild the frame with the correct MAC address and send it on its way. This attack works only in a unidirectional fashion if the attacker has compromised only the attacking host. If both hosts are compromised, bidirectional communication is trivial to set up.
Stopping this attack is pretty easy. Configure an inbound ACL on your router to stop all traffic from the local subnet to the local subnet. For example, if your server farm segment is 172.16.34.0/24, configure the following ACL on the default gateway:
IOS(config)#access-list 101 deny ip 172.16.34.0 0.0.0.255 172.16.34.0 0.0.0.255 log IOS(config)#access-list 101 permit ip any any IOS(config-if)#ip access-group 101 in
L2 Best Practices Recommendations
In summary, L2 of the OSI model can be a pretty weak link in your network security system if you aren't careful. Luckily, most of the attacks require local access, meaning the attacks are generated from the LAN they are trying to affect. Your security policy should provide guidance on how far to go in securing L2 infrastructure. Here is a summary of the best practices outlined in this section:
Always use a dedicated VLAN ID for all trunk ports.
Avoid using VLAN 1.
Set all user ports to nontrunking.
Deploy port security when possible for user ports.
Choose one or more ARP security options.
Enable STP attack mitigation (BPDU Guard, Root Guard).
Use PVLANs where appropriate.
Use MD5 authentication for VTP when VTP is needed.
Disable CDP where it is not needed.
Disable all unused ports and put them in an unused VLAN.
Ensure DHCP attack prevention where needed.