Network perimeter security has long been the focus for security products and defenses such as firewalls and layer 3 attacks. The SWITCH exam covers several different security topics in depth, but all from a layer 2 perspective. These kind of attacks are usually launched from within a network either from legitimate or rogue devices (ex. consumer wireless access points, access switches, and hubs).
A rogue switch added to the access layer could disrupt the Spanning Tree root bridge topology and even worse, could create a loop and bring an entire segment down.
MAC Address Attacks
The primary MAC address attack attempts to overwhelm the CAM table. Another layer 2 MAC attack is MAC spoofing which allow an attacking device to recieve frames intended for a different network host. Precautions include port security and port-based authentication.
MAC Flooding
In a MAC flooding attack, an attacker floods a target switch with invalid source MAC addresses which quickly fill the CAM table. Once the table is full, any frames whose MAC is not in the table are flooded out all ports causing everyone (including the attacker) to begin to see traffic on their port they would normally not. After the attack stops, the CAM table entries eventually age out so things will return to normal, but in the mean time the attack may have collected valuable information. Two preventative techniques for MAC flooding attacks are port security and implementing VLAN access maps – with port security being the most common solution.
Port Security
Port security can put limits on both what MAC addresses are allowed to be connected to a switch port and how many at any given time. Using port security specific MACs can be statically allowed, or dynamically “learned” using the sticky command.
If you simply enable port security on an interface, it will only allow a single MAC address to connect by default. You should specify the maximum number of MAC addresses that should connect to the port using the switchport port-security maximum command. If you then choose to statically assign MAC addresses to that interface, only those will be allowed plus however remaining until you reach the maximum MAC allowed. For example, lets say you configure port security on and interface, configure it for a max of 2 MAC addresses, then statically configure a single MAC address with the switchport port-security mac-address command. If you try to add another device to the port it wil be accepted because you allowed two MACs with the switchport port-security maximum number command.
Note: Port security can only be applied to access ports (including VoIP interfaces), but not trunks!
Configuring Port Security
Switch# conf t
Switch(config)# interface fa 1/1
To enable port security on the interface
Switch(config-int)# switchport port-security
Specify the maximum number of MACs allowed (default is one)
Switch(config-int)# switchport port-security maximum number
Specify the violation action when requirements defined are not met or exceeded. Shutdown puts int interface in err-disable state and sends an SNMP trap, Restrict will drop violator’s frames, log it and send an SNMP trap, and Protect will drop frames quietly from MACs not specified. Shutdown is the default action.
Switch(config-int)# switchport port-security violation {shutdown | restrict | protect}
Statically assign MAC addresses (optional)
Switch(config-int)# switchport port-security mac-address MAC address
Set the aging time for each assigned MAC
Switch(config-int)# switchport port-security aging time [0-1440 (minutes)]
* Use this feature to remove and add PCs on a secure port without manually deleting the existing secure MAC addresses while still limiting the number of secure addresses on a port. If the aging time is set to 0, aging is disabled.
Allows the switch to dynamically learn up to the maximum number of MAC addresses (optional)
Switch(config-int)# switchport port-security mac-address sticky
You can configure an interface to convert the dynamic MAC address to sticky secure MAC addresses and to add them to the running configuration by enabling sticky port security. The sticky secure MAC addresses do not automatically become part of the start up configuration. If, however, you save the running configuration to the start up configuration, then reboot the switch, the MACs will be saved upon reboot.
To verify the port security settings:
Switch# show port-security [interface | address]
** You cannot configure static or sticky MAC addresses using port security on a voice VLAN port.
Port security and VoIP
Port security can be applied to interfaces that use voice VLANs as well. Because voice VLANs typically also include data traffic from a connected PC and an internal switch in the phone, Cisco recommends setting the maximum number of allowed MAC addresses to 3 when using port security in conjunction with voice VLANs.
VLAN Attacks
The major security concern related to VLANs is a concept commonly known as “VLAN hopping”. VLAN hopping attacks involve an attacker sending and/or receiving traffic from a VLAN to which they are not assigned. There are two ways this can be done, switch spoofing and double-tagging – both done by manipulating the way switches create and pass data through trunk links.
Switch Spoofing
Switch spoofing uses a computer to mimic a trunk tunnel with a directly connected switch using Dynamic Trunking Protocol (DTP). DTP is enabled by default on Cisco switches and trunk ports also pass all traffic across trunks by default. If an attacker is able to trick the switch into establishing a trunk port, they are able to access (and inject) all traffic going through the switch.
802.1Q Double-Tagging
A double-tagging attack is possible because 802.1Q does not tag frames sent using the native VLAN. In this attack, the attacker sends a payload with two VLAN tags, the first assigned to the segment’s native VLAN and the second assigned to the target destination’s VLAN. The first switch to receive the attacker’s packet strips off the native VLAN tag and forwards it out all ports (including adjacent trunk ports) because that is how 802.1Q handles native VLAN traffic. Once the next hop switch receives the packet, it sees only the second tag and forwards it on to the target destination.
To Mitigate Switch Spoofing:
- Disable DTP on all ports using theswitchport nonegotiate command on each port.
- Define access ports and trunk ports explicitly using commands like switchport mode access and switchport mode trunk.
- Shutdown all unused ports and assign them all to an unused VLAN (ex. something like 999)
- Define the native VLAN separate from any data VLANs
- Define explicit VLANs allowed on the trunk links, rather than the default allow all
VACLs
There are three types of access control lists (ACLs) that Cisco switches support:
- Traditional Router ACL (RACL)
- QoS ACL
- VACL (also referred to VLAN access-maps)
VACLs are much like route-maps in that they use match and set statements to define what actions are taken. In this case, the set statements are “action” directives, which include forward, drop, and redirect. Also like route-maps, VACL statements are ordered.
Below is an example configuration:
Switch(config)# access-list 10 permit ip 10.1.1.0 0.0.0.255 any
Switch(config)#mac access-list extended SERVER
Switch(config-ext-mac)# permit any host ooo0.1111.2222
Switch(config)# vlan access-map TEST 1
Switch(config-map)# match ip address 10
Switch(config-map)# action drop
Switch(config-map)# vlan access-map TEST 2
Switch(config-map)# match mac address SERVER
Switch(config-map)# action drop
Switch(config-map)# vlan access-map TEST 3
Switch(config-map)#action forward
Switch(config)# vlan filter TEST vlan-list 14,17
Note that even when using the “action forward” statement, traffic that is not explicitly defined within the access list will be dropped because of the implicit deny feature at the end of the list. Also, it is important to remember for this exam that both routed and bridged ACLs can be applied as either inbound or outbound and that VLAN maps and router ACLs can be used in combination.
Spoof attacks include DHCP, MAC, and ARP spoofing – all of which I’ll briefly discuss.
DHCP Spoofing
DHCP spoofing attacks occur when an attacker responds to DHCP requests, listing themselves as the default gateway or DNS server. This positions them to intercept all traffic before forwarding it on to the real network gateway. The attacker could also simply flood the DHCP server with requests, filling up the available IP space (DoS attack).
One option for preventing DHCP spoofing attacks is to statically assign ARP entries into the DHCP server so that dynamically created ARP packets cannot interfere. A more manageable solution is to use DHCP snooping. DHCP snooping protects to against DHCP spoofing attacks and is a security feature that when enabled, only ports that uplink to an authorized DHCP server are trusted and allowed to pass all DCHP traffic. All other ports are untrusted (default) and can only send DHCP requests. If a DCHP response (“offer”) is heard on an untrusted interface, it is shutdown.
**DHCP snooping must be first configured globally, then on specific VLANs, and finally in any interfaces. Remember to configure only ports that connect directly to or uplink to a DHCP server as trusted.
DHCP Snooping Configuration
Globally:
Switch(config)# ip dhcp snooping
On VLAN(s):
Switch(config)# ip dhcp snooping vlan number number
On interfaces:
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# ip dhcp snooping limit pkts/sec (limits DoS attacks)
Verification:
Switch# show ip dhcp snooping
IP Source Guard
If more protection is required, IP Source Guard can be applied to access ports. IP Source Guard keeps track of the host’s IP address and/or MAC address associated with each port – usually in conjunction with DHCP snooping enabled. If traffic sourced from another address enters that interface, it is dropped.
To Configure IP Source Guard
Switch(config-if)# ip verify source (uses just IP address filtering)
Switch(config-if)# ip verify source port-security (uses IP + MAC filtering)
Switch# show ip source binding
ARP Spoofing
ARP spoofing is another man-in-the-middle attack exploiting the ARP protocol. An attacker sends out an unsolicited ARP message giving the IP address of the local gateway with it’s own MAC address. Local machines then overwrite their ARP tables and all traffic is forwarded through the attacker.
Dynamic ARP Inspection (DAI) is a security mechanism that works with DHCP snooping to define trusted and untrusted interfaces. DAI intercepts, logs, and drops ARP messages on untrusted ports that do not match the DHCP snooping MAC/IP bindings. All traffic that matches is passed, all traffic that does not match is dropped.
DIA is supported on access ports, trunk ports, EtherChannels, and private VLAN interfaces. Dynamic ARP Inspection should be only applied to ingress interfaces. All access ports should be untrusted and all trunks (including connections to routers) should be configured as trusted. Enable DAI on one or more VLANs, then configure the trusted interfaces. It matches IP and MAC by default.
Basic DAI configuration commands
Switch(config)# ip arp inspection vlan vlan-id
Switch(conf-if)# ip arp inspection trust
General Switch Security Recommendations
- Use strong passwords that are not susceptible to a dictionary attack (preferably using numbers and/or symbols)
- Limit Telnet access using ACLs
- Use SSH instead of Telnet
- Physically secure the switch
- Use banners that warn intruders against unauthorized access
- Remove unused services (ex. finger, TCP and UDP small servers, service config, and HTTP server)
- Configure a Syslog
- Disable DTP (Dynamic Trunking Protocol) – define trunks explicitly
- Disable CDP when it is not required
- no cdp run (disables it globally on the switch)
Port-Based Authentication
802.1x is a security protocol designed to authenticate devices like computers to access ports on a switch. When a device connects to a 802.1x enabled port, it goes through the following steps:
- It begins in the unauthorized state – only allowing EAP over LAN (EAPOL), CDP, and STP communication.
- The switch requests authentication or the client sends an EAPOL frame to begin authentication.
- The switch forwards the client’s authentication information to a RADIUS server and acts as a proxy.
- If authentication is successful, the port transitions to authorized state and traffic is permitted.
802.1x requires three different devices be configured for port-based authentication to work properly:
- Client (or host) – must be running 802.1x compliant system software
- Authentication server – Performs the actual authentication of the clients
** Radius is the only supported server type! - Switch (or authenticator) – controls physical access and acts as a proxy
To enable port-based authentication using 802.1x:
Switch(config)# aaa new-model (enables AAA globally, with default lists applied to the VTYs)
Switch(config)# aaa authentication dot1x default group radius
Switch(config)# dot1x system-auth-control (globally enables 802.1x on switch)
To enable 802.1x on an individual interface
Switch(config-if)# dot1x port-control [auto | forced-authorize | force-unauthorized]
Note: The auto is the default dot1x port-control mode, but you should be aware of the “forced-authorized” option. When applied to an interface, it forces the port to transition directly into an authorized state and disable 802.1x authentication. This can be applied to interfaces that you inherently trust are secure or more likely do not support any type of 802.1x exchange.
Switch# show dot1x





Pingback: CCNP SWITCH 642-813 :: Security Topics « Chomp The Bit
December 21, 2011 9:01 am
Cisco Catalyst 2950 Configuration Guide says: dot1x port-control default setting is force-authorized, not auto, as you wrote.
“You control the port authorization state by using the dot1x port-control interface configuration command and these keywords:
•force-authorized—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 the default setting.”