miércoles, 12 de agosto de 2009

Module 8: Minimizing Service Loss and Data Theft in a Campus Network Parte3

8.3 Protecting Against Spoof Attacks


8.3.1 Describing a DHCP Spoof Attack

One of the ways an attacker can gain access to network traffic is to spoof responses that would be sent by a valid DHCP server. The DHCP spoofing device replies to client DHCP requests. The legitimate server may reply as well, but if the spoofing device is on the same segment as the client, its reply to the client may arrive first. The intruder’s DHCP reply offers an IP address and supporting information that designates the intruder as the default gateway or Domain Name System (DNS) server. In the case of a gateway, the clients forward packets to the attacking device, which in turn sends them to the desired destination. This is referred to as a “man-in-the-middle” attack, and it may go entirely undetected as the intruder intercepts the data flow through the network.

Figure describes the DHCP spoofing attack sequence.



8.3.2 Describing DHCP Snooping


DHCP snooping is a Cisco Catalyst feature that determines which switch ports can respond to DHCP requests. Ports are identified as trusted and untrusted. Trusted ports can source all DHCP messages, while untrusted ports can source requests only. Trusted ports host a DHCP server or can be an uplink toward the DHCP server. If a rogue device on an untrusted port attempts to send a DHCP response packet into the network, the port is shut down.

Untrusted ports are those not explicitly configured as trusted. A DHCP binding table is built for untrusted ports. Each entry contains the client MAC address, IP address, lease time, binding type, VLAN number, and port ID recorded as clients make DHCP requests. The table is then used to filter subsequent DHCP traffic. From a DHCP snooping perspective, untrusted access ports should not send any DHCP server responses, such as DHCPOFFER, DHCPACK, or DHCPNAK.

With the DHCP option-82 feature enabled on the switch, port-to-port DHCP broadcast isolation is achieved when the client ports are within a single VLAN. During client-to-server exchanges, broadcast requests from clients connected to VLAN access ports are intercepted by a relay agent running on the switch and are not flooded to other clients on the same VLAN. The relay agent inserts additional information inside the DHCP request packet, such as which port the request originated from, and then forwards it to the DHCP server. During server-to-client exchanges, the DHCP (option-82 aware) server sends a broadcast reply that contains the option-82 field. The relay agent uses this information to identify which port connects to the requesting client and avoids forwarding the reply to the entire VLAN.


8.3.3 Configuring DHCP Snooping


To enable DHCP snooping, use the commands in Figure . Figure describes the steps to configuring DHCP snooping.

Figure shows how to display the DHCP snooping configuration for a switch.

Only ports that are trusted or that have a rate limit applied are shown in the output. All other ports are untrusted and are not displayed.

IP source guard is a security feature that prevents IP source address spoofing. This feature is enabled on a DHCP snooping untrusted Layer 2 port. All IP traffic on the port is blocked, except for DHCP packets that are allowed by the DHCP snooping process. When a client receives a valid IP address from the DHCP server, a per-port VLAN Access Control List (PVACL) is installed on the port. This process restricts the client IP traffic to those source IP addresses configured in the binding. Any IP traffic with a source IP address other than that in the IP source binding is filtered out. This filtering limits a host’s ability to attack the network by claiming a neighbor host’s IP address.

Note:
If IP source guard is enabled on a trunk port with a large number of VLANs that have DHCP snooping enabled, you might run out of ACL hardware resources and some packets might be switched in software.

IP source guard supports only the Layer 2 ports, including both access and trunk. For each untrusted Layer 2 port, there are two levels of IP traffic security filtering, as follows:

Source IP address filter: IP traffic is filtered based on its source IP address. Only IP traffic with a source IP address that matches the IP source binding entry is permitted.

An IP source address filter is changed when a new IP source entry binding is created or deleted on the port. The port PVACL is recalculated and reapplied in the hardware to reflect the IP source binding change. By default, if the IP filter is enabled without any IP source binding on the port, a default PVACL that denies all IP traffic is installed on the port. Similarly, when the IP filter is disabled, any IP source filter PVACL is removed from the interface.

A static IP source binding may be configured on a port via the following global command:

Switch(config)#ip source binding ip-addr ip vlan number interface interface

Source IP and MAC address filter: IP traffic is filtered based on its source IP address as well as its MAC address. Only IP traffic with source IP and MAC addresses matching the IP source binding entry are permitted.

Figure describes IP source guard commands. Figure describes the procedure for enabling IP source guard.

Note:
The static IP source binding can only be configured on Layer 2 switch ports. If you issue the ip source binding vlan interface command on a Layer 3 port, you receive this error message: “Static IP source binding can only be configured on switch port.”


8.3.4 Describing ARP Spoofing


