Implementing Local Area Network Security
The Data Link Layer of the OSI Model provides the functional and procedural means to transfer data among network entities with interoperability and connectivity to other layers, but from a security perspective, it presents its own set of challenges. The IINS exam objective covered in this chapter is as follows:
- Describe how to prevent Layer 2 attacks by configuring basic Catalyst switch security features
We cover DHCP snooping in our Cisco CCNA course.
This chapter is broken up into the following sections:
- LAN Switching Overview
- CAM Table Overflow Attacks
- MAC Spoofing Attacks
- ARP Spoofing Attacks
- VTP Attacks
- VLAN Hopping Attacks
- PVLAN Attacks
- Spanning-Tree Protocol Attacks
- DHCP Spoofing and Starvation Attacks
- Identity Based Networking Services
- IEEE 802.1x Attacks
- Other Cisco Catalyst Switch Security Features
LAN Switching Overview
LAN switching is a core component of the CCNA certification, which is a prerequisite for the IINS certification, and as such is not described in detail in this section. Instead, this section provides basic details on LAN switch operation, functionality, and protocols.
Switches operate at the Data Link Layer of the OSI Model and send frames. These frames contain source and destination MAC addresses for the sending and receiving hosts. The MAC addresses are stored in the switch MAC address table. The MAC address table uses Content Addressable Memory (CAM) and is referred to as the CAM table.
CAM is a memory type used in high-speed searching applications. CAM is used on switches because they are hardware-based, unlike bridges, which are software-based. By using Application Specific Integrated Circuits, or ASICs, switches can perform faster hardware-based lookups and forwarding than bridges can.
When building their CAM tables, switches note the incoming port of any particular MAC address when the device connected to that port sends a frame. Initially, switches have no idea where the destination device is, and so they broadcast the frame they receive from a particular host out of every port, except for the port on which the frame was received.
After the switch has flooded the frame, it will wait for a device to respond. When a device responds to the broadcast frame, the switch will note the port the response was received on and place that address in the MAC address table. This process is repeated until the switch has learned the MAC addresses of all devices connected to all ports. The MAC address learning process used by switches is illustrated in the following diagram:
Figure 6.1. MAC Address Learning Process
Referencing the diagram illustrated above, five devices are connected to a Cisco Catalyst switch: Host 1, Host 2, Host 3, Host 4, and Host 5. Host 1 wants to send data to Host 2. However, Host 1 only knows the IP address of Host 2, which is 10.1.1.2; it does not know the MAC address. In order to resolve the IP address of Host 2 to a MAC address, Host 1 will send out an ARP broadcast frame. ARP – Address Resolution Protocol – is used to resolve IP addresses to MAC addresses. This packet is sent to the Catalyst switch, as illustrated in step 1.
When the switch receives this frame from Host 1, it notes the incoming port, which is FastEthernet0/1, and because the switch does not currently know the MAC address of Host 2, it broadcasts the frame on all interfaces, except for FastEthernet0/1, as illustrated in step 2.
When Host 2 receives this broadcast frame, it responds to the broadcast with its MAC address. The switch then proceeds and notes the incoming port for the response from Host 2, which is FastEthernet0/2. This is illustrated in step 3. This received information is added to the switch CAM table. Subsequent frames from Host 1 to Host 2 will be switched between the FastEthernet interfaces the devices are connected to. This same process is repeated until the switch knows all the MAC addresses of all devices connected to it (e.g. Host 3, Host 4, and Host 5) as well.
Taking this concept one step further, switch CAM tables also reflect MAC addresses based on their VLAN allocations. A VLAN is a logical grouping of hosts, which can be restricted to a single switch or can span multiple physical switches. The concept of CAM table building for multiple VLANs is illustrated in the following diagram:
Figure 6.2. CAM Tables for Multiple VLANs
Referencing the diagram illustrated above, five devices are connected to a Cisco Catalyst switch: Host 1, Host 2, Host 3, Host 4, and Host 5. However, VLANs have been configured on the switch; Host 1, Host 2, and Host 3 reside in VLAN 10, and Host 4 and Host 5 reside in VLAN 20.
Host 1 wants to send data to Host 2. However, Host 1 only knows the IP address of Host 2, which is 10.1.1.2; it does not know the MAC address. In order to resolve the IP address of Host 2 to a MAC address, Host 1 will send out an ARP broadcast frame. This frame is sent to the Catalyst switch, as illustrated in step 1.
When the switch receives this frame from Host 1, it notes the incoming port, which is FastEthernet0/1, as well as the VLAN the port resides in, which is VLAN 10. Because the switch does not currently know the MAC address of Host 2, it sends out a broadcast on all interfaces in VLAN 10, except for the interface on which the frame was received. Given that FastEthernet0/1, FastEthernet0/2, and FastEthernet0/3 reside in VLAN 10, the broadcast will be sent only to those ports, as illustrated in step 2.
When Host 2 receives this broadcast frame, it responds to the broadcast with its MAC address. The switch then proceeds and notes the incoming port for the response from Host 2, which is FastEthernet0/2, as illustrated in step 3. This received information is added to the switch CAM table. Subsequent frames from Host 1 to Host 2 will be switched between the FastEthernet interfaces the devices are connected to. This same process is applicable to Host 4 and Host 5, which reside in VLAN 20. The switch CAM table is viewed by issuing the show mac-address-table command. The options available with this command are as follows:
| Sw1#show mac-address-table ?
address address keyword aging-time aging-time keyword count count keyword dynamic dynamic entry type interface interface keyword multicast multicast info for selected wildcard notification MAC notification parameters and history table static static entry type vlan VLAN keyword | Output modifiers <cr> |
There are only a few keywords that you should be familiar with for the purposes of the IINS course requirements. The address keyword allows administrators to view the specific MAC addresses in the CAM table. The aging-time keyword prints out information on the time MAC entries stored in the CAM table will be valid for. The dynamic keyword prints out all learned dynamic MAC entries in the CAM table. And, finally, the vlan keyword prints out all learned dynamic or configured static MAC addresses for the specified VLAN.
For example, to view all dynamic MAC address entries in the CAM table, the show mac-address-table dynamic command would be issued, as illustrated in the following output:
| Sw1#show mac-address-table dynamic
Mac Address Table ——————————————-
Vlan Mac Address Type Ports —- ———– ——– —– 2 000c.cea7.f3a0 DYNAMIC Fa0/1 2 0013.1986.0a20 DYNAMIC Fa0/2 6 0004.c16f.8741 DYNAMIC Fa0/3 6 0030.803f.ea81 DYNAMIC Fa0/4 8 0004.c16f.8742 DYNAMIC Fa0/5 8 0030.803f.ea82 DYNAMIC Fa0/6 Total Mac Addresses for this criterion: 6 |
When multiple switches are connected together via trunk links, they need to have some method to communicate VLAN information between them. This is accomplished by using the VLAN Trunking Protocol (VTP). VTP is a Cisco proprietary Layer 2 messaging protocol that manages the addition, deletion, and renaming of VLANs on a network-wide basis. Switches must reside within the same VTP domain in order to share VLAN information.
Trunk ports are used to carry traffic that belongs to multiple VLANs between switches, using the same link. By default, all VLANs are permitted to traverse a trunk port. However, the Cisco IOS software allows administrators to change this default behavior and manually specify which VLANs administrators want to traverse any given trunk link. VTP packets are sent across the trunk links either in Inter-Switch Link (ISL) or in IEEE 802.1Q (dot1Q) frames.
In switched networks with multiple, redundant trunk links between source and destination stations, the Spanning-Tree Protocol (STP) is used to prevent network loops. STP is defined in the IEEE 802.1d standard, and it uses the Spanning Tree Algorithm (STA) to determine which switch ports will be in a blocking state and which will be in a forwarding state. When all ports on all switches in the network are in either a blocking state or a forwarding state, the Layer 2 network is said to be converged.
CAM Table Overflow Attacks
As described in the previous section, CAM tables are storage locations that contain lists of MAC addresses known on physical ports of the switch, as well as their VLAN parameters. Switches, like all computing devices, do not have unlimited memory. This means that the CAM table has a fixed, allocated memory space.
Attackers can exploit the CAM table memory space limitation by flooding the switch with a large number of randomly generated invalid source and destination MAC addresses, until the CAM table fills up and the switch is no longer able to accept new entries. In such situations, the switch effectively turns into a hub and simply begins to broadcast all newly received frames to all ports (within the same VLAN) on the switch, essentially turning the VLAN into one big broadcast domain. CAM table attacks are easy to perform, and tools such as MACOF and DSNIFF are readily available to launch this type of attack.
While increasing the number of VLANs, which reduces the size of broadcast domains, can assist in reducing the effects of CAM table attacks, the recommended security solution is to enable and configure switch port security.
Port Security Overview
Port security is a dynamic Cisco Catalyst switch feature that secures switch ports, and ultimately the CAM table, by limiting the number of MAC addresses that can be learned on a particular port or interface. Port security can be implemented in the following three ways:
- Static Secure MAC Addresses
- Dynamic Secure MAC Addresses
- Sticky Secure MAC Addresses
Static secure MAC addresses are statically configured by network administrators and are stored in the MAC address table, as well as in the switch configuration. When static secure MAC addresses are assigned to a secure port, the switch will not forward frames that do not have a source MAC address that matches the configured static secure MAC address or addresses.
Dynamic secure MAC addresses are dynamically learned by the switch and are stored in the MAC address table. However, unlike static secure MAC addresses, dynamic secure MAC address entries are removed from the switch when the switch is reloaded or powered down.
Sticky secure MAC addresses are a combination of static secure MAC addresses and dynamic secure MAC addresses. These addresses can be learned dynamically or configured statically and are stored in the MAC address table, as well as in the switch configuration. This means that when the switch is powered down or rebooted, it will not need to dynamically discover the MAC addresses again because they will already be saved in the configuration file.
Once port security has been enabled, administrators can define the actions the switch will take in the event of a port security violation. Cisco IOS software allows administrators to specify three different actions to take when a violation occurs:
- Protect
- Shutdown
- Restrict
The protect option forces the port into a protected port mode. In this mode, all Unicast or Multicast frames with unknown source MAC addresses, i.e. MAC addresses not presently in the CAM table, are discarded by the switch. When the switch is configured to protect a port, it will not send out a notification when operating in protected port mode, meaning that administrators would never know when an attack was prevented in this mode.
The shutdown option places a port in an error-disabled state when a security violation occurs. The corresponding LED on the switch port is also turned off in this state. In shutdown mode, the switch sends out an SNMP trap and a Syslog message, and the violation counter is incremented.
The restrict option is used to drop packets with unknown MAC addresses, i.e. MAC addresses not presently in the CAM table, when the number of secure MAC addresses reaches the administrator-defined maximum limit for the port. In this mode, the switch will continue to restrict additional MAC addresses from sending frames until a sufficient number of secure MAC addresses is removed, or the number of maximum allowable addresses is increased. As is the case with the shutdown option, the switch sends out an SNMP trap and a Syslog message, and the violation counter is incremented.
Configuring Port Security
Port security is configured via the switchport port-security interface configuration command. The options available with this command are illustrated in the following output:
| Sw1(config)#int faste 0/1
Sw1(config-if)#switchport port-security ? aging Port-security aging commands mac-address Secure mac address maximum Max secure addrs violation Security Violation Mode <cr> |
The printed options are listed and described in the following table:
Table 6.1. Port Security Options
| Keyword | Description |
| aging | This keyword is used to specify the aging time for secure MAC addresses. |
| mac-address | This keyword is used to configure a static secure MAC address or to utilize sticky learning. |
| maximum | This keyword is used to specify the maximum number of secure MAC addresses that can be learned on an interface. |
| violation | This keyword is used to specify the action the switch will take in the event of a violation. |
The following example illustrates how to enable port security on an interface using a static secure MAC address of 001f:3c59:d63b to be forwarded by the switch:
| Sw1(config)#int fastethernet0/2
Sw1(config-if)#switchport port-security Sw1(config-if)#switchport port-security mac-address 001f.3c59.d63b |
Port security configuration can be validated by issuing the show port-security command, as illustrated in the following switch output:
| Sw1#show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action (Count) (Count) (Count) ——————————————————————————- Fa0/2 1 1 0 Shutdown ——————————————————————————- Total Addresses in System : 1 Max Addresses limit in System : 1024 |
NOTE: Keep in mind that, as illustrated in the output above, the default action in the event of a violation is to shut down the port. This default behavior can be modified by using the switchport port-security violation interface configuration command.
The following example illustrates how to configure port security to dynamically learn no more than two secure MAC addresses on a particular switch port. In the event that this value is exceeded, the switch has been configured to restrict frames from any other MAC addresses:
| Sw1(config)#int fastethernet0/2
Sw1(config-if)#switchport port-security Sw1(config-if)#switchport port-security maximum 2 Sw1(config-if)#switchport port-security violation restrict |
In the event of a security violation, and assuming that the switch has been configured for logging capabilities, the local switch log would reflect the following:
| Sw1#show logging
Syslog logging: enabled (0 messages dropped, 0 messages rate-limited, 0 flushes, 0 overruns) Console logging: disabled Monitor logging: level debugging, 0 messages logged Buffer logging: level informational, 243 messages logged Exception Logging: size (4096 bytes) File logging: disabled Trap logging: level informational, 247 message lines logged
Log Buffer (4096 bytes): 01:06:16: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0013.1986.0a20 on port Fa0/2. 01:06:36: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 000c.cea7.f3a0 on port Fa0/2. 01:06:41: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0004.c16f.8741 on port Fa0/2. |
Additionally, a remote Syslog server would show the following port security messages:
Figure 6.3. Syslog Security Messages
The increments in the port security violation counter can be viewed by using the show port-security command, as illustrated in the following output:
| Sw1#show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action (Count) (Count) (Count) ——————————————————————————- Fa0/2 2 2 16 Restrict ——————————————————————————- Total Addresses in System : 2 Max Addresses limit in System : 1024 |
The following example illustrates how to enable sticky learning on a port for a maximum of ten MAC addresses. In the event that unknown MAC addresses are detected on the port, the port is configured to go into protected port mode:
| Sw1(config)#int fastethernet0/2
Sw1(config-if)#switchport port-security Sw1(config-if)#switchport port-security mac-address sticky Sw1(config-if)#switchport port-security maximum 10 Sw1(config-if)#switchport port-security violation protect |
The configuration is validated via the show port-security [options] command, as follows:
| Sw1#show port-security
Secure Port MaxSecureAddr CurrentAddr SecurityViolation Security Action (Count) (Count) (Count) ——————————————————————————- Fa0/2 10 5 0 Protect ——————————————————————————- Total Addresses in System : 5 Max Addresses limit in System : 1024 |
An important aspect to remember regarding sticky learning is that the learned addresses are automatically added to the switch configuration and this configuration is retained between reboots. The show running-config interface [name] command can be used to view the learned and saved sticky MAC addresses per interface, as illustrated in the following output:
| Sw1#show running-config interface fastethernet 0/2
Building configuration…
Current configuration : 550 bytes ! interface FastEthernet0/2 switchport access vlan 2 switchport mode access switchport port-security switchport port-security maximum 10 switchport port-security violation protect switchport port-security mac-address sticky switchport port-security mac-address sticky 0004.c16f.8741 switchport port-security mac-address sticky 000c.cea7.f3a0 switchport port-security mac-address sticky 0013.1986.0a20 switchport port-security mac-address sticky 001d.09d4.0238 switchport port-security mac-address sticky 0030.803f.ea81 no ip address end |
Additionally, the show port-security address command can be used to view sticky addresses on a per-interface basis, as illustrated in the following output:
| Sw1#show port-security address
Secure Mac Address Table ——————————————————————- Vlan Mac Address Type Ports Remaining Age (mins) —- ———– —- —– ————- 2 0004.c16f.8741 SecureSticky Fa0/2 – 2 000c.cea7.f3a0 SecureSticky Fa0/2 – 2 0013.1986.0a20 SecureSticky Fa0/2 – 2 001d.09d4.0238 SecureSticky Fa0/2 – 2 0030.803f.ea81 SecureSticky Fa0/2 – ——————————————————————- Total Addresses in System : 5 Max Addresses limit in System : 1024 |
In addition to configuring the different port security parameters, it is important to completely understand the implications of port security on MAC address aging. By default, the secure MAC address will not be aged out and will remain in the switch MAC table until the switch is powered off. This means that even if a host with a secured MAC address is removed from the switch port, the MAC address entry will be retained in the switch CAM table. To address this issue, and the potential problems it may cause, the Cisco IOS software allows administrators to configure port security aging. There are two types of aging mechanisms that can be used:
- Absolute
- Inactivity
The absolute mechanism causes the secured MAC addresses on the port to age out after a fixed specified time, upon which all references are flushed from the secure address list. The inactivity mechanism, also referred to as the idle time mechanism, causes the secured MAC addresses on the port to age out if there is no activity (i.e. frames) during the specified time period.
The following example illustrates how to configure an aging time of two hours for inactive secured MAC addresses on FastEthernet0/2:
| Sw1(config)#int fastethernet0/2
Sw1(config-if)#switchport port-security aging time 120 Sw1(config-if)#switchport port-security aging type inactivity |
The following example illustrates how to configure a switch port so that all secured MAC addresses are flushed every eight hours:
| Sw1(config)#int fastethernet0/2
Sw1(config-if)#switchport port-security aging time 480 Sw1(config-if)#switchport port-security aging type absolute |
The remaining valid time for secure MAC addresses, based on the port security timer configuration, can be viewed by issuing the show port-security address command, as follows:
| Sw1#show port-security address
Secure Mac Address Table ——————————————————————- Vlan Mac Address Type Ports Remaining Age (mins) —- ———– —- —– ————- 2 0004.c16f.8741 SecureDynamic Fa0/2 479 2 000c.cea7.f3a0 SecureDynamic Fa0/2 479 2 0013.1986.0a20 SecureDynamic Fa0/2 478 2 001d.09d4.0238 SecureDynamic Fa0/2 478 2 0030.803f.ea81 SecureDynamic Fa0/2 479 ——————————————————————- Total Addresses in System : 5 Max Addresses limit in System : 1024 |
MAC Spoofing Attacks
Earlier in this guide, we learned that spoofing is masquerading or pretending to be someone you are not. In addition, we also learned that the most common types of spoofing attacks are IP spoofing attacks. In this section, we are going to be learning about spoofing at the Data Link Layer, specifically MAC address spoofing.
MAC spoofing is used to spoof a source MAC address to impersonate other hosts or devices in the network. The primary objective of MAC spoofing is to confuse the switch and cause it to believe that the same host is connected to two ports, which causes the switch to attempt to forward frames destined to the trusted host to the attacker as well. The following diagram illustrates a switch with four connected hosts, as well as the current CAM table of the switch:
Figure 6.4. Switch CAM Table
In the diagram illustrated above, the switch is operating normally and, based on CAM table entries, knows the MAC addresses for all devices connected to its ports. Therefore, if Host 4 wanted to send a frame to Host 2, the switch would simply forward the frame out of its FastEthernet0/2 interface to Host 2.
Now, suppose Host 1 was compromised by an attacker who wanted to receive all traffic destined for Host 2. Using MAC spoofing, the attacker crafts an Ethernet frame using the source address of Host 2. When the switch receives this frame, it notes the source MAC address and overwrites the CAM table entry for the MAC address of Host 2, and points it to port FastEthernet0/1 instead of port FastEthernet0/2, where the real Host 2 is connected. This concept is illustrated in the following diagram:
Figure 6.5. Compromised CAM Table
When Host 3 or Host 4 attempts to send frames destined to Host 2, the switch will forward them to the attacker on Host 1 because the CAM table entry has been poisoned. When Host 2 attempts to send frames, the switch relearns the same MAC address from FastEthernet0/2 and rewrites the CAM table entry once again to reflect this change.
The result is a tug-of-war between Host 2 and Host 1 as to which host owns this MAC address. In addition, this confuses the switch and causes repetitive rewrites of MAC address table entries, causing a DoS attack on the real host, i.e. Host 2. If the number of spoofed MAC addresses used is high, this attack could have serious performance consequences for the switch that is constantly rewriting its CAM table.
MAC spoofing attacks can be mitigated by implementing port security, which was described in detail in the previous section along with configuration examples.
ARP Spoofing Attacks
ARP spoofing attacks are used by attackers to disguise their source MAC address by the impersonation of another host on the network. It is important to understand that this is not the same thing as a MAC spoofing attack. In ARP spoofing attacks, the switch is misguided by poisoning the ARP cache. In MAC spoofing attacks, however, the switch is misguided into believing that two ports have the same MAC address, which effectively poisons the MAC address table.
ARP is used to resolve IP addresses to MAC addresses. For example, if a host has an IP address and needs to reach another host with a different IP address, it will use ARP to resolve that IP address to a MAC address so that the switch can forward the frames to the intended destination. Cisco routers and switches maintain ARP tables to show IP-to-MAC address mappings. Keep in mind that an ARP table is not the same as the switch CAM table. In Cisco IOS software, the ARP table can be viewed by issuing the show arp (for all IP and non-IP ARP mappings) or the show ip arp (for IP ARP mappings) commands. The following output illustrates an ARP table on a Cisco IOS router:
| R1#show arp
Protocol Address Age (min) Hardware Addr Type Interface Internet 150.10.100.102 105 0000.a710.859b ARPA Ethernet0/0 Internet 150.10.100.102 115 0000.a710.68cd ARPA Ethernet0/0 |
On Windows-based machines, the arp –a command can also be used to view the ARP table:
Figure 6.6. arp -a Command Output
ARP spoofing occurs during the ARP request and reply messaging between two or more legitimate host systems. It is during this exchange of messages that the attacker can inject a fake ARP reply message with his or her own MAC address masquerading as one of the legitimate hosts, as illustrated in the following diagram:
Figure 6.7. ARP Spoofing
In the diagram illustrated above, three hosts reside on a shared LAN segment. There are two legitimate hosts, Host 1 and Host 2, in addition to a machine that has been compromised and is now being operated by the attacker. When Host 1 wants to send data to Host 2, it sends out an ARP broadcast to resolve the IP address of Host 2 to a MAC address, as illustrated in step 1.
However, before Host 2 can respond to the ARP request from Host 1, the attacker crafts a packet and responds to Host 1, providing it with the MAC address of its machine instead. The ARP table on Host 1 is updated and incorrectly reflects an IP-to-MAC address mapping of 10.1.1.2 with the MAC address 1a2b.3333.cdef. This causes Host 1 to send all traffic that should be destined to Host 2 to the attacker’s machine instead.
Another ARP function that can be used to steer traffic to the attacker’s machine is accomplished using gratuitous ARP (GARP), which is an unsolicited ARP broadcast that contains the IP address of the target host and the attacker’s MAC address. The GARP causes all hosts to update incorrectly their ARP tables with an ARP entry that pairs the target’s IP address with the MAC address of the machine belonging to the attacker.
Similarly, GARP will also cause the switch to update incorrectly its CAM table, and when any host needs to send data to the target IP address, it will be forwarded to the machine belonging to the attacker instead. This concept is illustrated in the following diagram:
Figure 6.8. Attacker Using GARP
As illustrated in the diagram above, the attacker sends an unsolicited GARP to the LAN, causing all hosts to update their ARP tables with the MAC address 1a2b:a3fg:cd56 for the server 10.1.1.254. Therefore, all data sent to the server from Host 1, Host 2, Host 3, and Host 4, will actually be forwarded to the machine of the attacker.
ARP spoofing is very easy to perform and is commonly used in MITM attacks. In addition to this, readily available tools such as DSNIFF and ETTERCAP can be used to perform these attacks with relative ease. The recommended solution to prevent such attacks in Cisco Catalyst switches is to implement Dynamic ARP Inspection (DAI).
NOTE: DAI is only supported in medium-and-high-end Cisco Catalyst switches, such as the Cisco 4500 and Cisco 6500 series switches. It is not supported on lower-end switches, such as the Cisco Catalyst 2950 and 3750 series switches.
Dynamic ARP Inspection Overview
Dynamic ARP Inspection, or DAI, is a Cisco Catalyst switch security feature that validates ARP packets in a network. DAI determines the validity of packets by performing an IP-to-MAC address binding inspection, which is stored in a trusted DHCP snooping database on the switch. DHCP snooping will be described in detail later in this chapter.
Once this validity has been confirmed, packets are then forwarded to their destination; however, DAI will drop all packets with invalid IP-to-MAC address bindings that fail the inspection validation process. This capability protects the network from MITM attacks. Additionally, DAI ensures that only valid ARP requests and responses are relayed. When DAI is enabled, the switch performs the following activities:
- It intercepts all ARP requests and responses on untrusted ports. However, it is important to keep in mind that it inspects only inbound packets; it does not inspect outbound packets.
- It verifies that each of these intercepted packets has a valid IP-to-MAC address binding before updating the local ARP cache or before forwarding the packet to the its destination.
- It drops invalid ARP packets. These are ARP packets that contain invalid or incorrect IP-to-MAC address bindings.
DAI can be used in both DHCP and non-DHCP environments. In non-DHCP environments, there is no DHCP snooping database, but DAI can validate ARP packets against a user-defined ARP ACL to map hosts with a statically configured IP address to their MAC address. The following diagram illustrates basic DAI operation in a DHCP environment, on a Cisco Catalyst switch enabled for DAI in conjunction with DHCP snooping:
Figure 6.9. DAI With DHCP
Based on the network diagram illustrated above, DAI has been enabled on the switch to which Host 1, Host 2, and an attacker’s machine are connected. The switch is showing the IP-to-MAC bindings in the DHCP snooping database. Therefore, if the attacker attempts to send a GARP with a spoofed MAC address, DAI will intercept the packet, and because it has an invalid IP-to-MAC address binding, the packet will be discarded.
DAI associates a trust state with each interface on the switch. Packets arriving on trusted interfaces bypass all DAI validation checks, and those arriving on untrusted interfaces undergo the DAI validation process. In a typical network configuration, you configure all switch ports connected to host ports as untrusted and configure all switch ports connected to switches (i.e. trunks) as trusted. With this configuration, all ARP packets entering the network from a given switch bypass the security check, but because they have been validated on the host port, they pose no security threats. No other validation is needed at any other place in the VLAN or in the network. This concept is illustrated in the following diagram:
Figure 6.10. DAI Trusted Packets
As illustrated in the diagram above, the trunk link between the two switches is trusted. This means that ARP packets that traverse this link will not be subject to DAI validation. However, the access ports that connect Host 1 and Host 2 to the switches are untrusted, which means that ARP packets that traverse these links will be subject to DAI validation.
Configuring Dynamic ARP Inspection in a DHCP Environment
Configuring DAI in a DHCP environment is a relatively straightforward process. DAI is configured via the ip arp inspection vlan [vlan-range] global configuration command for either a specific VLAN or a range of VLANs. Once DAI has been configured for a specific VLAN or a range of VLANs, all ports are untrusted, by default. Therefore, to enable the DAI trusted state for ports, the ip arp inspection trust interface configuration command must be configured on the trusted interface.
You are not expected to perform advanced DAI configuration as part of the IINS course requirements. However, you are expected to know how to enable and verify a basic DAI implementation in Cisco IOS Catalyst switches. The following example illustrates how to enable and verify DAI for VLAN 5 on a switch:
| Sw1(config)#ip arp inspection vlan 5
Sw1(config)#exit Sw1# Sw1#show ip arp inspection vlan 5 Source Mac Validation : Disabled Destination Mac Validation : Disabled IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL —- ————- ——— ——— ———- 5 Enabled Active
Vlan ACL Logging DHCP Logging —- ———– ———— 5 Deny Deny |
The following example illustrates how to configure a port as a trusted port for DAI. This port either could be a trunk link or connected to a secure network server, for example:
| Sw1(config)#int gigabitethernet5/1
Sw1(config-if)#description ‘Trunk Link Connected To Sw2' Sw1(config-if)#switchport trunk encapsulation dot1q Sw1(config-if)#switchport mode trunk Sw1(config-if)#ip arp inspection trust Sw1(config-if)#exit Sw1(config)#exit Sw1# Sw1#show ip arp inspection interfaces gigabitethernet5/1
Interface Trust State Rate (pps) ————— ———– ———- Gi5/1 Trusted None |
Configuring Dynamic ARP Inspection in a Non-DHCP Environment
While the configuration of DAI in a non-DHCP environment is beyond the scope of the IINS course requirements, this section is provided for the purposes of being thorough. In order to configure DAI in a non-DHCP environment, administrators must first configure ARP ACLs that DAI will use to validate ARP packets. This is performed via the arp access-list [name] global configuration command.
Next, administrators can configure DAI to validate packets against the ARP ACL(s) via the ip arp inspection filter [arp-acl-name] vlan [vlan-range] global configuration command. The following example illustrates how to configure an ARP ACL to permit ARP packets from host 10.1.1.1 with a MAC address of 1a2b.1111.cdef, and how to configure and verify DAI inspection of ARP packets in VLAN 5 based on this ACL:
| Sw1(config)#arp access-list VLAN-5-ARP
Sw1(config-arp-nacl)#permit ip host 10.1.1.1 mac host 1a2b.1111.cdef Sw1(config-arp-nacl)#exit Sw1(config)#ip arp inspection filter VLAN-5-ARP vlan 5 Sw1(config)#exit Sw1# Sw1#show arp access-listARP access list VLAN-5-ARP permit ip host 10.1.1.1 mac host 1a2b.1111.cdef |
The show ip arp inspection command is used to validate the DAI configuration, as follows:
| Sw1#show ip arp inspection vlan 5
Source Mac Validation : Disabled Destination Mac Validation : Disabled IP Address Validation : Disabled
Vlan Configuration Operation ACL Match Static ACL —- ————- ——— ——— ———- 5 Enabled Active VLAN-5-ARP No
Vlan ACL Logging DHCP Logging —- ———– ———— 5 Deny Deny |
VTP Attacks
VTP is a Cisco-proprietary Layer 2 protocol used to distribute VLAN configuration information between switches in the same VTP domain over trunk links. There is only one documented case of an actual VTP attack that exploits a well-known vulnerability in the following low-end Cisco IOS Catalyst switches (most of which are end-of-life products and are no longer sold by Cisco):
- Cisco 2900XL Series
- Cisco 2900XL LRE Series
- Cisco 2940 Series
- Cisco 2950 Series
- Cisco 2950-LRE Series
- Cisco 2955 Series
- Cisco 3500XL Series
- Cisco IGESM
This attack includes the sending of malformed VTP packets to these switches. Upon receiving a malformed VTP packet, the switches listed above may reboot. This attack could be executed repeatedly, causing an extended DoS attack.
In order to exploit successfully this vulnerability, the attacker must know the VTP domain name, as well as send the malformed VTP packet to a port on the switch configured for trunking using either ISL or 802.1Q. If these older switches are incorporated into networks, administrators should ensure that only known, trusted devices are connected to ports configured for ISL or 802.1q trunking to mitigate against this attack.
The remaining VTP attacks are theoretical and there are no practical or real-world cases demonstrating such attacks. The theory behind these VTP attacks is that an intruder could either impersonate a trunk link in order to receive all VLAN information via VTP or send falsified VTP messages across trunk links, pretending to be a VTP server, which would allow the intruder to add, delete, or modify VLAN information throughout the VTP domain, or even create Spanning-Tree loops in the network.
To prevent the possibility of VTP attacks, it is recommended that a VTP password should be configured for the VTP domain using the vtp password [password] global configuration command. In addition, if the switch platform supports it, administrators should also consider running VTP version 3. While going into the details pertaining to VTP version 3 is beyond the scope of the IINS course requirements, the following section lists the enhancements in VTPv3 over VTPv2 and VTPv1:
- Support for extended VLANs
- Support for the creation and advertising of private VLANs
- Support for VLAN instances and MST mapping propagation instances
- Improved server authentication
- Protection from the ‘wrong’ database accidentally being inserted into a VTP domain
- Interaction with VTP version 1 and VTP version 2
- Ability to be configured on a per-port basis
The most important enhancement in VTPv3, from a security perspective, is the enhanced authentication capabilities: it introduces an enhancement to the handling of VTP passwords; it allows the configuration of a primary server; and its server cannot make any configuration changes in the domain without first becoming the primary server for the domain. The VTPv3 authentication enhancements are as follows:
- If no password is configured, or if a password is configured the same way as in VTPv1 or VTPv2, the following occurs:
- A switch can become the primary server and configure the domain with no restriction;
- The password appears in the configuration; and
- This enhancement is equivalent to the existing VTPv1 and VTPv2 levels of security.
- If a password is configured as a hidden password, the following occurs:
- The password does not appear in plain text in the configuration; and
- If you try to configure the switch as a primary server, you are prompted for the password.
While delving into the specifics of VTPv3 or configuring and validating VTPv3 is beyond the scope of the IINS course requirements, the following example illustrates how to configure the VTPv1 and VTPv2 password in Cisco IOS Catalyst switches:
| Sw1(config)#vtp password !in5s3cur!ty
Setting device VLAN database password to !in5s3cur!ty Sw1(config)#exit |
Once configured, the show vtp status command is used to validate configuration. However, it is important to remember that the password is automatically printed in encrypted form and is not legible. However, administrators can ensure that all switches have the same password by validating that the generated hash is consistent on all devices:
| Sw1#show vtp status
VTP Version : 2 Configuration Revision : 4 Maximum VLANs supported locally : 250 Number of existing VLANs : 11 VTP Operating Mode : Server VTP Domain Name : SECURITY VTP Pruning Mode : Enabled VTP V2 Mode : Enabled VTP Traps Generation : Disabled MD5 digest : 0x7C 0x00 0x6F 0x3D 0xCD 0x53 0xC5 0xE5 Configuration last modified by 0.0.0.0 at 3-1-93 00:30:52 Local updater ID is 172.16.1.254 on interface Vl2 (lowest numbered VLAN interface found) |
VLAN Hopping Attacks
By default, in order for users in different VLANs to communicate, inter-VLAN routing must be employed. This can be done using a one-armed-router, also referred to as a router-on-a-stick, by using sub-interfaces on the router. Alternatively, and more commonly, multi-Layer switches, such as the Cisco Catalyst 3750, 4500, and 6500 series switches, are used in the network. These switches have the capability to both route and switch. Inter-VLAN routing is a core concept and requirement of the CCNA certification. It is explained, in detail, in the CCNA study guide available from www.howtonetwork.net.
VLAN hopping attacks are methods in which an attacker attempts to bypass a Layer 3 device to communicate directly between VLANs, with the main objective being to compromise a device residing on another VLAN. There are two primary methods used to perform VLAN hopping attacks:
- Switch spoofing
- Double-tagging
Switch Spoofing Attacks
In switch spoofing, the attacker impersonates a switch by emulating ISL or 802.1Q signaling, as well as Dynamic Trunking Protocol (DTP) signaling. DTP provides switches with the ability to negotiate the trunking method for the trunk link they will establish between themselves.
If an attacker can successfully emulate ISL, 802.1Q, or DTP signaling, the attacker’s system becomes a member of all VLANs, since trunk links forward all VLAN information. Switch spoofing attacks exploit the default native VLAN, which is VLAN 1, that is used on Cisco Catalyst switches.
By default, when an access port sends a frame to a remote switch, and that packet is encapsulated into 802.1Q format with the native VLAN ID, it will be successfully forwarded to the remote switch without the need to cross a Layer 3 device. Network administrators can prevent switch spoofing attacks by performing the following actions:
- Disabling DTP on trunk ports
- Disabling trunking capabilities on ports that should not be configured as trunk links
- Preventing user data from traversing the native VLAN
The show interfaces [name] switchport command shows the default values for a switch port:
| Sw1#show interfaces gigabitethernet 0/2 switchport
Name: Gi0/2 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: down Administrative Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL
Protected: false
Voice VLAN: none (Inactive) Appliance trust: none |
The following example illustrates how a DTP can be disabled for a trunk port:
| Sw1(config)#int gigabitethernet 0/1
Sw1(config-if)#description ‘Trunk Link’ Sw1(config-if)#switchport trunk encapsulation dot1q Sw1(config-if)#switchport nonegotiate |
The operational status of the trunk can be validated by issuing the show interfaces [name] switchport command, as illustrated in the following output:
| Sw1#show interfaces gigabitethernet 0/1 switchport
Name: Gi0/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: down Administrative Trunking Encapsulation: dot1q Negotiation of Trunking: Off Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL
Protected: false
Voice VLAN: none (Inactive) Appliance trust: none |
The following example illustrates how to disable trunking capabilities on ports that should not be used to form trunk links on the switch:
| Sw1(config)#int fastethernet 0/1
Sw1(config-if)#description ‘Non-Trunk Access Link’ Sw1(config-if)#switchport Sw1(config-if)#switchport mode access Sw1(config-if)#switchport access vlan 2 |
This configuration can be validated via the show interfaces [name] switchport command:
| Sw1#show interfaces fastethernet 0/1 switchport
Name: Fa0/1 Switchport: Enabled Administrative Mode: static access Operational Mode: down Administrative Trunking Encapsulation: dot1q Negotiation of Trunking: Off Access Mode VLAN: 2 (VLAN0002) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL
Protected: false
Voice VLAN: none (Inactive) Appliance trust: none |
Finally, the following example illustrates how administrators can prevent user data from being sent across the native VLAN by specifying a VLAN other than VLAN 1, which does not span the entire Layer 2 network. Remember, VLAN 1 cannot be deleted or modified, but all other VLANs can:
| Sw1(config)#int giga0/1
Sw1(config-if)#switchport trunk native vlan 5 |
The following configuration can be validated via the show interfaces [name] switchport command:
| Sw1#show interfaces gigabitethernet 0/1 switchport
Name: Gi0/1 Switchport: Enabled Administrative Mode: trunk Operational Mode: down Administrative Trunking Encapsulation: dot1q Negotiation of Trunking: Off Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 5 (My-Native-VLAN) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL
Protected: false
Voice VLAN: none (Inactive) Appliance trust: none |
Double-Tagging Attacks
By default, the traffic in the native VLAN used on 802.1Q trunks is not tagged, as frames travel between switches in the Layer 2-switched network. This default behavior means that if an attacker resides on the native VLAN used by the switches, he or she could successfully launch a double-tagging network attack.
Double-tagging or double encapsulated VLAN hopping attacks involve tagging frames with two 802.1Q tags to forward the frames to a different VLAN. The embedded hidden 802.1Q tag inside the frame allows the frame to traverse a VLAN that the outer 802.1Q tag did not specify. This is a particularly dangerous attack because it will work even if the trunk port is set to OFF.
The first switch that encounters the double-tagged frame strips off the first tag and forwards the frame, the result being that the frame is forwarded with the inner 802.1Q tag out to all ports on the switch, including the trunk ports configured with the native VLAN ID of the network attacker. The second switch then forwards the frame to the destination based on the VLAN identifier in the second 802.1Q header. This concept is illustrated in the following diagram:
Figure 6.11. Double Tagging Attack
As illustrated in the diagram above, an attacker has compromised Host 1 and is trying to access Host 2. The attacker sends a double-tagged frame to Sw1, which includes the native VLAN (VLAN 1), and the VLAN Host 2 resides in, which is VLAN 200.
When Sw1 receives the frame, it strips off the first tag (1) and forwards the frame to Sw2. When Sw2 receives the frame, it only contains VLAN 200. The switch removes this tag and forwards the frame to Host 2, which resides in VLAN 200. Thus, the attacker has successfully managed to traverse different VLANs while bypassing any Layer 3 network devices.
To prevent double-tagging attacks, administrators should ensure that the native VLAN used on all the trunk ports is different from the VLAN ID of user access ports. It is best to use a dedicated VLAN that is specific for each pair of trunk ports and not the default VLAN, as illustrated in the following diagram:
Figure 6.12. Preventing Double Tagging Attacks
Additionally, configuring the native VLAN to tag all traffic prevents the vulnerability of double-tagged 802.1Q frames hopping VLANs. This functionality can be enabled by issuing the vlan dot1q tag native global configuration command.
PVLAN Attacks
Private VLAN Basics
Private VLANs (PVLANs) prevent inter-host communication by providing port-specific security between adjacent ports within a VLAN across one or more switches. Access ports within PVLANs are allowed to communicate only with the certain designated router ports, which are typically those connected to the default gateway for the VLAN. Both normal VLANs and private VLANs can co-exist on the same switch; however, unlike normal VLANs, private VLANs allow for the segregation of traffic at Layer 2, thereby transforming a broadcast segment into a non-broadcast multi-access segment.
Private VLAN Ports
The PVLAN feature uses three different types of ports:
- Community
- Isolated
- Promiscuous
Community PVLAN ports are logically combined groups of ports in a common community that can pass traffic amongst themselves and with promiscuous ports. Ports are separated at Layer 2 from all other interfaces in other communities or isolated ports within their PVLAN.
Isolated PVLAN ports cannot communicate with any other ports within the PVLAN. However, isolated ports can communicate with promiscuous ports. Traffic from an isolated port can be forwarded only to a promiscuous port and no other port.
Promiscuous PVLAN ports can communicate with any other ports, including community and isolated PVLAN ports. The function of the promiscuous port is to allow traffic between ports in a community of isolated VLANs. Promiscuous ports can be configured with switch ACLs to define what traffic can pass between these VLANs. It is important to know that only one (1) promiscuous port is allowed per PVLAN, and that port serves the community and isolated VLANs within that PVLAN. Because promiscuous ports can communicate with all other ports, this is the recommended location to place switch ACLs to control traffic between the different types of ports and VLANs.
Isolated and community port traffic can enter or leave switches via trunk links, because trunks support VLANs carrying traffic among isolated community and promiscuous ports. Hence, PVLANs are associated with a separate set of VLANs that are used to enable PVLAN functionality in Cisco Catalyst switches. There are three types of VLANs used in PVLANs:
- Primary VLANs
- Isolated VLANs
- Community VLANs
Primary VLANs carry traffic from a promiscuous port to isolated, community, and other promiscuous ports within the same primary VLAN.
Isolated VLANs carry traffic from isolated ports to a promiscuous port. Ports in isolated VLANs cannot communicate with any other port in the private VLAN without going through the promiscuous port.
Community VLANs carry traffic between community ports within the same PVLAN, as well as to promiscuous ports. Ports within the same community VLAN can communicate with each other at Layer 2; however, they cannot communicate with ports in other community or isolated VLANs without going through a promiscuous port.
Isolated and community VLANs are typically referred to as secondary VLANs. Therefore, a private VLAN actually contains three elements: the PVLAN itself, the secondary VLANs, and the promiscuous port. This concept is illustrated in the following diagram:
Figure 6.13. Private VLANs
NOTE: Complete PVLAN configuration is only supported in Cisco Catalyst switches 3750 switches and above. PVLAN configuration is not supported in Layer 2-only switches, such as the Cisco Catalyst 2950 series.
Configuring Private VLANs
NOTE: Before configuring PVLANs, it is important to remember to configure the switch in VTP Transparent mode before creating the PVLANs. Although PVLANs can be propagated between switches, they are created in the context of a single switch and cannot have member switches. The following configuration steps are required to configure private VLANs:
- Configure the primary VLAN by issuing the private-vlan primary VLAN configuration mode command for the desired VLAN;
- Configure the secondary VLAN(s) by issuing the private-vlan [community|isolated] VLAN configuration mode command for the desired VLAN(s);
- Associate the secondary VLAN(s) to the primary VLAN via the private-vlan association VLAN configuration command under the primary VLAN created in step 1;
- Map secondary VLANs to the Switch Virtual Interface (Layer 3 VLAN interface) of the primary VLAN via the private-vlan mapping interface configuration command;
- Configure Layer 2 interfaces as isolated or community ports, and associate the Layer 2 interface with the primary VLAN and selected secondary VLAN pair via the switchport mode private-vlan host and the switchport private-vlan host association [primary vlan] [secondary vlan] interface configuration commands; and
- Configure a Layer 2 interface as a promiscuous port and map the PVLAN promiscuous port to the private VLAN and to the selected VLAN pair via the switchport mode private-vlan promiscuous and the switchport private-vlan mapping [primary vlan] [secondary vlans] interface configuration commands.
To reinforce these six steps, the following example illustrates how to implement private VLANs. VLAN 111 will be configured as the primary VLAN; VLAN 222 will be configured as a community VLAN; and VLAN 333 will be configured as an isolated VLAN. Switch port FastEthenet0/1 will be assigned to VLAN 111; switch port FastEthenet0/2 will be assigned to VLAN 222; and switch port FastEthernet0/3 will be assigned to VLAN 333. These parameters are provided in the following table:
Table 6.2. VLAN Parameters
| VLAN Number | VLAN Type | VLAN Port |
| 111 | Primary | FastEthernet0/1 |
| 222 | Community | FastEthernet0/2 |
| 333 | Isolated | FastEthernet0/3 |
Configure the primary VLAN by issuing the private-vlan primary VLAN configuration mode command for the desired VLAN, as follows:
| Sw1(config)#vlan 111
Sw1(config-vlan)#name ‘My-Primary-VLAN' Sw1(config-vlan)#private-vlan primary Sw1(config-vlan)#exit |
Configure the secondary VLAN(s) by issuing the private-vlan [community|isolated] VLAN configuration mode command for the desired VLAN(s), as follows:
| Sw1(config)#vlan 222
Sw1(config-vlan)#name ‘My-Community-VLAN' Sw1(config-vlan)#private-vlan community Sw1(config-vlan)#exit Sw1(config)#vlan 333 Sw1(config-vlan)#name ‘My-Isolated-VLAN' Sw1(config-vlan)#private-vlan isolated Sw1(config-vlan)#exit |
Associate the secondary VLAN(s) to the primary VLAN via the private-vlan association VLAN configuration command under the primary VLAN created in step 1, as follows:
| Sw1(config)#vlan 111
Sw1(config-vlan)#private-vlan association 222,333 Sw1(config-vlan)#exit |
Map secondary VLANs to the Switch Virtual Interface (Layer 3 VLAN interface) of the primary VLAN via the private-vlan mapping interface configuration command, as follows:
| Sw1(config-if)#int vlan 111
Sw1(config-if)#private-vlan mapping add 222,333 Sw1(config-if)#exit |
Configure Layer 2 interfaces as isolated or community ports, and associate the Layer 2 interface with the primary VLAN and selected secondary VLAN pair via the switchport mode private-vlan host and the switchport private-vlan host association [primary vlan] [secondary vlan] interface configuration commands, as follows:
| Sw1(config)#int fa0/2
Sw1(config-if)#switchport mode private-vlan host Sw1(config-if)#switchport private-vlan host-association 111 222 Sw1(config-if)#exit Sw1(config)#int fa0/3 Sw1(config-if)#switchport mode private-vlan host Sw1(config-if)#switchport private-vlan host-association 111 333 Sw1(config-if)#exit |
Configure a Layer 2 interface as a promiscuous port and map the PVLAN promiscuous port to the private VLAN and to the selected VLAN pair via the switchport mode private-vlan promiscuous and the switchport private-vlan mapping [primary vlan] [secondary vlans] interface configuration commands, as follows:
| Sw1(config)#int fast0/1
Sw1(config-if)#switchport mode private-vlan promiscuous Sw1(config-if)#switchport private-vlan mapping 111 222 333 Sw1(config-if)#exit |
Private VLAN Attacks
Now that we have an understanding of PVLANs, this section describes a Proxy Attack, which can be used to bypass access restrictions that are enforced by PVLANs. During a Proxy Attack, frames are forwarded to a host on the network that is connected to a promiscuous port. In this attack, both the source (attacker) and the destination (victim) are on the same subnet, but their direct communication has been restricted via PVLAN implementation. This attack is performed by the attacker sending a crafted packet that contains the following three elements:
- The source IP and MAC address of the machine compromised by the attacker;
- The destination IP address of the victim; and
- The destination MAC address of the upstream router connected to the promiscuous port.
This concept is illustrated in the following diagram:
Figure 6.14. Private VLAN Attacks
Referencing the diagram above, the attacker crafts a packet that contains his or her (Host 1) source IP and MAC addresses, the IP address of the intended target (Host 2), and the destination MAC address of the host connected to the promiscuous port (R1).
In step 1, when the switch receives this packet, it forwards it using the MAC address, not the IP address, and so it forwards the frame to R1 based on the destination MAC address. R1 receives this frame successfully.
In step 2, having received the packet, R1 looks at the IP address and notes that it belongs to Host 2. The router then forwards the packet to Host 2 and rewrites the destination MAC address to that of Host 2. The attack is successful and Host 1 is able to communicate with Host 2, while bypassing PVLAN restrictions.
The recommended method to prevent PVLAN attacks is to implement ACLs on the gateway(s), which are typically connected to promiscuous ports. For example, referring to the diagram used in the previous example, if Host 1 and Host 2 were on the 172.16.1.0/24 subnet, the following ACL would be used to prevent the hosts on this subnet from communicating with each other, thus preventing a PVLAN attack:
| R1(config)#access-list 100 remark ‘Prevent PVLAN Attacks'
R1(config)#access-list 100 deny ip 172.16.1.0 0.0.0.255 172.16.1.0 0.0.0.255 log R1(config)#access-list 100 permit ip any any R1(config)#interface fas 0/0 R1(config-if)#description ‘IINS PVLAN Gateway Connected to Sw1 FastEthernet0/1’ R1(config-if)#ip address 172.16.1.1 255.255.255.0 R1(config-if)#ip access-group 100 in |
Spanning-Tree Protocol Attacks
The Spanning-Tree Protocol (STP) is used in redundantly connected Layer 2 networks to prevent loops by placing interfaces or ports in either a blocking or a forwarding state. Because STP is a core component and requirement of the CCNA certification, this section will not be covered in detail. Instead, this section will focus on security features that can be enabled to secure switched networks that are running the Spanning-Tree Protocol.
STP attacks typically center on changing the root bridge of the Layer 2 network by injecting falsified Bridge Protocol Data Units information, which causes Spanning-Tree Protocol recalculations and effectively allows the attacker’s switch to become the root bridge of the Layer 2 network. When this happens, traffic is transmitted across the attacker’s switch, allowing him or her to view any and all data by using simple tools such as packet captures.
Cisco IOS Catalyst switches can be configured to allow administrators to enforce the placement of the root bridge in the Layer 2 network, prevent rogue switch network extensions, and ultimately mitigate STP attacks using the following two features:
- BPDU Guard
- Root Guard
BPDU Guard
The BPDU Guard feature is designed to keep the STP active topology predictable and to enhance network reliability by enforcing the STP domain borders. This feature either can be enabled globally (i.e. for the entire switch) or on a per-interface basis. In a valid switch configuration, ports configured for PortFast, which is used immediately to transition an interface on the switch to the forwarding state and is implemented on access ports, do not receive BPDUs.
Receiving a BPDU on an interface enabled for PortFast indicates an invalid configuration or possible security condition, i.e. the connection of an unauthorized device. The BPDU Guard feature places all ports with PortFast enabled that receive a BPDU into an error-disabled state. Once the interface has been placed into an error-disabled state, it must be enabled manually by the administrator, providing an additional layer of security, as well as a secure response to invalid configurations or possible security conditions.
At the global level, BPDU Guard is enabled by issuing the spanning-tree portfast bpduguard default global configuration command; and at the interface level, BPDU Guard is enabled by issuing the spanning-tree bpduguard enable interface configuration command. These two configuration options are illustrated in the following output:
| Sw1(config)#spanning-tree portfast bpduguard default
Sw1(config)#int fast0/1 Sw1(config-if)#spanning-tree bpduguard enable Sw1(config-if)#exit |
Once enabled, BPDU Guard can be validated by issuing the show spanning-tree summary. The information printed by this command is illustrated in the following output:
| Sw1#show spanning-tree summary
Switch is in pvst mode Root bridge for: VLAN0002 EtherChannel misconfiguration guard is enabled Extended system ID is enabled Portfast is disabled by default PortFast BPDU Guard is enabled by default Portfast BPDU Filter is disabled by default Loopguard is disabled by default UplinkFast is disabled BackboneFast is disabled Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active ———————- ——– ——— ——– ———- ———- VLAN0002 0 0 0 1 1 ———————- ——– ——— ——– ———- ———- 1 vlan 0 0 0 1 1 |
To verify BPDU Guard on a per-interface basis, the show spanning-tree interface [name] detail command can be used, as illustrated in the following output:
| Sw1#show spanning-tree interface fastethernet 0/1 detail
Port 1 (FastEthernet0/1) of VLAN0002 is forwarding Port path cost 19, Port priority 128, Port Identifier 128.1. Designated root has priority 32770, address 000d.bd06.4100 Designated bridge has priority 32770, address 000d.bd06.4100 Designated port id is 128.1, designated path cost 0 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 1 Link type is point-to-point by default Bpdu guard is enabled BPDU: sent 43, received 0 |
Root Guard
Root Guard is a Cisco Catalyst switch feature that allows administrators to identify the correct placement of the root switch in a Layer 2 network. The Root Guard feature is configured on any and all interfaces that are non-root ports. A root port, in a Spanning-Tree Protocol implementation, is any port on the switch that is closest to the root bridge of the Spanning-Tree-switched domain. The following diagram illustrates how the Root Guard feature would be implemented to prevent non-root ports from becoming root switches:
Figure 6.15. Root Guart on a Cisco Network
The diagram above illustrates a Layer 2-switched network consisting of five switches: Switch A through Switch E. The network administrators have decided to implement a predictable STP network and have configured Switch A as the STP root bridge by assigning a priority value of 4096 for all configured VLANs. For redundancy, the network administrators have configured Switch B with an STP priority value of 8192. Switches C, D, and E are all using default STP priority values of 32,768.
In this topology, there is no reason that Switch E should ever become the root bridge of the STP network. Therefore, the Root Guard feature can be enabled on the Switch C and Switch D interfaces that are connected to Switch E. This sets those interfaces as designated ports and if any device through those ports becomes the root bridge, perhaps through an incorrect configuration that results in superior BPDUs or via an STP attack, the interface will be placed into a root-inconsistent state. While the port is in this state, all traffic will be blocked by the switch. Additionally, the port will remain in this state until the superior BPDUs received on those ports are no longer being received.
Unlike the BPDU Guard feature, which can be enabled globally for the entire switch or on a per-interface basis, the Root Guard feature can only be enabled on a per-interface basis. This is performed via the spanning-tree guard root interface configuration command. The following configuration example illustrates how to configure the Root Guard feature on an interface:
| Sw1(config)#int fas 0/1
Sw1(config-if)#spanning-tree guard root Sw1(config-if)#exit |
Once configured, administrators can use the show spanning-tree interface [name] detail command to view Root Guard status on a per-interface basis, as follows:
| Sw1#show spanning-tree interface fastethernet 0/1 detail
Port 1 (FastEthernet0/1) of VLAN0002 is forwarding Port path cost 19, Port priority 128, Port Identifier 128.1. Designated root has priority 32770, address 000d.bd06.4100 Designated bridge has priority 32770, address 000d.bd06.4100 Designated port id is 128.1, designated path cost 0 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 1 Link type is point-to-point by default Bpdu guard is enabled Root guard is enabled on the port BPDU: sent 4860, received 0 |
Finally, the show spanning-tree inconsistentports command can be used to view inconsistent Spanning-Tree Protocol ports, as illustrated in the following output:
| Sw1#show spanning-tree inconsistentports
Name Interface Inconsistency ——————– ——————– —————— VLAN1 FastEthernet0/1 Root Inconsistent
Number of inconsistent ports (segments) in the system :1 |
Because BPDU Guard and Root Guard are among the most misunderstood topics, it is important to ensure that you have a solid understanding of the differences between these two features and of what their purposes are. The following table summarizes the BPDU Guard and Root Guard feature and what kind of STP attacks they are used to mitigate:
Table 6.3. BPDU and Root Guard Features
| STP Attack Type | STP Mitigation Technique | STP Mitigation Operation |
| Attacker attempts to connect an unauthorized network device, such as another switch, to an access port to gain access to the Layer 2-switched network | BPDU Guard, which is enabled globally or on a per-interface basis for all interfaces with PortFast enabled | BPDU Guard will error-disable an interface configured for PortFast that receives a BPDU |
| Attacker attempts to manipulate the STP root bridge so that all traffic is forwarded to his or her switch | Root Guard, which is enabled on a per-interface basis for all non-root ports on the switch | Root Guard will block all forwarding of packets on an interface that receives superior BPDUs that has this feature enabled |
DHCP Spoofing and Starvation Attacks
DHCP spoofing and starvation attacks are methods used by intruders to exhaust the DHCP address pool on the DHCP sever, resulting in resource starvation where there are no DHCP addresses available to be assigned to legitimate users.
DHCP is used to dynamically assign hosts with IP addresses. A DHCP server can be configured to provide DHCP clients with a great deal of information, such as DNS servers, NTP servers, WINS information, and default gateway (router) information. DHCP uses UDP port 68. Cisco IOS routers and some switches can be configured as both DHCP clients and DHCP servers.
When using DHCP on a network, the DHCP client sends a DHCPDISCOVER message to locate a DHCP server. This is a Layer 2 broadcast, because the client has no Layer 3 address, and so the message is directed to the Layer 2 broadcast address FFFF:FFFF:FFFF. If the DHCP server is on the same Layer 2 broadcast domain as the DHCP client, no explicit configuration is needed from a network configuration standpoint.
Upon receiving the DHCPDISCOVER message, the DHCP server offers network configuration settings to the client via the DHCPOFFER message. This message is sent only to the requesting DHCP client.
The client then sends another DHCPREQUEST broadcast message so that any other servers that had responded to the initial DHCPDISCOVER message, after the first issuing DHCP server, can reclaim the IP addresses they had offered to that client. Finally, the issuing DHCP server then confirms that the IP address has been allocated to the client by issuing a DHCPACK message to the requesting DHCP client.
The following diagram illustrates DHCP packet exchange between a DHCP client and server:
Figure 6.16. DHCP Packet Exchange
DHCP starvation attacks work on MAC address spoofing by flooding a large number of DHCP requests with randomly generated spoofed MAC addresses to the target DHCP server, thereby exhausting the address space available for a period of time. This prevents legitimate DHCP clients from being served by the DHCP server.
Once the legitimate DHCP server has been successfully flooded and can no longer service legitimate clients, the attacker then proceeds to introduce a rogue DHCP server, which then responds to the DHCP requests of legitimate clients with the intent of providing incorrect configuration information to the clients, such as default gateways and WINS or DNS servers. This forged information then allows the attacker to perform other types of attacks, such as MITM attacks. Common and readily available tools such as MACOF and GOBBLER can be used by attackers to perform DHCP starvation attacks.
There are several techniques that can be used to prevent such attacks from occurring. The first is port security, which can be used to limit the number of MAC addresses on a switch port and thus mitigate DHCP spoofing and starvation attacks. The second method is VLAN ACLs (VACLs), which are ACLs that are applied to entire VLANs and are used to control host communication within VLANs. VACLs are described later in this chapter. The third method, which is also the most recommended method, is to enable DHCP snooping.
DHCP Snooping Overview
The DHCP snooping feature provides network protection from rogue DHCP servers by creating a logical firewall between untrusted hosts and DHCP servers. When DHCP snooping is enabled, the switch builds and maintains a DHCP snooping table, which was described briefly in the section pertaining to DAI.
The DHCP snooping table is also referred to as the DHCP binding table, and it is used to prevent and filter untrusted messages from the network. In a manner similar to DAI, the DHCP snooping feature uses the concept of trusted and untrusted interfaces. For incoming packets received on untrusted ports, packets are dropped if the source MAC address of those packets does not match the MAC address in the binding table entry. The following diagram serves to illustrate the basic operation of the DHCP snooping feature:
Figure 6.17. DHCP Snooping
As illustrated in the diagram above, an attacker attempts to inject false DHCP responses into the exchange of DHCP messages between the DHCP client and server. However, because DHCP snooping is enabled on the switch, these packets are dropped because they are originating from an untrusted interface, and the source MAC address does not match the MAC address in the binding table entry.
However, the exchange between the legitimate client, who is also on an untrusted interface, and the DHCP server, which is on the trusted interface, is permitted because the source address does match the MAC address in the binding table entry. The following diagram illustrates the use of the DHCP snooping table that is used to filter untrusted DHCP messages from the network:
Figure 6.18. DCHP Snooping Table
In the diagram illustrated above, packets sourced from trusted ports are not subject to DHCP snooping checks. Trusted interfaces for DHCP snooping would be configured for ports directly connected to DHCP servers. However, all packets from untrusted interfaces are checked against the entries in the DHCP snooping table.
This means that if an attacker attempts to use randomly generated MAC addresses to initiate a DHCP snooping and starvation attack, all packets will be checked against the DHCP snooping table, and because there will be no matches for those specific MAC addresses, all packets will be discarded by the switch, effectively preventing this type of attack from occurring.
NOTE: The DHCP snooping feature is only supported in medium-and-high-end Cisco Catalyst switches, such as the Cisco 4500 and Cisco 6500 series switches. It is not supported on lower-end switches, such as the Cisco Catalyst 2950 and 3750 series switches.
Configuring DHCP Snooping
NOTE: The following section provides information on basic DHCP snooping configuration. You are not expected to perform advanced DHCP snooping configuration as part of the IINS course requirements. Configuring basic DHCP snooping involves three basic steps:
- Globally enabling DHCP snooping on the switch by issuing the ip dhcp snooping global configuration command;
- Enabling DHCP snooping for a VLAN or a range of VLANs by issuing the ip dhcp snooping vlan [vlan-number|vlan-range] global configuration command; and
- Configuring trusted interfaces for DHCP snooping by issuing the ip dhcp snooping trust interface configuration command. It is extremely important to remember that in order for DHCP snooping to function properly, all DHCP servers must be connected to the switch through trusted interfaces. All untrusted DHCP messages (i.e. messages from untrusted ports) will be forwarded only to trusted interfaces.
Optionally, network administrators can configure the switch to support the DHCP Relay Agent Information Option, which is DHCP option 82, by issuing the ip dhcp snooping information option global configuration command when configuring DHCP snooping on the switch.
Once DHCP snooping has been enabled, administrators can use the show ip dhcp snooping configuration to validate their configuration. The following example illustrates how to enable DHCP snooping for VLAN 100 and to enable DHCP Option 82 insertion. Additionally, interface FastEthernet5/24 is connected to a DHCP server and is configured as a trusted interface:
| Sw2(config)#ip dhcp snooping
Sw2(config)#ip dhcp snooping vlan 100 Sw2(config)#ip dhcp snooping information option Sw2(config)#int fast 5/24 Sw2(config-if)#ip dhcp snooping trust |
Once DHCP snooping has been enabled, the show ip dhcp snooping command can be used to validate DHCP snooping configuration, as illustrated in the following output:
| Sw2#show ip dhcp snooping
Switch DHCP snooping is enabled. DHCP Snooping is configured on the following VLANs: 100 Insertion of option 82 information is enabled. Interface Trusted Rate limit (pps) ——— ——- —————- FastEthernet5/24 yes none |
Additionally, administrators can also use the show ip dhcp snooping binding command to view DHCP snooping binding entries that correspond to untrusted ports. The information printed by this command is illustrated in the following output:
| Sw2#show ip dhcp snooping binding
MacAddress IP Address Lease (seconds) Type VLAN Interface ———– ———– —————- —– —– ———— 0021.8642.0b01 10.1.1.254 1600 dynamic 100 FastEthernet5/1 |
Identity Based Networking Services
The Cisco Identity Based Networking Services (IBNS) provides an important addition to the tools available for securing the network. The Cisco IBNS is an integrated solution combining several Cisco products that offer authentication, access control, and user policies to secure network access and resources. The IBNS solution extends network access security based on the 802.1x technology, Extensible Authentication Protocol (EAP) technologies, and the RADIUS security server service. IBNS provides identity-based network access control and policy enforcement at the port level.
Cisco IBNS offers scalable and flexible access control and policy enforcement services, as well as capabilities at the network edge (i.e. at switch access ports), by providing the following:
- Per-user or per-service authentication services
- Policies mapped to network identity
- Port-based network access control based on authentication and authorization policies
- Additional policy enforcement based on access level
Cisco Secure Access Control Server Basics
Cisco Secure Access Control Server (ACS) is a key component of IBNS. IBNS is primarily a security standard for port-based access control that combines IEEE 802.1x and Extensible Authentication Protocol (EAP), which will be described in detail later in this chapter, to extend AAA security inside the LAN. When the Cisco ACS server is used as the authentication server in IBNS, the following features are available for network security administrators:
- Time and day restrictions
- NAS restrictions
- MAC address filtering
- Per-user and per-group VLAN assignments
- Per-user and per-group ACL assignments
Additionally, the Cisco ACS RADIUS server supports internal and external user database sources such as Microsoft Active Directory, Novell NDS, and Lightweight Directory Access Protocol (LDAP). The external database support provides the flexibility and scalability of integrating into the existing user database structure, which simplifies its deployment.
IEEE 802.1x Basics
IEEE 802.1x is a protocol standard framework for both wired and wireless Local Area Networks that authenticates users or network devices and provides policy enforcement services at the port level to provide secure network access control. The 802.1x protocol provides the definition to encapsulate the transport of EAP messages at the Data Link Layer over any PPP or IEEE 802 media (e.g. Ethernet, FDDI, or Token Ring) through the implementation of a port-based network access control to a network device.
The 802.1x standard describes how the EAP messages are communicated between an end device, referred to as a supplicant, and an authenticator, which can be either a switch or a wireless access point. The authenticator relays the EAP information to the authentication server, e.g. a Cisco Secure ACS server, via the RADIUS security server protocol. There are three primary components (or roles) in the 802.1x authentication process:
- Supplicant or Client
- Authenticator
- Authentication Server
An IEEE 802.1x supplicant or client is simply an 802.1x-compliant device such as a workstation, a laptop, or even an IP phone with software that supports the 802.1x and EAP protocols. The supplicant client sends an authentication request to the access LAN via the connected authenticator device (e.g. the access switch) using EAP, as illustrated in the following diagram:
Figure 6.19. Authentication using EAP
Referring to the diagram above, the first step in the authentication process is the client or supplicant sending the authenticator an EAP over LAN (EAPoL) frame to start the authentication process. The switch responds to the EAPoL frame by sending the supplicant a login request, asking for the correct credentials (e.g. username and password pair) to gain network access, as illustrated in step 2.
In step 3, the supplicant provides the credentials to the authenticator, which then encapsulates them in RADIUS format and relays them to the RADIUS authentication server, as illustrated in step 4. When the RADIUS server receives the authentication request, it checks its database, which can be either internal or external, and then sends a response back, as illustrated in step 5. This response is relayed by the authenticator to the supplicant, as illustrated in step 6.
The supplicant provides the requested information, as illustrated in step 7, and the authenticator relays this information to the RADIUS server, as illustrated in step 8. Assuming that the check is successful and the credentials match and have been validated, the supplicant receives a permit access message, as illustrated in steps 9 and 10. The port then transitions to an authorized state and the supplicant is allowed to send packets onto the network. When the supplicant logs off the network, the port transitions to the unauthorized state and the login and authentication process will start over when the supplicant logs back on.
If the credentials are incorrect, the supplicant can also receive a deny message and will not be allowed access onto the LAN, and will also be blocked at the port level. The authorized and unauthorized port states are described, in detail, later in this chapter.
An 802.1x authenticator is a device that enforces physical access control to the network based on the authentication status (i.e. permit or deny) or the supplicant. An example of an authenticator would be the switch illustrated in the diagram in the previous example. The authenticator acts as a proxy and relays information between the supplicant and the authentication server.
The authenticator receives the identity information from the supplicant via EAPoL frames, which are verified and then encapsulated into RADIUS protocol format before being forwarded to the authentication server. It is important to remember that the EAP frames are not modified or examined during the encapsulation process, which means that the authentication server must support EAP within the native frame format. When the authenticator receives frames from the authentication server, the RADIUS header is removed, leaving only the EAP frame, which is then encapsulated in the 802.1x format. These frames are then sent back to the supplicant or client.
The authentication server is the database policy software, such as Cisco Secure ACS, that supports the RADIUS server protocol and performs authentication of the supplicant that is relayed by the authenticator via the RADIUS client-server model.
The authentication server validates the identity of the client and notifies the authenticator whether the client is allowed or denied access to the network. Based on the response from the authentication server, the authenticator relays this information back to the supplicant. It is important to remember that during the entire authentication process, the authentication server remains transparent to the client because the supplicant is communicating only to the authenticator. The RADIUS protocol with EAP extensions is the only supported authentication server; in other words, you cannot use TACACS+ or Kerberos as the authentication server.
EAP Technologies
While you are not expected to display advanced knowledge of the different types of EAP methods that are commonly used in the IBNS control solution, you should have a basic understanding of the different types of EAP technologies and their basic characteristics. This section provides a brief description of the following EAP technologies:
- EAP Message Digest 5 (MD5)
- EAP Transport Layer Security (TLS)
- EAP Flexible Authentication via Secure Tunneling (FAST)
- Protected EAP (PEAP)
- Cisco Lightweight Extensible Authentication Protocol (LEAP)
- EAP Tunneled TLS (EAP-TTLS)
EAP MD5 is a standards-based EAP type that uses an MD5 challenge, similar to that used by PPP CHAP authentication. EAP MD5 uses a series of EAP challenge request and response messages to validate supplicant credentials. In the event that the authentication process is successful, an EAP Success Notification message is sent from the authenticator to the client.
EAP TLS was designed by Microsoft to address weaknesses found in other EAP types. This EAP type is more complex than other EAP types and uses certificate-based (i.e. X.509) authentication. This means that both the supplicant and the authentication server must have a valid digital certificate in order to be able to perform mutual authentication. EAP TLS provides several advantages over other EAP types. These advantages include the following:
- It can provide encryption and authentication for each packet.
- Keys are exchanged using a standards-based approach.
- It supports the fragmentation and reassembly of packets (in a manner similar to PPP).
- It provides acknowledgements for both success and failure operations.
EAP FAST, which was developed by Cisco, protects authentication messages within a secure TLS tunnel. Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide security and data integrity for communications over networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end. EAP FAST uses shared secret keys, which are unique to each user and are referred to as protected access credentials (PACs). These PACs allow authentication to happen much faster than when digital certificates are used.
PEAP comes in several different forms. PEAP version 0 uses Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAPv2) and PEAP version 1 uses a Generic Token Card (GTC) for authentication. PEAP version 0 was co-developed by Cisco, Microsoft, and RSA and it increases the protection of authentication messages by creating a protected TLS tunnel, and then within this protected tunnel, an authentication protocol such as MS-CHAPv2 can then be used.
Cisco LEAP uses a username and password pair to perform authentication. This version of EAP is typically found in Cisco wireless LAN (WLAN) implementations. WLAN implementations are beyond the scope of the IINS course requirements.
EAP-TTLS uses a secured TLS tunnel to send other authentication messages. Like Cisco LEAP, EAP-TTLS is beyond the scope of the IINS course requirements.
802.1x Port States and Authentication Flowchart
When 802.1x is enabled on the authenticator, there are two port states in which the physical ports on the authenticator may be: the authorized and unauthorized states. Initially, all 802.1x-enabled ports start off in an unauthorized state. In this state, no traffic is allowed through the port except for 802.1x message exchange packets.
If a non-802.1x connects to an unauthorized port, the authenticator has no way of knowing that the client does not support 802.1x, and so it sends the client a login request asking for identity credentials. However, because the client does not support 802.1x, the client is unable to interpret the received packet and does not respond to the authenticator’s request.
Based on this, the authenticator denies all packets on that port and the switch port remains in the unauthorized state. Administrators control the port authorization state by using the dot1x port-control interface configuration command and one of the following keywords:
- The force-authorized keyword—this disables 802.1X and causes the port to transition to the authorized state without any authentication exchange required. The port transmits and receives normal traffic without 802.1X-based authentication of the client. This is by default.
- The force-unauthorized keyword—this causes the port to remain in the unauthorized state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the interface.
- The auto keyword—this enables 802.1X authentication and causes the port to begin in the unauthorized state, allowing only EAPoL frames to be sent and received through the port. The authentication process begins when the link state of the port transitions from down to up, or when an EAPoL-start frame is received. The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. Each client attempting to access the network is uniquely identified by the switch by using the client’s MAC address.
While this is by default, it is important to understand that if the authenticator is a Cisco Catalyst switch, the user may not necessarily be blocked but could instead be assigned to a guest or a restricted VLAN. Both VLAN types will be described in the next section.
Inversely, if an 802.1x-compliant device connects to a port that is not running 802.1x, the client initially begins to send EAPoL start packets, but because there is no response from the authenticator, the client assumes that 802.1x authentication is not required and continues to send packets as though the port were in an authorized state. The switch does not block access because there is no 802.1x enabled on that port, even though the client is an 802.1x-compliant client. The following diagram, provided by Cisco for the Catalyst 3560 switches, illustrates the 802.1x authentication flowchart:
Figure 6.20. 802.1x Authentication Flowchart
802.1x VLAN Assignment and RADIUS Attributes
AAA Authorization must be enabled on the authenticator if network-related services such as per-user or per-group VLAN assignment on 802.1x authenticated ports are required. While Cisco Secure ACS configuration is beyond the scope of the IINS course requirements, it is important to know that there are two types of RADIUS server selections available in Cisco ACS that can be selected to achieve this purpose, and both options can be used when defining the authenticator as the AAA client in the network configuration on Cisco Secure ACS. These two options are:
- RADIUS (IETF)
- RADIUS (Cisco IOS/PIX 6.0)
When the RADIUS (IETF) server is selected as the NAS type in Cisco Secure ACS, the following three attributes must be returned to the switch for 802.1x authentication:
- [RADIUS Attribute 64] Tunnel-Type=VLAN. RADIUS attribute 64 must contain the value ‘VLAN’, which is type 13;
- [RADIUS Attribute 65] Tunnel-Medium-Type=802. RADIUS attribute 65 must contain the value ‘802’, which is type 6; and
- [RADUIS Attribute 81] Tunnel-Private-Group-ID=VLAN NAME. RADIUS attribute 81 contains the VLAN name of VLAN ID assigned to the authenticated user.
When RADIUS (Cisco IOS/PIX 6.0) is selected as the NAS type in Cisco Secure ACS, the vendor-specific AV-Pair (Attribute 26) must be used to download attribute 64, 65, and 81 to be returned to the switch for 802.1x authentication, and the values are as follows:
- cisco-avpair=’tunnel-type(#64)=VLAN(13)’
- cisco-avpair=’tunnel-medium-type(#65)=802 media(6)’
- cisco-avpair=’tunnel-private-group-ID(#81)=vlan_name or vlan_id’
In addition to standard VLANs, Cisco Catalyst switches (authenticators) also support guest VLANs. These VLANs are used for clients that do not support or are not enabled for 802.1x and are connected to a switch port configured for 802.1x authentication. Guest VLANs typically have limited access to network resources, such as the Internet, for example. As a network administrator, you can use the dot1x guest-vlan interface configuration command on the switch to specify an active VLAN as an IEEE 802.1x guest VLAN. However, in Cisco IOS Catalyst switches running IOS version 12.2(25)SE, administrators can use the dot1x guest-vlan supplicant global configuration command to enable this behavior
Restricted VLANs are also supported when Cisco Catalyst switches are authenticators in an 802.1x-enabled network. Unlike guest VLANs, which support clients that are not enabled for 802.1x authentication, a restricted VLAN can be used to provide limited network access to clients that are 802.1x-enabled but that have failed authentication. In a manner similar to that of guest VLANs, restricted VLANs also typically have limited access to network resources. If administrators choose to use the restricted VLAN feature, they must be aware of the following restrictions that pertain to these types of VLANs:
- Restricted VLANs are only supported on static access ports, i.e. not on trunk ports, etc.
- Restricted VLANs are compatible only when a switch is running in single-host mode.
- Restricted VLANs cannot be used for Remote SPAN (RSPAN).
- Restricted VLANs cannot be used as voice VLANs, sometimes called auxiliary VLANs.
NOTE: Remote SPAN (RSPAN) is beyond the scope of the IINS course requirements.
A switch can be configured to place a port in the configured restrictive VLAN after a connected client fails to successfully authenticate after a certain number of tries by issuing the dot1x auth-fail max-attempts interface configuration command on the switch port.
Configuring Basic 802.1x Port-Based Authentication
Configuring basic 802.1x port-based authentication is a relatively straightforward process that is comprised of the following four basic steps:
- Globally enable AAA services on the switch by issuing the aaa new-model global configuration command. AAA must be enabled before a switch can be configured for 802.1x port-based authentication services;
- Create or use the default 802.1X authentication method list and specify RADIUS server information by issuing the aaa authentication dot1x [method-list|default] group [name|radius] global configuration command;
- Configure RADIUS server parameters (e.g. keys and ports) via the radius-server host global configuration command for an individual server or the aaa group server radius global configuration command for a RADIUS server group; and
- Enable 802.1x port-based authentication on desired switch ports by issuing the dot1x port-control auto interface configuration command.
To reinforce these configuration steps and familiarize you with the configuration of 802.1x port-based authentication services, we will be going over a few configuration examples. The first configuration example illustrates the configuration of 802.1x port-based authentication on the FastEthernet0/23 and FastEthernet0/24 interfaces of a Cisco Catalyst switch. A RADIUS server with the IP address and secret key d0t!xauth will be configured to authentication 802.1x users. This RADIUS server will have the IP address 10.1.1.254 and will use UDP port 1812 for Authentication services:
| Sw1(config)#aaa new-model
Sw1(config)#aaa authentication dot1x default group radius Sw1(config)#radius-server host 10.1.1.254 auth-port 1812 key d0t!xauth Sw1(config)#interface range fastethernet0/23 – 24 Sw1(config-if-range)#switchport mode access Sw1(config-if-range)#dot1x port-control auto Sw1(config-if-range)#exit |
The second configuration example illustrates how to configure IEEE 802.1x port-based authentication against a RADUIS server group named DOT1X-RADIUS, which contains servers 10.1.1.254, 11.1.1.254, and 12.1.1.254. In addition to this, 802.1x port-based authentication will be configured to use the method list DOT1X-LIST for authentication. 802.1x port-based authentication will be enabled on the FastEthernet0/12 interface of the switch:
| Sw1(config)#aaa new-model
Sw1(config)#aaa authentication dot1x DOT1X-LIST group DOT1X-RADIUS Sw1(config)#aaa group server radius DOT1X-RADIUS Sw1(config-sg-radius)#server 10.1.1.254 Sw1(config-sg-radius)#server 11.1.1.254 Sw1(config-sg-radius)#server 12.1.1.254 Sw1(config-sg-radius)#exit Sw1(config)#int f0/12 Sw1(config-if)#switchport mode access Sw1(config-if)#dot1x port-control auto Sw1(config-if)#exit |
The third and final configuration example illustrates how to enable 802.1x port-based authentication for port FastEthernet0/1 against a RADIUS server with the IP address 172.16.1.254, using default RADIUS port values. Additionally, FastEthernet0/2 will have 802.1x port-based authentication disabled so that the port can transition to the authorized state without any authentication exchange required; and FastEthernet0/3 will have 802.1x port-based authentication enabled but will be configured to remain in the unauthorized state:
| Sw1(config)#aaa new-model
Sw1(config)#aaa authentication dot1x default group radius Sw1(config)#radius-server host 172.16.1.254 Sw1(config)#int f0/1 Sw1(config-if)#switchport mode access Sw1(config-if)#dot1x port-control auto Sw1(config-if)#exit Sw1(config)#int f0/2 Sw1(config-if)#switchport mode access Sw1(config-if)#dot1x port-control force-authorized Sw1(config-if)#exit Sw1(config)#int f0/3 Sw1(config-if)#switchport mode access Sw1(config-if)#dot1x port-control force-unauthorized Sw1(config-if)#exit |
It is important to remember to configure the switch port as a static access port before enabling 802.1x port-based authentication; otherwise, the following error message will be received:
| Sw1(config)#int f0/15
Sw1(config-if)#dot1x port-control auto % Error: 802.1X can not be configured on a dynamic port |
Once 802.1x has been implemented and configured, administrators can use the show dot1x [options] command to view 802.1x configuration parameters and statistics on Cisco Catalyst switches. For example, to view the 802.1x configuration of an interface, administrators should issue the show dot1x interface [name] command, as illustrated in the following output:
| Sw1#show dot1x interface fastethernet 0/1
802.1X is enabled on FastEthernet0/1 Status Unauthorized Port-control Auto Supplicant Not set Multiple Hosts Disallowed Current Identifier 2
Authenticator State Machine State CONNECTING Reauth Count 2
Backend State Machine State IDLE Request Count 0 Identifier (Server) 0
Reauthentication State Machine State INITIALIZE |
For troubleshooting purposes, administrators can use the show dot1x statistics interface [name] command to view 802.1x statistics on a per-interface basis, as illustrated below:
| Sw1#show dot1x statistics interface fastethernet 0/1
FastEthernet0/1
Rx: EAPOL EAPOL EAPOL EAPOL EAP EAP EAP Start Logoff Invalid Total Resp/Id Resp/Oth LenError 0 0 0 0 0 0 0
Last Last EAPOLVer EAPOLSrc 0 0000.0000.0000
Tx: EAPOL EAP EAP Total Req/Id Req/Oth 23 13 0 |
IEEE 802.1x Attacks
As we learned in the previous section, the 802.1x framework defines the guidelines for packaging EAP messages by using the EAPoL protocol, which is Ethernet frames using the EAP encapsulation over Local Area Networks. While EAPoL is a relatively secure protocol, it is important to know that there are two critical vulnerabilities present in EAPoL:
- The injection of spoofed EAP-Success messages; and
- The ability of attackers to hijack the session.
The first critical vulnerability is the injection of a spoofed EAP-Success message towards the end of the EAPoL authentication sequence, resulting in an MITM attack. The EAP-Success message is sent from the authenticator to the supplicant, and this message does not have any integrity check to ensure that message has not been altered as it traversed from the authenticator to the supplicant. Attackers can take advantage of this and send an unsolicited forged EAP-Success message to the supplicant that appears to come from the authenticator, allowing the attacker passively to establish a path between the supplicant and the authenticator.
The second critical vulnerability that exists is that an intruder can hijack an existing session that is established. After the supplicant has successfully been authenticated, the authenticator and supplicant both move to the authenticated state. An intruder can take advantage of this and send a crafted dissociate frame to the supplicant, spoofing the MAC address of the authenticator. This causes the supplicant to assume the message is coming from the authenticator, and the supplicant terminates the session. However, because the authenticator did not send the message, it remains in the authenticated state and the attacker simply spoofs the source MAC address of the former legitimate supplicant and gains network access by assuming that supplicant’s identity. The authenticator has no way to validate that the legitimate supplicant is still connected and the session is therefore considered hijacked.
Mitigating 802.1x Attacks
There is no integrity mechanism available in the EAPoL protocol that can mitigate against an 802.1x attack. Therefore, the recommended solution is to use PEAP instead. The PEAP authentication protocol was developed to address these and other concerns pertaining to 802.1x security. PEAP offers integrity by implementing the authentication sequence in two distinct parts:
- A TLS session is established between the supplicant and the PEAP authentication server; and
- The EAP exchange is carried out over the TLS session to authenticate the supplicant.
Other Cisco Catalyst Switch Security Features
The final section in this chapter describes some other Cisco Catalyst switch security features, as follows:
- Storm Control
- Protected Ports
- Port Blocking
- Port ACLs
- VLAN ACLs
- MAC ACLs
- IP Source Guard
Storm Control
The storm control feature, also referred to as the traffic suppression feature, prevents network traffic from being disrupted by a Broadcast, Multicast, or Unicast packet storm (i.e. flood) on any of the physical interfaces on the Cisco Catalyst switch. This feature monitors inbound packets on a physical interface over a 1-second interval and compares them to a configured storm control suppression level by using one of the following methods to measure the packet activity:
- The percentage of total bandwidth available of the port allocated for Broadcast, Multicast, or Unicast traffic; or
- The traffic rate over a 1-second interval in packets-per-second (pps) at which Broadcast, Multicast, or Unicast packets are received on the interface.
Regardless of the method used, packets are blocked until the traffic rate drops below the configured suppression level, at which point the port resumes normal forwarding. The storm control feature is enabled by issuing the storm-control interface configuration command. The options available with this command are as follows:
| Sw1(config)#int fastethernet0/1
Sw1(config-if)#storm-control ? action Action to take for storm-control broadcast Broadcast address storm control multicast Multicast address storm control unicast Unicast address storm control |
The action keyword is used to specify the action that the port will enforce in the event of a violation of the configured policy. There are two possible actions that can be defined, either shutdown the port or generate and send an SNMP trap, as illustrated below:
| Sw1(config)#int fastethernet0/1
Sw1(config-if)#storm-control action ? shutdown Shutdown this interface if a storm occurs trap Send SNMP trap if a storm occurs |
The broadcast, multicast, and unicast keywords are used to define storm control parameters for Broadcast, Multicast, and Unicast traffic, respectively. For example, to block Broadcast traffic if it exceeds 50 per cent of the physical port bandwidth, the following configuration would be implemented on a switch port:
| Sw1(config)#int fast 0/2
Sw1(config-if)#storm-control broadcast level 50 |
The following example illustrates how to block all Multicast traffic if it exceeds 80 per cent of the physical port bandwidth but resumes all normal forwarding when it falls below 40 per cent:
| Sw1(config)#int fastethernet 0/2
Sw1(config-if)#storm-control multicast level 80 40 |
Storm control configuration can be validated by issuing the show storm-control [options] command. For example, to view configured storm control parameters for FastEthernet0/2 on a Cisco Catalyst switch, the following command would be issued:
| Sw1#show storm-control fastethernet 0/2 broadcast
Interface Filter State Trap State Upper Lower Current Traps Sent ——— ————- ————- ——- ——- ——- ———- Fa0/2 Forwarding inactive 50.00% 50.00% 0.00% 0 Sw1# Sw1#show storm-control fastethernet 0/2 multicast Interface Filter State Trap State Upper Lower Current Traps Sent ——— ————- ————- ——- ——- ——- ———- Fa0/2 Forwarding inactive 80.00% 40.00% 0.00% 0 Sw1# Sw1#show storm-control fastethernet 0/2 unicast Interface Filter State Trap State Upper Lower Current Traps Sent ——— ————- ————- ——- ——- ——- ———- Fa0/2 inactive inactive 100.00% 100.00% N/A 0 |
Protected Ports
Protected ports operate in a similar manner to private VLANs. These ports have the following characteristics when enabled on Cisco Catalyst switches:
- The switch will not forward any traffic between ports that are configured as protected; any data must be routed via a Layer 3 device between the protected ports;
- Control traffic, such as routing protocol traffic, is considered an exception and will be forwarded between protected ports; and
- Forwarding between protected and non-protected ports proceeds normally, i.e. protected ports can communicate with non-protected ports without using a Layer 3 device.
By default, no ports are protected. However, administrators can enable this feature by issuing the switchport protected interface configuration command on all interfaces that they want to become protected ports. The following example illustrates how to configure a protected port:
| Sw1(config)#int fastethernet 0/4
Sw1(config-if)#switchport protected |
Once configured, administrators can validate protected port status by issuing the show interfaces [name] switchport command, as illustrated in the following output:
| Sw1#show interfaces fastethernet 0/4 switchport
Name: Fa0/4 Switchport: Enabled Administrative Mode: dynamic desirable Operational Mode: down Administrative Trunking Encapsulation: dot1q Negotiation of Trunking: On Access Mode VLAN: 2 (VLAN0002) Trunking Native Mode VLAN: 1 (default) Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: none Operational private-vlan: none Trunking VLANs Enabled: ALL Pruning VLANs Enabled: 2-1001 Capture Mode Disabled Capture VLANs Allowed: ALL
Protected: true
Voice VLAN: none (Inactive) Appliance trust: none |
Port Blocking
NOTE: Port blocking is only supported in Cisco Catalyst 3750 switches and above. It is not supported on lower-end switches, such as the Cisco Catalyst 2950.
When a packet arrives at a switch port, the switch performs a CAM table lookup to determine the port that it will use to send the packet to its destination. If no entry is found for the destination MAC address, the switch will flood the packet out of all interfaces, except for the interface on which the packet was received, and wait for a response. While this default behavior is generally acceptable, it is important to understand that from a security perspective, the forwarding of unknown traffic to a protected port could raise security issues.
To address these concerns, Cisco Catalyst switches can be configured to block unknown Unicast and Multicast traffic from being forwarded on a per-interface basis. This is performed by using the switchport block [multicast|unicast] interface configuration command. The following example illustrates how to block unknown Unicast and Multicast packets on a particular port:
| Sw1(config)#int fast 0/6
Sw1(config-if)#switchport block multicast Sw1(config-if)#switchport block unicast |
This configuration can be validated by issuing the show interfaces [name] switchport command, as illustrated in the following output:
| Sw1#show interfaces fastethernet 0/6 switchportName: Fa0/6Switchport: EnabledAdministrative Mode: dynamic autoOperational Mode: downAdministrative Trunking Encapsulation: negotiateNegotiation of Trunking: OnAccess Mode VLAN: 1 (default)Trunking Native Mode VLAN: 1 (default)Trunking VLANs Enabled: ALLPruning VLANs Enabled: 2-1001 Protected: falseUnknown unicast blocked: enabledUnknown multicast blocked: enabled |
Port ACLs
NOTE: Complete PACLs are only supported in medium-and-high-end Cisco Catalyst switches, such as the Cisco 4500 and Cisco 6500 series switches. They are not supported on lower-end switches, such as the Cisco Catalyst 2950 and 3750 series switches.
Port ACLs, or PACLs, are similar to router ACLs but are supported and configured on Layer 2 (i.e. non-routed) interfaces on a switch. PACLs are supported on physical interfaces and EtherChannel interfaces. The following access lists are supported on Layer 2 interfaces:
- Standard IP ACLs
- MAC extended ACLs
- Extended IP ACLs
The main advantage afforded by PACLs is that they can be used to filter both IP (i.e. IP standard and IP extended ACLs) and non-IP (i.e. MAC ACLs) traffic on a Layer 2 interface. The following output illustrates how to configure a PACL using an extended IP ACL:
| Sw4(config)#ip access-list extended MY-IP-PACL
Sw4(config-ext-nacl)#permit ip any any Sw4(config-ext-nacl)#exit Sw4(config)#interface fastethernet 5/1 Sw4(config)#switchport mode access Sw4(config)#switchport access vlan 15 Sw4(config-if)#ip access-group MY-IP-PACL in |
The following example illustrates how a MAC ACL can be applied to a switch port:
| Sw4(config)#mac access-list extended MY-MAC-PACL
Sw4(config-ext-macl)#permit host 1a2b.1111.cdef any Sw4(config-ext-macl)#exit Sw4(config)#interface fastethernet 6/1 Sw4(config)#switchport mode access Sw4(config)#switchport access vlan 7 Sw4(config-if)#mac access-group MY-MAC-PACL out |
Cisco IOS software allows administrators to use the access-group mode interface configuration command to change the way PACLs interact with other ACLs, such as VLAN ACLs (VACLs) that may be configured for the VLAN that the Layer 2 interface is also configured for. In a per-interface fashion, the access-group mode command can be implemented with one of the following keywords:
- The prefer port keywords—If PACL is configured on a Layer 2 interface, then the PACL takes effect and overwrites the effect of other ACLs configured on the interface, or for the entire VLAN. However, if no PACL is configured on the Layer 2 interface, other features applicable to the interface are merged and applied on the interface. This is by default.
- The prefer vlan keywords—When used, VLAN-based ACL features take effect on the port provided they have been applied on the port and no PACLs are in effect. If no VLAN-based ACL features are applicable to the Layer 2 interface, then the PACL feature already on the interface is applied.
- The merge keyword—This command merges applicable ACL features before they are programmed into the switch hardware.
NOTE: You are not expected to perform any advanced PACL configurations, as they are beyond the scope of the IINS course requirements. Therefore, no configuration examples are provided on the access group mode feature.
VLAN ACLs
NOTE: VACLs are only supported in medium-and-high-end Cisco Catalyst switches, such as the Cisco 4500 and Cisco 6500 series switches. They are not supported on lower-end switches, such as the Cisco Catalyst 2950 and 3750 series switches.
VLAN ACLs, or VACLs, are also commonly referred to as VLAN maps. These ACLs provide filtering capabilities for all traffic types (i.e. IP and non-IP) that are bridged within a VLAN or routed into or out of the VLAN. Unlike traditional router ACLs, VACLs are not defined by an inbound or outbound direction. Instead, all packets entering or leaving the VLAN are checked against the configured VACL.
VACLs are processed in switch hardware and therefore do not cause any performance impact when implemented on switches. VACL configuration is a straightforward process that is performed in three steps:
- Create the extended IP ACL that matches the desired packets using either the IP or MAC address against one or more standard or extended access lists;
2. Configure the VLAN access map, which is an ordered list of entries, that will be used to match the ACL(s) configured in step 1. This is performed via the vlan access-map global configuration command. In addition, the VLAN access map must be configured to drop or forward the packets matched in the ACL by using the action [drop|forward] VLAN access map configuration command; and
3. Apply a VLAN map to one or more VLANs by using the vlan filter [map-name] vlan-list [list-of-vlans] global configuration command.
While you are not expected to perform advanced VACL configurations, you are expected to be familiar with the configuration of simple VACLs. The following configuration example illustrates how to configure an extended IP ACL named ALLOW-TCP that permits all TCP traffic, match that ACL using a VLAN access map named MY-VACL-MAP, which allows this traffic to be forwarded, and apply the configuration to VLAN 22 via a VLAN map named VLAN-22-MAP:
| Sw4(config)#ip access-list extended ALLOW-TCP
Sw4(config-ext-nacl)#permit tcp any any Sw4(config-ext-nacl)#exit Sw4(config)#vlan access-map MY-VACL-MAP Sw4(config-access-map)#match ip address ALLOW-TCP Sw4(config-access-map)#action forward Sw4(config-access-map)#exit Sw4(config)#vlan filter map VLAN-22-MAP vlan-list 22 |
The following configuration example illustrates how to configure an extended IP ACL named DENY-UDP that permits all UDP traffic, match that ACL using a VLAN access map named UDP-DROP-VACL-MAP, which allows this traffic to be dropped, and apply the configuration to VLANs 11-15 via a VLAN map named VLAN-11-To-15-MAP:
| Sw4(config)#ip access-list extended DENY-UDP
Sw4(config-ext-nacl)#permit udp any any Sw4(config-ext-nacl)#exit Sw4(config)#vlan access-map UDP-DROP-VACL-MAP Sw4(config-access-map)#match ip address DENY-UDP Sw4(config-access-map)#action drop Sw4(config-access-map)#exit Sw4(config)#vlan filter map VLAN-11-To-15-MAP vlan-list 11-15 |
Administrators can then use the show vlan access-map command to view VACL configuration. The information printed by this command is provided in the following output:
| Sw4#show vlan access-map
Vlan access-map ” MY-VACL-MAP ” 10 Match clauses: ip address: ALLOW-TCP Action: drop
Vlan access-map ” UDP-DROP-VACL-MAP ” 10 Match clauses: ip address: DENY-UDP Action: forward |
The following restrictions should be kept in mind when configuring VACLs:
- VLAN maps do not filter IPv4 ARP packets.
- If there is no router ACL configured to deny traffic on a routed VLAN interface (input or output), and no VLAN map configured, all traffic is permitted.
- Each VLAN map consists of a series of entries. The order of entries in a VLAN map is important. A packet that comes into the switch is tested against the first entry in the VLAN map. If it matches, the action specified for that part of the VLAN map is taken. If there is no match, the packet is tested against the next entry in the map.
- If the VLAN map has at least one match clause for the type of packet (IP or MAC) and the packet does not match any of these match clauses, the default is to drop the packet. If there is no match clause for that type of packet in the VLAN map, the default is to forward the packet.
- The system might take longer to boot if you have configured a large number of ACLs.
MAC ACLs
MAC ACLs, also referred to as Ethernet ACLs, can filter non-IP traffic on a VLAN (i.e. be used in conjunction with VACLs) as well as on a port (i.e. be used as a PACL). The configuration logic of MACLs follows that of extended IP ACLs. While delving into advanced MACL configuration is beyond the requirements of the IINS course requirements, the following example illustrates how to configure and apply an MACL that permits DECNET Spanning-Tree Protocol and NETBOIS:
| Sw1(config)#mac access-list extended MY-MAC-ACL
Sw1(config-ext-macl)#permit any any dec-spanning Sw1(config-ext-macl)#permit any any netbios Sw1(config-ext-macl)#exit Sw1(config)#int fa 0/10 Sw1(config-if)#mac access-group MY-MAC-ACL in Sw1(config-if)#exit |
Once they have been configured and implemented, MACLs can be validated by issuing the show mac access-group [options] command. For example, to view the MACL configured on FastEthernet0/10, the following commands would be executed:
| Sw1#show mac access-group interface fastethernet 0/10
Interface FastEthernet0/10: Inbound access-list is MY-MAC-ACL |
IP Source Guard
NOTE: IP Source Guard is only supported in Cisco Catalyst 3750 switches and above. It is not supported on lower-end switches, such as the Cisco Catalyst 2950 series switches.
IP Source Guard is a feature that restricts IP traffic on untrusted Layer 2 ports by filtering the traffic based on the DHCP snooping binding database or manually configured IP source bindings. This feature is used to prevent IP spoofing attacks. Any traffic coming into the interface with a source IP address other than that assigned via DHCP or static configuration will be filtered out on the untrusted Layer 2 ports.
The IP Source Guard feature is typically enabled in combination with DHCP snooping on untrusted Layer 2 interfaces. IP Source Guard builds and maintains an IP source binding table that is learned by DHCP snooping or manually configured bindings. Entries in the IP source binding table contain the IP address and the associated MAC and VLAN numbers. The IP Source Guard feature is only supported on Layer 2 interfaces, which include access and trunk links. The IP Source Guard feature is enabled by issuing the ip verify source interface configuration command on Layer 2 interfaces.
Additionally, port security can be enabled by issuing the ip verify source port security interface configuration command. However, it is important to remember that this configuration command requires the global configuration command ip dhcp snooping information option, which allows the DHCP server to support DHCP option 82. DHCP option 82 is simply the DHCP Relay Agent Information Option. All other advanced DHCP options and IP Source Guard configuration are beyond the scope of the IINS course requirements.
Chapter Summary
The following section is a summary of the major points you should be aware of in this chapter:
LAN Switching Overview
- Switches operate at the Data Link Layer of the OSI Model and send frames
- Frames sent by switches contain source and destination MAC addresses
- The source and destination MAC addresses are stored in the switch MAC address table
- The MAC address table is commonly referred to as the CAM table
- Content Addressable Memory is a memory type used in high-speed searching applications
- The switch CAM table is viewed by issuing the show mac-address-table command
- A VLAN is a logical grouping of hosts
- VTP is a Cisco proprietary Layer 2 messaging protocol that manages VLANs network-wide
- VTP packets are sent across the trunk links in either ISL or in IEEE 802.1Q frames
- Trunk ports are used to carry traffic that belongs to multiple VLANs
- Spanning-Tree Protocol is used to prevent loops in switched networks
CAM Table Overflow Attacks
- Attackers can exploit CAM memory limitation with a large number of MAC addresses
- The recommended method to mitigate against such attacks is to implement port security
- Port security can be implemented in three ways:
- Static Secure MAC Addresses
- Dynamic Secure MAC Addresses
- Sticky Secure MAC Addresses
- When a port security violation is detected, switches can perform the following actions:
- Protect
- Shutdown
- Restrict
The port security feature has two types of aging methods or mechanisms:
- Absolute
- Inactivity
MAC Spoofing Attacks
- MAC spoofing is used to spoof a source MAC address impersonate other hosts or devices
- MAC spoofing confuses the switch and it believes the same MAC is connected to two ports
- MAC spoofing attacks can be mitigated by implementing port security
ARP Spoofing Attacks
- ARP spoofing attacks are used by attackers to disguise their source MAC address
- ARP spoofing occurs during the ARP request and reply messaging between two hosts
- ARP spoofing attacks can be implemented by implementing Dynamic ARP Inspection
- DAI is a security feature that validates ARP packets in a network
- DAI validates ARP packets by performing an IP-to-MAC address binding inspection
- DAI can be implemented in DHCP or non-DHCP environments
VTP Attacks
- VTP attacks include the sending of malformed VTP packets to these switches
- To mitigate VTP attacks, administrators should configure a VTP password
- Additionally, administrators can also implement VTPv3, which has the following features:
- Support for extended VLANs
- Support for the creation and advertising of private VLANs
- Support for VLAN instances and MST mapping propagation instances
- Improved server authentication
- Protection from the “wrong” database accidentally being inserted into a VTP domain
- Interaction with VTP version 1 and VTP version 2
- Ability to be configured on a per-port basis
VLAN Hopping Attacks
- VLAN hopping attacks bypass a Layer 3 device to communicate directly between VLANs
- There are two primary methods used to perform VLAN hopping attacks:
- Switch spoofing
- Double-tagging
- In switch spoofing, the attacker impersonates a switch
- Double-tagging attacks involve tagging frames with two 802.1Q tags
- VTP attacks can be mitigated by performing the following:
- Disable DTP on trunk ports
- Disable trunking capabilities on ports that should not be configured as trunk links
- Prevent user data from traversing the native VLAN
- Ensuring the native VLAN on trunks is different from the VLAN ID of user VLANs
PVLAN Attacks
- Private VLANs prevent inter-host communication by providing port-specific security
- The private VLAN feature uses three different types of ports:
- Community
- Isolated
- Promiscuous
The three types of VLANs used in PVLANs are:
- Primary VLANs
- Community VLANs
- Isolated VLANs
- PVLAN attacks are performed by r sending a crafted packet that contains the following:
- The source IP and MAC address of the machine compromised by the attacker
- The destination IP address of the victim
- The destination MAC address of the upstream router connected to the promiscuous port
- PVLAN attacks can be mitigated by implementing ACLs on the promiscuous port
Spanning-Tree Protocol Attacks
- STP is used in redundantly connected switched networks to prevent Layer 2 loops
- STP attacks typically center on changing the root bridge of the Layer 2 network
- STP attacks can be mitigated by implementing two features:
- BPDU Guard
- Root Guard
- The following table highlights the scenarios in which these features would be implemented:
| STP Attack Type | STP Mitigation Technique | STP Mitigation Operation |
| Attacker attempts to connect an unauthorized network device, such as another switch to an access port to gain access to the Layer 2 switched network | BPDU Guard, which is enabled globally or on a per-interface basis for all interfaces with PortFast enabled | BPDU Guard will error-disable an interface configured for PortFast that receives a BPDU |
| Attacker attempts to manipulate the STP root bridge so that all traffic is forwarded to their switch | Root Guard, which is enabled on a per-interface basis for all non-root ports on the switch | Root Guard will block all forwarding of packets on an interface which receives superior BPDUs that has this feature enabled |
DHCP Spoofing and Starvation Attacks
- These attacks are methods used by intruders to exhaust the DHCP address pool
- The following solutions can be implemented to mitigate against these attacks:
- Port Security
- VLAN ACLs, or VACLs
- DHCP Snooping
- DHCP snooping creates a logical firewall between untrusted hosts and DHCP servers
- This feature builds a DHCP snooping table which is used to validate packets
Identity Based Networking Services
- IBNS is an integrated solution that offers authentication, access control and user policies
- IBNS extends network access security based on the 802.1x, EAP, and RADIUS
- IBNS provides identity-based access control and policy enforcement at the port level
- Cisco IBNS provides the following:
- Per-user or per-service authentication services
- Policies mapped to network identity
- Port-based network access control based on authentication and authorization policies
- Additional policy enforcement based on access level
- IEEE 802.1x is a protocol standard framework that authenticates users or network devices
- IEEE 802.1x provides policy enforcement services at the port level
- IEEE 802.1x allows for the encapsulation of EAP messages at the Data Link Layer
- There are three primary components (or roles) in the 802.1x authentication process:
- Supplicant or Client
- Authenticator
- Authentication Server
- The most common types of EAP technologies are:
- EAP Message Digest 5 (MD5)
- EAP Transport Layer Security (TLS)
- EAP Flexible Authentication via Secure Tunneling (FAST)
- Protected EAP (PEAP)
- Cisco Lightweight Extensible Authentication Protocol (LEAP)
- EAP Tunneled TLS (EAP-TTLS)
- There are two port states in which the physical ports on the authenticator may be:
- Authorized
- Unauthorized
- There are two types of RADIUS server selections in Cisco ACS that are used for 802.1x:
- RADIUS (IETF)
- RADIUS (Cisco IOS/PIX 6.0)
- In addition to standard VLANs, 802.1x can use restricted and guest VLANs
- Guest VLANs typically have limited access to network resources
- Guest VLANs are used for clients that do not support or are not enabled for 802.1x
- Restricted VLANs can be used to provide limited network access to clients
- Restricted VLANs are used for 802.1x-enabled client that have failed authentication
- Restricted VLANs have the following restrictions:
- Restricted VLANs are only supported on static access ports, i.e. not on trunk ports, etc
- Restricted VLANs are compatible only when a switch is running in single-host mode
- Restricted VLANs cannot be used for Remote SPAN (RSPAN)
- Restricted VLANs cannot be used as voice VLANs, sometimes called auxiliary VLANs
IEEE 802.1x Attacks
- Two critical vulnerabilities that are present in EAPoL are:
- The injection of spoofed EAP-Success messages
- The ability of attackers to hijack the session
- The recommended method to mitigate EAPoL vulnerabilities is to use PEAP
- PEAP offers integrity by implementing the authentication sequence in two distinct parts:
- A TLS session is established between the supplicant and the PEAP authentication server
- EAP exchange is carried out over the TLS session to authenticate the supplicant
Other Cisco Catalyst Switch Security Features
- Other Cisco Catalyst switch features that can be used to enhance LAN security are:
- Storm Control
- Protected Ports
- Port Blocking
- Port ACLs
- VLAN ACLs
- MAC ACLs
- IP Source Guard
Commands Used in this Chapter
The following section is a summary of the commands used in this chapter:
| Command | Description |
| show mac-address-table | Used to view the switch CAM table |
| switchport port-security | Used to enable port security |
| switchport port-security mac-address | Use to configure static secure MACs |
| switchport port-security maximum | Used to specify the maximum number of secure MACs |
| switchport port-security violation | Used to specify switch action in the event of violations |
| show logging | Used to view the local logs |
| show port-security | Used to verify port security configuration and statistics |
| switchport port-security aging | Used to configure port security aging parameters |
| ip arp inspection vlan | Used to enable DAI for a VLAN or range of VLANs |
| ip arp inspection trust | Used to configure a DAI trusted interface |
| show ip arp inspection | Used to verify DAI configuration and statistics |
| arp access-list | Used to create a static IP-to-MAC binding |
| ip arp inspection filter | Used to configure DAI based on a static ARP entry |
| vtp password | Used to configure a VTP password |
| show vtp status | Used to verify VTP configuration |
| show interfaces [name] switchport | Used to view interface switch port parameters |
| switchport nonegotiate | Used to disable DTP on trunk links |
| switchport trunk encapsulation | Used to specify the trunk encapsulation protocol |
| switchport mode access | Used to specify an interface as a static access port |
| switchport access vlan | Used to assign an interface to a VLAN |
| vlan dot1q tag native | Used to tag the 802.1Q native VLAN frames |
| private-vlan primary | Used to configure the primary PVLAN |
| private-vlan [community|isolated] | Used to configure the secondary PVLAN |
| private-vlan association | Used to associate primary and secondary PVLANs |
| private-vlan mapping | Used to map secondary PVLANs to the SVI |
| switchport mode private-vlan | Used to configure PVLAN parameters on interfaces |
| spanning-tree portfast bpduguard default | Used to enable the BPDU Guard feature globally on the entire switch |
| spanning-tree bpduguard enable | Used to enable the BPDU Guard feature per interface |
| show spanning-tree summary | Used to verify STP configuration parameters |
| show spanning-tree interface | Used to verify STP interface configuration parameters |
| spanning-tree guard root | Used to enable the Root Guard feature per interface |
| show spanning-tree inconsistentports | Used to view inconsistent STP ports |
| ip dhcp snooping | Used to globally enable DHCP snooping |
| ip dhcp snooping vlan | Used to enable DHCP snooping for a VLAN |
| ip dhcp snooping trust | Used to configure trusted DHCP snooping interfaces |
| show ip dhcp snooping | Used to view DHCP snooping configuration parameters |
| show ip dhcp snooping binding | Used to view the DHCP snooping binding table |
| dot1x port-control | Used to enable 802.1x on a switch port or ports |
| dot1x guest-vlan | Used to enable guest VLANs for newer IOS versions |
| dot1x guest-vlan supplicant | Used to enable guest VLANs for IOS 12.2(25)SE |
| dot1x auth-fail max-attempts | Used to specify the number of authentication attempts |
| aaa new-model | Used to enable AAA |
| aaa authentication dot1x | Used to configure Authentication parameters for 802.1x |
| show dot1x interface | Used to view interface 802.1x configuration |
| show dot1x statistics interface | Used to view interface 802.1x statistics |
| storm-control | Used to configure storm control parameters |
| switchport protected | Used to enable the protected port feature |
| switchport block | Used to configure switch port blocking |
| mac access-list extended | Used to configure an extended MAC ACL |
| mac access-group | Used to apply a MAC ACL to an interface |
| show mac access-group | Used to view MAC ACLs applied to an interface |
| ip verify source | Used to enable the IP Source Guard feature |
| ip verify source port security | Used to enable IP Source Guard and Port Security |
| ip dhcp snooping information option | Used to allow the DHCP server to support option 82 |
| vlan access-map | Used to configure a VLAN access map |
| vlan filter map | Used to map a VLAN access map to a VLAN |
