STP SECURITY FEATURES IN SWITCHES

Date: 3-3-2014

 

Enable ENHANCED STP features (for example, BPDU Guard, Loopguard, and Root Guard) are Layer 2 Security Best Practices.

Table of Contents

• BPDU Guard

• Root Guard

• Loop Guard

• Etherchannel Guard

STP attacks Mitigation techniques

Attacking device spoofs the root bridge in the STP topology. If successful, the network attacker can see a variety of frames.

The Spanning Tree Protocol (STP) Man in The Middle (MiTM) attack compromises the STP "Root Bridge" election process and allows a hacker to use their PC to masquerade as a "Root Bridge," thus controlling the flow of L2 traffic.

STP MiTM attack, and other attacks, can be thwarted on a Cisco Catalyst device by using either the "BPDU Guard" Feature or the "Root Guard" Feature. These enhanced features of STP are the two best methods for thwarting STP MiTM attack, in which a rogue workstation starts generating superior Configuration BPDUs in order to elect itself as the Root Bridge.

Recommended:

• Proactively configure the primary and backup root (or secondary root).

• Enable Root Guard and BPDU Guard to defeat MiTM attacks.

BPDU Guard and Root Guard are enhancements to Spanning Tree Protocol (STP) enhancements that improve the reliability of the protocol to unexpected events.

Remember that the purpose of the the Spanning Tree algorithm is to create a single path through the network to prevent loops. because the Ethernet frame has no loop prevention mechanism. 

Both BPDU Guard and Root Guard are used to enforce design enforcement (integrity / security) and ensure that the STP protocol operates as designed. In brief:

• Root Guard is mainly implemented on Switch to Switch connections (except ports of the root switch and root ports) and access ports at the network edge, for example: servers, laptop and desktop ports.

• BPDU Guard is implemented at the Network Edge.

You can use together BPDU Guard and Root Guard on access ports to protect them against unexpected BPDUs.

BPDU Guard

• Prevents problems related to switches accidentally being connected to PortFast-enabled ports.

• The port is shut down in an error condition (errdisable) if it receives a BPDU (whether superior to the current root or not) and must be either manually re-enabled or automatically recovered through the errdisable timeout function.

• You should use BPDU Guard on all switch ports where STP PortFast is enabled. This prevents any possibility that a switch will be added to the port, either intentionally or by mistake.

• An obvious application for BPDU Guard is on access-layer switch ports where users and end devices connect.

• You never should enable BPDU Guard on any switch uplink where the root bridge is located.

 

Note: A port that has PortFast enabled also has BPDU guard automatically enabled. By combining PortFast & BPDU guard we have a port that can quickly enter the Forwarding state from Blocking state and automatically shut down when receiving BPDUs.

 

By default, BPDU Guard is disabled on all switch ports. You can configure BPDU Guard as a global default, affecting all switch ports with a single command or on per-port basis. Let’s see:

 

To enable or disable BPDU Guard globally on the switch:

Switch(config)# [no] spanning-tree portfast edge bpduguard default

 

Note: in Earlier releases, to enable BPDU Guard globally:

Router(config)# spanning-tree portfast bpduguard default

 

To enable or disable BPDU Guard at the interface level (on per-port basis):   

Switch(config-if)#  spanning-tree bpduguard {enable | disable}

 

Tip: if you enable BPDU Guard globally on the switch, disable BPDU Guard on trunk links with:

switch(config-if)# spanning-tree bpduguard disable

 

Note You can enable the BPDU guard feature if your switch is running PVST+, rapid PVST+, or MSTP [PVST+ uses STP, the other two use RSTP].

Root Guard

• We can configure the root guard feature to prevent unauthorized switches from becoming the root bridge.

• Root guard was developed to control where root bridges can be located within the network.

• Root guard is best deployed toward ports that connect to switches which should not be the root bridge.

• The root bridge always is expected to be seen on the root port and the alternative ports because these are “closest” (have the best-cost path) to it.

• Root guard can be applied to interfaces where a root bridge should never been seen. Root Guard does not allow the port to become a STP root port.

• When root guard is applied to an interface, it forces the port to essentially always remain as a designated interface, never allowing it to transition to a root port.

• If a root guard-enabled port receives a superior BPDU (or one with a better bridge ID), it inmediately moves the port to a root-inconsistent STP state (essentially the same as the listening state) and does not forward any traffic out that port. No data can be sent or received in that state, but the switch can listen to BPDUs received on the port to detect a new root advertising itself.

• Because it’s impossible to have two designated ports in a same segment, when two ports of one segment are configured with Root Guard, one of them is moved to root-inconsistent state. Thus this link won’t be used.

• Root guard cannot be used on root switch, because this command is based on blocking the port when a superior BPDU is received – while a root switch can’t have a blocked port, only designated ports.

• When the root guard protected port stops receiving superior BPDUs, it automatically unblocks the port and proceeds through its normal listening, learning, and eventually forwarding states.

• Use Root Guard on switch ports where you never expect to find the root bridge for a VLAN. In fact, Root Guard affects the entire port so that a root bridge never can be allowed on any VLAN on the port.

 

To enable root guard on an interface:

Switch(config-if)#  spanning-tree guard root

 