In normal ARP operation, a host sends a broadcast to determine the MAC address of a host with a particular IP address. The device at that IP address replies with its MAC address. The originating host caches the ARP response, using it to populate the destination Layer 2 header of packets sent to that IP address. By spoofing an ARP reply from a legitimate device with a gratuitous ARP, an attacking device appears to be the destination host sought by the senders. The ARP reply from the attacker causes the sender to store the MAC address of the attacking system in its ARP cache. All packets destined for those IP addresses are forwarded through the attacker system.

Figures and illustrate the sequence of events in an ARP spoofing attack.


8.3.5 Dynamic ARP Inspection


Dynamic ARP Inspection (DAI) determines the validity of an ARP packet based on the MAC address-to-IP address bindings stored in a DHCP snooping database. Additionally, DAI can validate ARP packets based on user-configurable ACLs for hosts that use statically configured IP addresses.

To prevent ARP spoofing or “poisoning,” a switch must ensure that only valid ARP requests and responses are relayed. To ensure that only valid ARP requests and responses are relayed, DAI takes the following actions:

  • Forwards ARP packets received on a trusted interface without any checks

  • Intercepts all ARP packets on untrusted ports

  • Verifies that each intercepted packet has a valid IP-to-MAC address binding before forwarding packets that can update the local ARP cache

  • Drops, logs, or drops and logs ARP packets with invalid IP-to-MAC address bindings

Generally, all access switch ports should be cofigured as untrusted and all switch ports connected to other switches as trusted. All ARP packets traversing the network from an upstream distribution or core switch could bypass the security check requiring no further validation.

You can also use DAI to set the rate limit of ARP packets and then err-disable the interface if the rate is exceeded.


8.3.6 Configuring Dynamic ARP Inspection


Figure lists the commands used to configure Dynamic ARP Inspection, and Figure describes the commands.

The following example shows how to configure DAI for hosts on VLAN 1, where client devices are located for switch 2. All client ports are untrusted by default. Only port 3/3 is trusted, because this is the only port where DHCP replies would be expected.

Switch S2(config)#ip arp inspection vlan 1
Switch S2(config)#interface fastethernet 3/3
Switch S2(config-if)#ip arp inspection trust

8.3.7 Protecting Against ARP Spoofing Attacks

To mitigate the chances of ARP spoofing, the following procedures are recommended:

Step 1 Implement protection against DHCP spoofing.

Step 2 Enable dynamic ARP inspection.



Module 8: Minimizing Service Loss and Data Theft in a Campus Network Parte2

8.2 Protecting Against VLAN Attacks
8.2.1 Explaining VLAN Hopping

VLAN hopping is a network attack whereby an end system sends packets to, or collects packets from, a VLAN that should not be accessible to that end system. This is accomplished by tagging the invasive traffic with a specific VLAN ID or by negotiating a trunk link to send or receive traffic on penetrated VLANs. VLAN hopping can be accomplished by switch spoofing or double tagging.


In a switch spoofing attack, the network attacker configures a system to spoof itself as a switch by performing Inter-Switch Link (ISL) or 802.1Q trunking, along with Dynamic Trunking Protocol (DTP) negotiations, to establish a trunk connection to the switch. Any switch port configured as DTP auto may become a trunk port when a DTP packet generated by the attacking device is received, and thereby accept traffic destined for any VLAN supported on that trunk. The malicious device can then send packets to, or collect packets from, any VLAN carried on the negotiated trunk.

Figure describes the switch spoofing sequence of events.

Another method of VLAN hopping is for a workstation to generate frames with two 802.1Q headers to get the switch to forward the frames onto a VLAN that would be inaccessible to the attacker through legitimate means.

If the double-tagged frame has a multicast, broadcast, or unknown destination, the switch that receives the frame floods this frame out all ports attached to the same VLAN (VLAN 10) as the attacker’s port native VLAN. The switch would strip the first VLAN tag before forwarding, provided this tag matched the native VLAN of the port it was received on. Any access port on this first switch assigned to VLAN 10 would receive the frame with the second VLAN tag. If a trunk port has the same native VLAN (VLAN 10), the switch would not re-tag the frame and it would arrive at the next switch with only the second VLAN tag. The second switch would then believe the frame originated from a different VLAN (VLAN 20) and thus flood it out to all ports active in this second VLAN. Also the second switch would forward the frame on any additional trunks that were active with the second VLAN.

If the trunk port on the first switch was assigned a different VLAN than the attacker’s port, the frame would simply be flooded to all active ports in VLAN 10 on both switches (no VLAN hopping). The reason is that the first switch would tag the 801.1Q frame with the attacker’s port VLAN prior to sending it across the trunk.

Figure describes the double-tagging method of VLAN hopping.


8.2.2 Mitigating VLAN Hopping

