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