Miscellaneous Switch Security Features

Following is a high-level discussion of some additional switch security features that can be used by themselves or in conjunction with the mitigation techniques
previously examined

Intrusion Notification

In some situations, you might want to configure the switch to send a notification to an SNMP NMS when MAC addresses are learned by the system or deleted from the CAM table. An example of where this might be used could be a switch that is deployed in a particularly restrictive security zone in the network, like an R&D lab or a DMZ, and where you want to determine if there is anomalous MAC address learning behavior in that part of the network. The following command enables this feature:
Catalyst1(config)#mac-address-table notification Only dynamic and secure MAC addresses generate a MAC address notification. Traps are not sent for self, multicast, or other static addresses.

NOTE
Use the mac-address-table notification command with caution. It can generate a lot of traffic to the NMS. You might consider changing the interval at which alerts are sent to the NMS by using the following format of the command: Catalyst1(config)#mac-address-table notification interval 120 In this example, the interval at which events are trapped to the NMS server has been set to 120 seconds.

Switched Port Analyzer (SPAN)

Chapter 8, “Network Security Using Cisco IOS IPS,” discusses how an IDS should be deployed in the network in such a way that it will see all the traffic in a particular part of the network. If it doesn’t see all the traffic, its effectiveness as an IDS is questionable at best. Referring to Figure 10.2, if an organization’s perimeter router is connected to an ISP router via a switch, an IDS deployed on a single switch port would normally see only flooded traffic, namely unknown unicasts, broadcasts, and multicasts. It would not see the majority of ingress and egress traffic in and out of the organization’s network, rendering it ineffective.

A way must be found to replicate the traffic that hits the GigE 0/1 interface to the GigE 0/2 interface where the IDS resides. This is the idea behind SPAN. The destination port (GigE 0/2, in our example) is dedicated to monitor the activity on another port or VLAN. SPAN can copy traffic sent or received. The port dedicated for SPAN use does not receive or forward any other traffic than that which is required for SPAN use. This type of port monitoring is often called port mirroring. SPAN does not affect switch operation.

The following are the commands to create a monitoring session, number 1, which mirrors traffic from gigabitEthernet 0/1 to gigabitEthernet 0/2. The encapsulation replicate part of the second command preserves the encapsulation method of the monitored port. For example, if the mirrored port is an IEEE 802.1Q trunk, the port that the frames are replicated to will see copies of tagged VLAN traffic and native VLAN traffic.

Catalyst1(config)# monitor session 1 source interface gigabitEthernet0/1
Catalyst1(config)# monitor session 1 destination interface
gigabitEthernet0/2 encapsulation replicate

Storm Control

Broadcast storms are not just a product of topological loops. If they were, then spanning tree would be the sole requirement for mitigating broadcast storms.
Broadcast storms can also result from the following:

DoS attacks
Poorly-designed, chatty applications
Protocols that rely heavily on broadcasts (for example, NetBIOS, AppleTalk, and Novell)

Storm control is essentially a method of traffic suppression. A threshold is set for the number of incoming broadcast, multicast, and unicast frames that are allowed on each port. Frames are counted in a one-second interval, and the switch blocks broadcasts that rise above that threshold within that interval. Control frames such as BPDUs are exempt, but other, necessary traffic, such as frames that carry routing protocol packets, may be discarded. It is good practice to understand the type and disposition of protocol traffic that may arrive on a specific switch interface before setting these thresholds; weighing the likelihood of attack on that port against the criticality of traffic that needs to flow for normal operation.

EXAM ALERT
Remember that storm control is configured on an interface and not globally.

In the end, storm control only treats the symptoms and not the cause of broadcasts if the problem is simply poor design. A network should be designed to limit the amount of broadcast and multicast traffic. To enable storm control, use the following interface configuration command: Catalyst1(config-if)#storm-control You can then specify a traffic suppression level for the type of traffic in a variety of different ways:

Percentage (up to two decimal places of accuracy) of total bandwidth on the port
Rate in packets per second (pps)
Rate in bits per second

To verify the storm control that has been configured on a particular interface, you might choose to use the following command:

Catalyst1(config-if)#do show running-config interface GigabitEthernet0/1
Building configuration...
Current configuration : 271 bytes
!
interface GigabitEthernet0/1
storm-control broadcast level 62.50
storm-control multicast level pps 3k 2k
storm-control unicast level bps 50m 25m
storm-control action shutdown
end

In the previous CLI example

Broadcast traffic is limited to no more than 62.5% of total bandwidth on the port, and traffic exceeding this threshold is blocked until it falls back to 62.5% (see the following note).
Multicast traffic is limited to no more than 3,000 packets per second on a rising threshold and continues to be blocked until the number of multicast packets per second drops to the falling threshold of 2,000.
Unicast traffic is limited to no more than 50 Mbps on a rising threshold and continues to be blocked until the falling threshold of 25 Mbps is reached.
The port is shut down if any of these thresholds is exceeded.

NOTE
If you define the threshold in pps or bps (as in this example of the storm-control command), you can use k, m, or g to specify thousand, millions, and billions of packets per second or bits per second respectively. If a falling threshold is not specified (2k pps for multicasts and 25m bps for unicasts in this example), the traffic will be blocked until the traffic falls below the rising threshold. For the action in the storm-control command, you can also specify the option trap, which sends an SNMP alert to the NMS when a storm occurs.

Switch Security Best Practices

Cisco makes the following recommendations for switch security best practices:

Secure management: Think security for switch management. Use SSH, a dedicated management VLAN, OOB, and so on as much as possible.
Native VLAN: Always use a dedicated VLAN ID for trunk ports and avoid using VLAN 1 at all.
User ports: Non-trunking. (Cisco VoIP phones being the exception. See Chapter 9, “Introduction to Endpoint, SAN, and Voice Security.”)
Port security: Use for access ports whenever possible.
SNMP: Limit to the management VLAN if possible and treat community strings like superuser passwords. (See Chapter 4, “Implementing Secure Management and Hardening the Router,” for more information.)
STP attacks: Use BPDU guard and root guard.
CDP: Only use if necessary. CDP should be left on for switch ports connected to VoIP phones. An attacker can learn much from CDP advertisements.
Unused ports: Disable and put them in an unused VLAN for extra security.

CCNA Security Study Notes