The measures to defend the network from VLAN hopping consist of a series of best practices for all switch ports and a set of parameters to follow when establishing a trunk port:

  • Configure all unused ports as access ports so that trunking cannot be negotiated across those links.

  • Place all unused ports in the shutdown state and associate with a VLAN designated only for unused ports, carrying no user data traffic.

  • When establishing a trunk link, configure the following:

    • Make the native VLAN different from any data VLANs

    • Set trunking as “on,” rather than negotiated

    • Specify the VLAN range to be carried on the trunk

Note:
The configuration commands in Figure do not work on access ports that support VoIP because they will be configured as trunk ports. However, on all other access ports, it is best practice to apply these commands to mitigate VLAN hopping.


8.2.3 VLAN Access Control Lists


Cisco multilayer switches support three types of ACLs:

  • Router access control list (RACL): Applied to Layer 3 interfaces such as SVI or L3 routed ports. It controls the access of routed traffic between VLANs. RACLs are applied on interfaces for specific directions (inbound or outbound). You can apply one access list in each direction. To improve performance in Cisco Catalyst multilayer switches, RACLs are supported in ternary content addressable memory (TCAM).

  • Port access control list (PACL): Applied on a Layer 2 switch port, trunk port, or EtherChannel port. PACLs perform access control on traffic entering a Layer 2 interface. With PACLs, you can filter IP traffic by using IP access lists and non-IP traffic by using MAC addresses. When you apply a PACL to a trunk port, it filters traffic on all VLANs present on the trunk port.

  • VLAN access control list (VACL): Supported in software on Cisco multilayer switches. Filtering based on Layer 2 or Layer 3 parameters within a VLAN. Unlike RACLs, VACLs are not defined by direction (input or output).

Catalyst switches support four ACL lookups per packet: input and output security ACL, and input and output Quality of Service (QoS) ACL.

Catalyst switches use two methods of performing a merge: order independent and order dependent. With order-independent merge, ACLs are transformed from a series of order-dependent actions to a set of order-independent masks and patterns. The resulting access control entry (ACE) can be very large. The merge is processor and memory intensive.

An order-dependent merge is a recent improvement on some Catalyst switches in which ACLs retain their order-dependent aspect. The computation is much faster and is less processor intensive.

RACLs are supported in hardware through IP standard ACLs and IP extended ACLs, with permit and deny actions. ACL processing is an intrinsic part of the packet forwarding process. ACL entries are programmed in hardware. Lookups occur in the pipeline whether ACLs are configured or not. With RACLs, access list statistics and logging are not supported.

8.2.4 Configuring VACLs


VACLs (also called VLAN access maps in Cisco IOS software) apply to all traffic on the VLAN. You can configure VACLs for IP and MAC-layer traffic.

VACLs follow route-map conventions in which map sequences are checked in order.

When a matching permit ACE is encountered, the switch takes the action. When a matching deny ACE is encountered, the switch checks the next ACL in the sequence or checks the next sequence.

Three VACL actions are permitted:

  • Permit (with capture, Catalyst 6500 only)

  • Redirect (Catalyst 6500 only)

  • Deny (with logging, Catalyst 6500 only)

Two features are supported only on the Cisco Catalyst 6500:

  • VACL capture: Forwarded packets are captured on capture ports. The capture option is only on permit ACEs. The capture port can be an IDS monitor port or any Ethernet port. The capture port must be in an output VLAN for Layer 3 switched traffic.

  • VACL redirect: Matching packets are redirected to specified ports. You can configure up to five redirect ports. Redirect ports must be in a VLAN where the VACL is applied.

The VACL capture option copies traffic to specified capture ports. VACL ACEs installed in hardware are merged with RACLs and other features.

Figure lists the commands used to configure VACLs. Figure describes the steps used to configure VACLs.

Figure shows a sample configuration.

The above configuration does not allow any host using a source IP address from 10.1.0.0 through 10.1.255.255 to send frames across this switch. If the switch receives a frame sourced from this range of IP addresses, they are dropped. It does not matter which VLAN the frame originates from or if the frame is destined for the same originating VLAN. Frames with any other source are allowed to forward.

Note:
You may also specify MAC address filtering within a VLAN using VACL configurations.



8.2.5 Private VLANs and Protected Ports


Internet service providers (ISPs) often have devices from multiple clients, as well as their own servers, on a single Demilitarized Zone (DMZ) segment or VLAN. As security issues proliferate, it becomes necessary to provide traffic isolation between devices, even though they may exist on the same Layer 3 segment and VLAN. Catalyst 6500/4500/3750/3560 switches implement private VLANs to keep some switch ports shared and some isolated, although all ports exist on the same VLAN. The 2960 supports “protected ports,” which is functionally similar to PVLANs on a per-switch basis.

