STP SECURITY FEATURES ON SWITCHES

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

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. Bridging loops would normally instantly occur. It places inmediately the port in err-disable state if it receives a BPDU (whether superior to the current root or not) - disabling the interface. The port is shut down in an error condition and must be either manually re-enabled or automatically recovered through the errdisable timeout function.

The BPDU Guard feature was developed to further protect the integrity of switch ports that have PortFast enabled.

Normally, PortFast provides quick network access to end-user devices, where bridging loops never are expected to form. Even while PortFast is enabled on a port, STP still is running and can detect a bridging loop. However, a loop can be detected only in a finite amount of time —the length of time required to move the port through the normal STP states.

Suppose that a switch is connected by mistake to a port where PortFast is enabled and BPDU Guard is not in use. Now, there is a potential for a bridging loop to form. An even greater consequence is that the potential now exists for the newly connected device to advertise itself and become the new root bridge.

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

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: in Earlier releases, to enable BPDU Guard globally:

Router(config)# spanning-tree portfast bpduguard default

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.

BPDU Guard is mainly used on access-layer switch ports where users and end devices connect. BPDUs normally would not be expected there and would be detected if a switch or hub inadvertently were connected.

You don't need bpduguard to block a loop. That's what STP does naturally. Bpduguard is just a way of enforcing a security policy that states that a given port should never receive a bpdu. This could be helpful in the case where a hub is connected to an access port. The hub does not generate bpdus, so it is legitimate to configure bpduguard on the access port. If some users create a loop on the hub, it will send back to the access port its own bpdus. The access port will then go errdisable, at least isolating the loop if it cannot prevent it.

A hub doesn’t transmit BPDUs itself; it merely repeats Ethernet frames from its other ports. A loop could form if the hub became connected to two locations in the network, providing a path for frames to be looped without any STP activity.

Note If BPDU Guard is enabled on an uplink port, BPDUs will be detected and the uplink will be put into the Errdisable state. This will preclude that uplink port from being used as an uplink into the network.

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

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

The Root Guard feature can be enabled on all switch ports where the root bridge should never be seen (that is, every port that is not a root port , the port on each switch that is considered to be closest to the root bridge). So you can use this feature on access ports enabled with portfast and bpdu 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.

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.

Switches learn about and elect root bridges based on BPDUs they receive, so if a new switch is added to the environment with a lower bridge priority than the current root bridge (or the same bridge priority but a lower MAC address), the new switch will become root – and in turn disrupt your carefully planned traffic patterns. The STP topology might reconverge to a new shape. This is entirely permissible by the STP because the switch with the lowest bridge ID always wins the root election. In addition, while the topology is reconverging, your production network might become unavailable.

To prevent this from occurring, 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. The local switch will not allow the new switch to become the root. 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.

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.

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.

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. No intervention is required.

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.

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.

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

The Loop Guard is another enhanced feature that provides an additional layer of protection against the Layer 2 forwarding loops (STP loops) by preventing alternate or root ports from becoming designated ports because of a failure resulting in a unidirectional link. This feature is most effective when it is enabled on the entire switched network.

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

By default, the spanning tree does not send BPDUs on root or alternate ports.

Most bridging loops that occur when STP is active happen when a port in blocking state stops receiving BPDUs on the interface and therefore transitions to forwarding state – creating an all-ports-forwarding loop.

If BPDUs are being sent over a link but the flow of received BPDUs stops for some reason, the last known BPDU is kept until the Max Age timer expires. Then that BPDU is flushed, and the switch thinks there is no longer a need to block the port. After all, if no BPDUs are received, there must not be another STP device connected there.

The switch then moves the port through the STP states until it begins to forward traffic—and forms a bridging loop. In its final state, the port becomes a designated port where it begins to relay or send BPDUs downstream, when it actually should be receiving BPDUs from upstream.

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.

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

To enable loop guard globally on the switch:

Switch(config)# spanning-tree loopguard default

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

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.

For the same reason, if 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).

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.

Note: 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.

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).