You can enable Root Guard only on a per-port basis. By default, it is disabled on all switch ports.

 

Tip: To display switch ports that Root Guard has put into the root-inconsistent state

Switch#  show spanning-tree inconsistentports

Other STP security features on Switches

Loop Guard

• Loop Guard protect a switch trunk port from causing loops.

• Loop guard prevents alternate or root ports from becoming the designated port due to a failure that could lead to a unidirectional link.

• Loop guard operates only on interfaces that the spanning tree identifies as point-to-point.

• Loop guard should be applied to all non-designated ports (more precisely, on root and alternate ports) for all possible combinations of active topologies. As long as the loop guard is not a per-VLAN feature, the same trunk port might be designated for one VLAN and non-designated for the other.

• When enabled, Loop Guard keeps track of the BPDU activity on nondesignated ports. While BPDUs are received, the port is allowed to behave normally. When BPDUs go missing, Loop Guard moves the port into the loop-inconsistent state. The port is effectively blocking at this point to prevent a loop from forming and to keep it in the nondesignated role.

• When BPDUs are received on the port again, Loop Guard allows the port to move through the normal STP states and become active. In this fashion, Loop Guard automatically governs ports without the need for manual intervention.

• Although Loop Guard is configured on a switch port, its corrective blocking action is taken on a per-VLAN basis. In other words, Loop Guard doesn’t block the entire port; only the offending VLANs are blocked.

• If Loop Guard is enabled on an EtherChannel interface, the entire channel is blocked for a particular VLAN, not just one link (because EtherChannel is regarded as one logical port from the STP point of view).

 

By default, Loop Guard is disabled on all switch ports.

 

To enable loop guard globally on the switch:

Switch(config)# spanning-tree loopguard default

 

Note This feature is most effective when it is enabled on the entire switched network. To avoid bridging loops, you can enable Loop Guard on all switch ports, regardless of their functions. The switch figures out which ports are nondesignated and monitors the BPDU activity to keep them nondesignated.

 

You can override this setting of the spanning-tree loopguard default global configuration command.

To enable or disable loop guard on an interface:

Switch(config-if)#  [no] spanning-tree guard loop

 

To verify Loop Guard:

Switch#  show spanning-tree interface interface-id detail

 

Interoperability of Loop Guard with other STP Features

• The root guard is mutually exclusive with the loop guard feature. The root guard is used on designated ports, and it does not allow the port to become non-designated. The loop guard works on non-designated ports and does not allow the port to become designated through the expiration of max_age. The root guard cannot be enabled on the same port as the loop guard. When the loop guard is configured on the port, it disables the root guard configured on the same port.

• Both uplink fast and backbone fast are transparent to the loop guard feature.

• Loop guard cannot be enabled for ports on which portfast is enabled. Since BPDU Guard works on portfast-enabled ports, some restrictions apply to BPDU Guard.

• Loop guard should not be enabled on shared links. If you enable loop guard on shared links, traffic from hosts connected to shared segments might be blocked.

• Loop guard functions correctly in the MST environment. When the switch is operating in MST mode, BPDUs are not sent on nonboundary ports only if the interface is blocked by loop guard in all MST instances. On a boundary port, loop guard blocks the interface in all MST instances.

Etherchannel Guard

The EtherChannel Guard feature is used to detect EtherChannel misconfigurations between the switch and a connected device. An example of a misconfiguration is when the channel parameters are not identical and do not match on both sides of the EtherChannel. Another example could be when only one side is configured with channel parameters. EtherChannel parameters must be the same on both sides for the guard to work.

When the switch detects an EtherChannel misconfiguration, the EtherChannel Guard places the switch interface in the error-disabled state and displays an error message.

 

The EtherChannel Guard feature can be enabled by using the global configuration command:

Switch(config)# spanning-tree etherchannel guard misconfig

 

STP Terminology

BID (Bridge ID) = bridge priority + MAC address; if bridge priority is the same in all the switches, the switch with the lower MAC address wins the choice for Root bridge.

Root port: port with the lowest-cost path from non-root bridge to root bridge. Each non-root bridge is assigned a single root port that sends and receives traffic.

• On non-root bridges only.

• Best path cost to the root bridge.

• Only one per switch and active at any time.

• Is always in forwarding state in an active/stable topology.

Designated port: non-root port with the lowest path cost to the root bridge. Each segment has a single destinated port. All ports on the root bridge act as designated ports (send and receive traffic as well as BPDUs). In the event of a tie, the lowest sender bridge ID serves as a tie breaker for the choice of designated ports.

• On root and non-root bridges.

• All ports on root bridge are designated ports.

• Receives and forwards frames towards the root bridge as needed.

• Only one per segment.

Non-designated or non-root port: switch ports that are neither root ports nor designated ports. These ports break any bridging loop that would form otherwise. They are placed in the blocking state.

Alternate port: is a port role of RSTP.

• Offers an alternative path towards the root bridge, but is in discarding state in an active topology.

• Present on nondesignated switches.

• Provides a backup of your own Root port. If your Root port fails, the Alternate port is allowed to immediately transition into the Forwarding state and become the new Root port (in essence, the Alternate port is the one that receives the second best BPDU).