The traditional solution to address these ISP requirements is to provide one VLAN per customer, with each VLAN having its own IP subnet. A Layer 3 device then provides interconnectivity between VLANs and Internet destinations.

These are the challenges with this traditional solution:

  • Supporting a separate VLAN per customer may require a high number of interfaces on service provider network devices.

  • Spanning tree becomes more complicated with many VLAN iterations.

  • Network address space must be divided into many subnets, which wastes space and increases management complexity.

  • Multiple ACL applications are required to maintain security on multiple VLANs, resulting in increased management complexity.

PVLANs and protected ports provide Layer 2 isolation between ports within the same VLAN. This isolation eliminates the need for a separate VLAN and IP subnet per customer.

A protected port does not forward any traffic (unicast, multicast, or broadcast) to any other port that is also a protected port. Traffic cannot be forwarded between protected ports at Layer 2; all traffic passing between protected ports must be forwarded through a Layer 3 device. The forwarding behavior between a protected port and a non-protected port is not affected and proceeds normally.

The example in Figure shows how to configure Fast Ethernet 0/1 interface as a protected port and verify the configuration.

PVLANs are supported on Catalyst 3560, 3750, 4500 and 6500 switches.

A port in a PVLAN can be one of three types:

  • Isolated: Has complete Layer 2 separation from other ports within the same PVLAN, except for the promiscuous port. PVLANs block all traffic to isolated ports, except the traffic from promiscuous ports. Traffic received from an isolated port is forwarded only to promiscuous ports.

  • Promiscuous: Communicates with all ports within the PVLAN, including the community and isolated ports. The default gateway for the segment would likely be hosted on a promiscuous port, given that all devices in the PVLAN need to communicate with that port.

  • Community: Communicate among themselves and with their promiscuous ports. These interfaces are isolated at Layer 2 from all other interfaces in other communities, or in isolated ports within their PVLAN.

Note:
Because trunks can support the VLANs carrying traffic between isolated, community, and promiscuous ports, isolated and community port traffic might enter or leave the switch through a trunk interface.

PVLAN ports are associated with a set of supporting VLANs that are used to create the PVLAN structure. A PVLAN uses VLANs in three ways:

  • As a primary VLAN: Carries traffic from promiscuous ports to isolated, community, and other promiscuous ports in the same primary VLAN.

  • As an isolated VLAN: Carries traffic from isolated ports to a promiscuous port.

  • As a community VLAN: Carries traffic between community ports and to promiscuous ports. You can configure multiple community VLANs in a PVLAN.

Isolated and community VLANs are called secondary VLANs. You can extend PVLANs across multiple devices by trunking the primary, isolated, and community VLANs to other devices that support PVLANs.

Note:
A promiscuous port can service only one primary VLAN. A promiscuous port can service one isolated or many community VLANs.

With a promiscuous port, you can connect a wide range of devices as access points to a PVLAN. For example, you can connect a promiscuous port to the server port to connect an isolated VLAN or a number of community VLANs to the server. A load balancer may be used to load-balance the servers present in the isolated or community VLANs, or you can use a promiscuous port to monitor or back up all the PVLAN servers from an administration workstation.


8.2.6 Configuring PVLANs


To configure a PVLAN on an IOS-based Catalyst 3560, 3750, 4500, or 6500, follow these steps:

Step 1 Set VTP mode to transparent.

Step 2 Create the secondary VLANs.

Note:
Isolated and community VLANs are secondary VLANs.

Step 3 Create the primary VLAN.

Step 4 Associate the secondary VLAN with the primary VLAN. Only one isolated VLAN can be mapped to a primary VLAN, but more than one community VLAN can be mapped to a primary VLAN.

Step 5 Configure an interface as an isolated or community port.

Step 6 Associate the isolated port or community port with the primary-secondary VLAN pair.

Step 7 Configure an interface as a promiscuous port.

Step 8 Map the promiscuous port to the primary-secondary VLAN pair.

Use these commands to configure a VLAN as a PVLAN:

Switch(config)#vlan vlan_ID
Switch(config-vlan)#[no] private-vlan {isolated | primary}

The following example shows how to configure VLAN202 as a primary VLAN and verify the configuration:

Switch#configure terminal
Switch(config)#vlan 202
Switch(config-vlan)#private-vlan primary
Switch(config-vlan)#end
Switch#show vlan private-vlan type

Primary Secondary Type Interfaces
------- --------- ----------------- ------------
202 primary

This example shows how to configure VLAN 200 as an isolated VLAN and verify the configuration:

Switch#configure terminal
Switch(config)#vlan 200
Switch(config-vlan)#private-vlan isolated
Switch(config-vlan)#end
Switch#show vlan private-vlan type

Primary Secondary Type Interfaces
------- --------- ----------------- ------------
202 primary
200 isolated

To associate secondary VLANs with a primary VLAN, perform this procedure:

Switch(config)#vlan primary_vlan_ID
Switch(config-vlan)#[no] private-vlan association {secondary_vlan_list | add secondary_vlan_list | remove secondary_vlan_list}

When you associate secondary VLANs with a primary VLAN, note the following:

  • The secondary_vlan_list parameter contains only one isolated VLAN ID.

  • Use the remove keyword with the secondary_vlan_list parameter to clear the association between the secondary and primary VLANs. The list can contain only one VLAN.

  • Use the no keyword to clear all associations with the primary VLAN.

  • The command does not take effect until you exit VLAN configuration mode.

To configure a Layer 2 interface as a PVLAN promiscuous port, perform this procedure:

Switch(config)#interface {fastethernet | gigabitethernet} slot/port
Switch(config-if)#switchport mode private-vlan {host | promiscuous}
Switch(config-if)#[no] switchport private-vlan mapping primary_vlan_ID {secondary_vlan_list | add secondary_vlan_list | remove secondary_vlan_list}

When you configure a Layer 2 interface as a PVLAN promiscuous port, note the following:

  • The secondary_vlan_list parameter cannot contain spaces. It can contain multiple comma-separated items. Each item can be a single PVLAN ID or a hyphenated range of PVLAN IDs.

  • Enter a secondary_vlan_list or use the add keyword with a secondary_vlan_list to map the secondary VLANs to the PVLAN promiscuous port.

  • Use the remove keyword with a secondary_vlan_list to clear the mapping between secondary VLANs and the PVLAN promiscuous port.

  • Use the no keyword to clear all mappings with the PVLAN promiscuous port.

This example shows how to configure interface FastEthernet 5/2 as a PVLAN promiscuous port, map it to a PVLAN, and verify the configuration:

Switch#configure terminal
Switch(config)#interface fastethernet 5/2
Switch(config-if)#switchport mode private-vlan promiscuous
Switch(config-if)#switchport private-vlan mapping 202 440
Switch(config-if)#end
Switch#show interfaces fastethernet 5/2 switchport
Name: Fa5/2
Switchport: Enabled
Administrative Mode: private-vlan promiscuous
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative private-vlan host-association: none ((Inactive))

Administrative private-vlan mapping: 202 (VLAN0202) 440 (VLAN0440)

Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled

To configure a Layer 2 interface as a PVLAN host port, perform this procedure:

Switch(config)#interface {fastethernet | gigabitethernet} slot/port
Switch(config-if)#switchport mode private-vlan {host | promiscuous}
Switch(config-if)#[no] switchport private-vlan host-association primary_vlan_ID secondary_vlan_ID

This example shows how to configure interface FastEthernet 5/1 as a PVLAN host port and verify the configuration:

Switch#configure terminal
Switch(config)#interface fastethernet 5/1
Switch(config-if)#switchport mode private-vlan host
Switch(config-if)#switchport private-vlan host-association 202 440
Switch(config-if)#end
Switch#show interfaces fastethernet 5/1 switchport
Name: Fa5/1
Switchport: Enabled

Administrative Mode: private-vlan host
Operational Mode: down
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: On
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)

Administrative private-vlan host-association: 202 (VLAN0202)
Administrative private-vlan mapping: none

Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled

To permit routing of secondary VLAN ingress traffic, perform this procedure:

Switch(config)#interface vlan primary_vlan_ID
Switch(config-if)#[no] private-vlan mapping primary_vlan_ID {secondary_vlan_list | add secondary_vlan_list | remove secondary_vlan_list}

When you permit routing on the secondary VLAN ingress traffic, note the following:

  • Enter a value for the secondary_vlan_list parameter or use the add keyword with the secondary_vlan_list parameter to map the secondary VLANs to the primary VLAN.

  • Use the remove keyword with the secondary_vlan_list parameter to clear the mapping between secondary VLANs and the primary VLAN.

  • Use the no keyword to clear all mappings with the PVLAN promiscuous port.

This example shows how to permit routing of secondary VLAN ingress traffic from PVLAN440 and verify the configuration:

Switch#configure terminal
Switch(config)#interface vlan 202
Switch(config-if)#private-vlan mapping add 440
Switch(config-if)#end
Switch#show interfaces private-vlan mapping
Interface Secondary VLAN Type
--------- --------- -----------------
vlan202 440 isolated




Module 8: Minimizing Service Loss and Data Theft in a Campus NetworkParte1

Module 8: Minimizing Service Loss and Data Theft in a Campus Network


Overview


This module defines the potential vulnerabilities related to VLANs within a network and possible solutions. Topics include port security for mitigation of MAC spoofing and flooding, using PVLANs and VACLs to control VLAN traffic, VLAN hopping, DHCP spoofing, ARP spoofing, and STP attacks. You learn about many potential problems and solutions; in particular, you learn how to secure switch access using vty ACLs and implementing SSH.


8.1.1 Overview of Switch Security Concerns

A lot of industry attention dwells on security attacks from outside the walls of an organization and at the upper Open Systems Interconnection (OSI) layers. Network security often focuses on edge-routing devices and on filtering packets based on Layer 3 and 4 headers, ports, and stateful packet inspection. This includes all issues surrounding Layer 3 and above as traffic makes its way into the campus network from the Internet. Generally, most security discussions do not consider campus access devices and Layer 2 communication.

The default state of networking equipment highlights this focus on external protection and internal open communication. Firewalls are placed at the organizational borders and default to a secure operational mode, allowing no communication until configured to do so. The default operational mode for routers and switches placed internal to an organization is to accommodate communication and forward all traffic, which often results in minimal security configuration and renders them targets for malicious attacks. If an attack is launched at Layer 2 on an internal campus device, the rest of the network can be quickly compromised, often without detection.

Many security features are available for switches and routers, but they must be enabled to be effective. As with Layer 3, where security had to be tightened on devices within the campus as malicious activity increased, security measures must now be taken to guard against malicious activity at Layer 2. A new security focus centers on attacks launched by maliciously leveraging normal Layer 2 switch operations. Security features exist to protect switches and Layer 2 operations but, as with access control lists (ACLs) for upper-layer security, a policy must be established and appropriate features configured to protect against potential malicious acts while maintaining daily network operations.


8.1.2 Describing Unauthorized Access by Rogue Devices

Rogue access comes in several forms. For example, because unauthorized rogue access points are inexpensive and readily available, employees sometimes plug them into existing LANs and build ad hoc wireless networks without IT department knowledge or consent. These rogue access points can be a serious breach of network security because they can be plugged into a network port behind the corporate firewall. Employees generally do not enable any security settings on the rogue access point, so it is easy for unauthorized users to use the access point to intercept network traffic and hijack client sessions.

Malicious rogue access points, while much less common than employee-installed ones, present an even greater risk and challenge because they are intentionally hidden from physical and network view. These rogue access points create an unsecured wireless LAN connection that puts the entire wired network at risk.

Another security threat is rogue Layer 2 switches. An attacker with physical access to data cabling attaches a rogue switch that can be used to manipulate Spanning Tree Protocol (STP), hop VLANs, sniff traffic, and so on. This rogue switch can be a workstation with the ability to trunk and participate in other Layer 2 operations.

To mitigate STP manipulation, use the root guard and BPDU guard enhancement commands to enforce the placement of the root bridge in the network and the STP domain borders. The STP BPDU guard allows network designers to keep the active network topology predictable. While BPDU guard may seem unnecessary given that the administrator can set the bridge priority to zero, there is still no guarantee that the bridge will be elected as the root bridge because there might be another bridge with priority zero and a lower bridge ID. BPDU guard is best deployed toward user-facing ports to prevent rogue switch network extensions by an attacker.


8.1.3 Switch Attack Categories

Layer 2 malicious attacks are typically launched by a device connected to the campus network. This can be a physical rogue device placed on the network or an external intrusion that takes control of and launches attacks from a trusted device. In either case, the network sees all traffic as originating from a legitimate connected device.

The following lists the types of attacks launched against switches and Layer 2:

  • MAC layer attacks

  • VLAN attacks

  • Spoof attacks

  • Switch device attacks

Figure describes attack methods and mitigation steps.



8.1.4 Describing a MAC Flooding Attack



A common Layer 2 or switch attack is MAC flooding, which causes a switch’s CAM table to overflow, resulting in flooding regular data frames out all switch ports. This attack can be launched to collect a broad sample of traffic or as a denial of service (DoS) attack.

A switch’s CAM tables are limited and, therefore, can contain only a limited number of entries at any one time. A network intruder can maliciously flood a switch with a large number of frames from a range of invalid source MAC addresses. If enough new entries are made before old ones expire, new valid entries are not accepted. Then, when traffic arrives at the switch for a legitimate device that is located on one of the switch ports that was not able to create a CAM table entry, the switch must flood frames to that address out all ports. This has two adverse effects:

  • Switch traffic forwarding is inefficient and voluminous.

  • An intruding device can be connected to any switch port and capture traffic not normally seen on that port.

If the attack is launched before the beginning of the day, the CAM table in the switches would be full. As the majority of legitimate end devices are powered up, their source MAC addresses would not be entered into the CAM tables. If this represents a large number of network devices, the number of MAC addresses for which traffic will be flooded is high, and switch ports will carry flooded frames from a large number of devices.

If the initial flood of invalid CAM table entries is a one-time event, the switch eventually ages out older, invalid CAM table entries, allowing new, legitimate devices to create an entry. Traffic flooding will cease and may never be detected, while the intruder captured a significant amount of data from the network.

Figure shows the progression of a MAC flooding attack.

To mitigate against MAC flooding, port security is configured to define the number of MAC addresses that are allowed on a given port. Port security can also specify which MAC address is allowed on a given port.



8.1.5 Describing Port Security

Cisco Catalyst switches include port security as a feature. Port security restricts a switch port to a specific set or number of MAC addresses. Those addresses can be learned dynamically or configured statically. The port then provides access only to frames from those addresses. If, however, the number of addresses is limited to four but no specific MAC addresses are configured, the port allows any four MAC addresses to be learned dynamically, and port access is then limited to those four dynamically learned addresses.

A port security feature called “sticky learning,” which is available on some switch platforms, combines the features of dynamically learned and statically configured addresses. When this feature is configured on an interface, the interface converts dynamically learned addresses to “sticky secure” addresses. The addresses are added to the running configuration as if they were configured using the switchport port-security mac-address command.

Scenario

Imagine five individuals whose laptops are allowed to connect to a specific switch port when they visit an area of the building. We want to restrict switch port access to the MAC addresses of those five laptops and allow no addresses to be learned dynamically on that port.

Figure describes the process for achieving this.

Note:
Port security cannot be applied to trunk ports where addresses might change frequently. Implementations of port security vary by Cisco Catalyst platform. Check your documentation to see if and how your particular hardware supports this feature.

8.1.6 Configuring Port Security on a Switch

Figure describes what is involved in configuring port security to limit switch port access to a finite, specific set of end-device MAC addresses.

Figure lists the configuration steps. You should be aware of the following things:

Step 1 Port security is enabled on a port-by-port basis.

Step 2 By default, only one MAC address is allowed access through a given switch port when port security is enabled. This parameter increases that number. It places no restriction on specific MAC addresses, just on the total number of addresses that can be learned by the port. Learned addresses are not aged out by default, but can be configured to do so after a specified time using the switchport port-security aging command. The value parameter can be any number from 1 to 1024, with some restrictions regarding the number of ports on a given switch with port security enabled.

Note:
Be sure to set the value parameter to a value of 2 when you are configuring a port to support VoIP and requires a phone and computer accessible on the port. If the default value is used, a port security violation occurs.

Step 3 Access to the switch port can be restricted to one or more specific MAC addresses. If the number of MAC addresses assigned is lower than the value parameter set in Step 2, the remaining allowed addresses can be learned dynamically. If you specify a set of MAC addresses that is equal to the maximum number allowed, access is limited to that set of MAC addresses.

Step 4 By default, if the maximum number of connections is achieved and a new MAC address attempts to access the port, the switch must take one of the following actions:

  • Protect: Frames from the non-allowed address are dropped, but there is no log of the violation.

Note:
The protect argument is platform or version dependent.
  • Restrict: Frames from the non-allowed address are dropped, a log message is created, and a Simple Network Management Protocol (SNMP) trap is sent.

  • Shut down: If any frames are seen from a non-allowed address, the interface is errdisabled, a log entry is made, an SNMP trap is sent, and manual intervention or errdisable recovery must be used to make the interface usable.

Use show commands to verify the port security configuration.

The show port-security command lists the ports on which port security has been enabled. It also displays count information and security actions to be taken per interface.

The full command syntax is as follows:

Switch#show port-security [interface interface_id] address

You can view port security status by interface or by the addresses associated with port security on all interfaces.

Figure displays output from the show port-security command when you do not enter an interface. Use the interface keyword to provide output for a specific interface.

Figure displays output from the show port-security command for a specified interface.

Use the address keyword to display MAC address table security information. Figure displays output from the show port-security address privileged EXEC command. The Remaining Age column is populated only if specifically configured for a given interface.


8.1.7 Port Security with Sticky MAC Addresses

Port security can be used to mitigate spoof attacks by limiting access through each switch port to a single MAC address. This prevents intruders from using multiple MAC addresses over a short period of time but does not limit port access to a specific MAC address. The most restrictive port security implementation would specify the exact MAC address of the single device that is to gain access through each port. Implementing this level of security, however, requires considerable administrative overhead.

Port security has a feature called “sticky MAC addresses” that can limit switch port access to a single, specific MAC address without the network administrator having to determine the MAC address of every legitimate device and manually associate it with a particular switch port.

When sticky MAC addresses are used, the switch port converts dynamically learned MAC addresses to sticky MAC addresses, and adds them to the running configuration as if they were static entries for a single MAC address allowed by port security. Sticky secure MAC addresses are added to the running configuration but do not become part of the startup configuration file, unless the running configuration is copied to the startup configuration after addresses have been learned. If they are saved in the startup configuration, they do not have to be relearned when the switch is rebooted, which provides a higher level of network security.

The following command converts all dynamic port security–learned MAC addresses to sticky secure MAC addresses:

switchport port-security mac-address sticky

This command cannot be used on ports where voice VLANs are configured.



8.1.8 Authentication, Authorization, and Accounting


Authentication, authorization, and accounting (AAA) network security services provide the primary framework through which access control is set up on a switch. AAA is an architectural framework for configuring a set of three independent security functions in a consistent manner. AAA provides a modular way of performing these services. For purposes of this course, only authentication is discussed.

Authentication is the way a user is identified before being allowed access to the network and network services. AAA authentication is configured by defining a list of named authentication methods and then applying that list to various interfaces. The method list defines the types of authentication to be performed and in which sequence they are performed. The method list must be applied to a specific interface before any of the defined authentication methods are performed. If there is no defined method list, the default method list (named “default”) is applied. A defined method list overrides the default method list.

In many circumstances, AAA uses protocols such as RADIUS, TACACS+, or 802.1x to administer security functions. If the switch is acting as a network access server, AAA is the means through which a switch establishes communication between the network access server and the RADIUS, TACACS+, or 802.1x security server.


8.1.9 Authentication Methods

The AAA security services facilitate a variety of login authentication methods.

The list-name argument is the name of the list being created. The method argument refers to the actual method the authentication algorithm tries. Additional authentication methods are used only if the previous method returns an error, not if it fails.

For example, to specify RADIUS as the default method for user authentication during login, enter the following command:

aaa authentication dot1x default group radius

Figure describes the basic process for configuring AAA.


8.1.10 802.1x Port-Based Authentication

The IEEE 802.1x standard defines a port-based access control and authentication protocol that restricts unauthorized workstations from connecting to a LAN through publicly accessible switch ports. The authentication server authenticates each workstation connected to a switch port before making available any services offered by the switch or the LAN.

Until the workstation is authenticated, 802.1x access control allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to which the workstation is connected. After authentication succeeds, normal traffic can pass through the port.

With 802.1x port-based authentication, the devices in the network have the following specific roles:

  • Client: The device (workstation) that requests access to the LAN and switch services, and responds to requests from the switch. The workstation must be running 802.1x-compliant client software, such as what is offered in the Microsoft Windows XP and Vista operating systems. (The port that the client is attached to is the supplicant [client] in the IEEE 802.1x specification.)

  • Authentication server: Performs the actual authentication of the client. The authentication server validates the identity of the client and notifies the switch whether or not the client is authorized to access the LAN and switch services. Because the switch acts as the proxy, the authentication service is transparent to the client. The RADIUS security system with EAP extensions is the only supported authentication server.

  • Switch (also called the authenticator): Controls physical access to the network based on the authentication status of the client. The switch acts as an intermediary (proxy) between the client (supplicant) and the authentication server, requesting identifying information from the client, verifying that information with the authentication server, and relaying a response to the client. The switch uses a RADIUS software agent, which is responsible for encapsulating and decapsulating the EAP frames and interacting with the authentication server.

The switch port state determines whether the client is granted access to the network. The port starts in the unauthorized state. While in this state, the port disallows all ingress and egress traffic, except for 802.1x protocol packets. When a client is successfully authenticated, the port transitions to the authorized state, allowing all traffic for the client to flow normally.

If the switch requests the client identity (authenticator initiation) and the client does not support 802.1x, the port remains in the unauthorized state, and the client is not granted access to the network.

In contrast, when an 802.1x-enabled client connects to a port and the client initiates the authentication process (supplicant initiation) by sending the EAPOL-start frame to a switch not running the 802.1x protocol, no response is received, and the client begins sending frames as if the port is in the authorized state.

You control the port authorization state by using the dot1x port-control interface configuration command and these keywords:

  • force-authorized: Disables 802.1x port-based authentication 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.

  • force-unauthorized: 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.

  • auto: Enables 802.1x port-based 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 (authenticator initiation) or when an EAPOL-start frame is received (supplicant initiation). The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. The switch uniquely identifies each client attempting to access the network with the client MAC address.

If the client is successfully authenticated (receives an “accept” frame from the authentication server), the port state changes to authorized, and all frames from the authenticated client are allowed through the port. If the authentication fails, the port remains in the unauthorized state, but authentication can be retried. If the authentication server cannot be reached, the switch can retransmit the request. If no response is received from the server after the specified number of attempts, authentication fails and network access is not granted.

When a client logs off, it sends an EAPOL-logoff message, causing the switch port to transition to the unauthorized state.

The commands for configuring 802.1x are illustrated in Figure .

To implement 802.1x port-based authentication, follow the steps in Figure .

In Figure , the example shows how to enable AAA and 802.1x on Fast Ethernet port 5/1.