CCNA Exploration: Accessing the WAN Chapter 4 Case Study
Objectives:
Secure LAN Layer 2.
Intro:
Radius Inc. wants to improve the security in their network and called you.
The Scenario:
Radius’ network topology is quite simple. A router R1 is used to route packets between Radius’ internal
network and the network outside. Radius also employs 3 switches to interconnect the internal devices.
There are also VLANs created in the switches separate traffic.
The network work flawless at the moment but Radius wants to know whether their network devices are
secure and if not, they want you to implement the proper changes.
Topology:
© 2009 Cisco Learning Institute
CCNA Exploration: Accessing the WAN Chapter 4 Case Study
Step 1 – Analyzing the network
You get to their office and go take a look in the router. It looks like all major security router measures
were taken:
-
remote administrative access was secured;
relevant router activity is being logged;
vulnerable services were secured;
routing protocols were secured;
network traffic is filtered and controlled;
Even though the router was secured, you decide to check the switches. It is common layer 2 devices to
be “forgotten” when securing network devices.
Question 1:
Why is so important to secure layer 2 devices?
Answer: many protocols spoken by layer 2 devices (mostly switches) have vulnerabilities which, if
exploited, can compromise sensitive internal data or even disable network devices.
You connect to SW1, SW2 and SW3 and learn that even though some security was applied to them, a
few important points still make the switches vulnerable.
Step 2 – STP Vulnerabilities
The first vulnerability you notice in the switches regards the Spanning Tree protocol. Spanning Tree
Protocol (or STP) was created to avoid layer 2 loops but since it has no solid authentication mechanism,
any device could pose as a valid STP speaker switch and disrupt the operation of the network.
An attacker using one of the internal PCs could generate malicious SPT control frames (called BPDUs) in
order to disrupt the operation of the protocol.
Radius’ switches are particularly vulnerable to an attack known as “taking over the root bridge”.
As you know, switches speaking STP must elect one switch to act as Root Bridge. A Root Bridge is vital
to STP because it will be the switch used as reference by all other STP participant switches when
creating STP Tree.
The switch with lower bridge ID wins the election and become the Root Bridge. The Root Bridge ID is
included in the BPDUs frames sent out by the switches.
An attacker could use a PC to run an attack tool in order to generate BPDU frames with lower Root
Bridge IDs. Such “manufactured” BPDUs would ensure the attacker’s PC would win the election and
become the Root Bridge just to send out a retraction of that information a few seconds later. This is
© 2009 Cisco Learning Institute
CCNA Exploration: Accessing the WAN Chapter 4 Case Study
guaranteed to cause lots of process churn because of constant state machine transitions, with high CPU
utilization as a result and a potential Denial of Service (DoS).
The countermeasure to a root bridge take over attack is simple. Actually two features help thwart a root
takeover attack: Root Guard and BPDU-Guard.
Root-Guard
The root guard feature ensures that the port on which root guard is enabled is the designated port.
Normally, root bridge ports are all designated ports, unless two or more ports of the root bridge are
connected together. If the bridge receives superior STP Bridge Protocol Data Units (BPDUs) on a root
guard-enabled port, root guard moves this port to a root-inconsistent STP state. This root-inconsistent
state is effectively equal to a listening state. No traffic is forwarded across this port. In this way, the root
guard enforces the position of the root bridge.
Root guard allows the device to participate in STP as long as the device does not try to become the root.
If root guard blocks the port, subsequent recovery is automatic. Recovery occurs as soon as the
offending device ceases to send superior BPDUs.
BPDU-Guard
STP configures meshed topology into a loop-free, tree-like topology. When the link on a bridge port goes
up, STP calculation occurs on that port. The result of the calculation is the transition of the port into
forwarding or blocking state. The result depends on the position of the port in the network and the STP
parameters. This calculation and transition period usually takes about 30 to 50 seconds. At that time, no
user data pass via the port. Some user applications can time out during the period.
In order to allow immediate transition of the port into forwarding state, the STP PortFast feature can be
enabled. PortFast immediately transitions the port into STP forwarding mode upon linkup. The port still
participates in STP. So if the port is to be a part of the loop, the port eventually transitions into STP
blocking mode.
BPDU guard disables the port upon BPDU reception if PortFast is enabled on the port. The disablement
effectively denies devices behind such ports from participation in STP. You must manually reenable the
port that is put into errdisable state or configure errdisable-timeout.
The STP PortFast BPDU guard enhancement allows network designers to enforce the STP domain
borders and keep the active topology predictable. The devices behind the ports that have STP PortFast
enabled are not able to influence the STP topology. At the reception of BPDUs, the BPDU guard
operation disables the port that has PortFast configured. The BPDU guard transitions the port into
errdisable state, and a message appears on the console. This message is an example:
2000 May 12 15:13:32 %SPANTREE-2-RX_PORTFAST:Received BPDU on PortFast enable
port.
Disabling 2/1
2000 May 12 15:13:32 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1
© 2009 Cisco Learning Institute
CCNA Exploration: Accessing the WAN Chapter 4 Case Study
Configuring Root Guard:
Since root guard should be configured in all ports where no root bridges are expected and SW1 is the
only root bridge present in Radius’ network, you connect to SW1 and configure it in all ports. The
commands are shown below:
SW1# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SW1 (config)# interface ra fastethernet 0/1 - 24
SW1(config-if)# spanning-tree rootguard
SW1(config-if)# ^Z
*Mar 15 20:15:16: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Rootguard enabled on
port FastEthernet0/24 VLAN 1.^Z
SW1#
Question 2:
Why SW1 was chosen to act as the Root Bridge?
Answer: SW1 is the switch with more memory and CPU power and was placed in a strategic location.
Configuring BPDU Guard:
STP PortFast BPDU guard can be enabled or disabled on a global basis, which affects all ports that have
PortFast configured. By default, STP BPDU guard is disabled.
You connect to SW2 and SW3 and enable BPDU Guard in them. The commands are listed below for
future reference:
SW2(config)# spanning-tree portfast bpduguard
SW3(config)# spanning-tree portfast bpduguard
When STP BPDU guard disables the port, the port remains in the disabled state unless the port is
enabled manually. You can configure a port to reenable itself automatically from the errdisable state. You
decide to configure SW2 and SW3 in order to recovery from error automatically and issue these
commands, which set the errdisable-timeout interval and enable the timeout feature:
SW2(config)# errdisable recovery cause bpduguard
SW2(config)# errdisable recovery interval 400
SW3(config)# errdisable recovery cause bpduguard
SW3(config)# errdisable recovery interval 400
Note: The default timeout interval is 300 seconds and, by default, the timeout feature is disabled.
© 2009 Cisco Learning Institute
CCNA Exploration: Accessing the WAN Chapter 4 Case Study
Step 3 – VLAN Vulnerabilities
Another problem Radius’ are vulnerable to is known as 802.1q Double Stacking.
While internal to a switch, VLAN numbers and identification are carried in a special extended format that
allows the forwarding path to maintain VLAN isolation from end to end without any loss of information.
Instead, outside of a switch, the tagging rules are dictated by standards such as ISL or 802.1Q.
ISL is a Cisco proprietary technology and is in a sense a compact form of the extended packet header
used inside the device: since every packet always gets a tag, there is no risk of identity loss and therefore
of security weaknesses.
On the other hand, the IEEE committee that defined 802.1Q decided that because of backward
compatibility it was desirable to support the so-called native VLAN, that is to say, a VLAN that is not
associated explicitly to any tag on an 802.1Q link. This VLAN is implicitly used for all the untagged traffic
received on an 802.1Q capable port.
This capability is desirable because it allows 802.1Q capable ports to talk to old 802.3 ports directly by
sending and receiving untagged traffic.
However, in all other cases, it may be very detrimental because packets associated with the native VLAN
lose their tags, for example, their identity enforcement, as well as their Class of Service (802.1p bits)
when transmitted over an 802.1Q link.
For these sole reasons—loss of means of identification and loss of classification—the use of the native
VLAN should be avoided.
When double-encapsulated 802.1Q packets are injected into the network from a device whose VLAN
happens to be the native VLAN of a trunk, the VLAN identification of those packets cannot be preserved
from end to end since the 802.1Q trunk would always modify the packets by stripping their outer tag. After
the external tag is removed, the internal tag permanently becomes the packet's only VLAN identifier.
Therefore, by double-encapsulating packets with two different tags, traffic can be made to hop across
VLANs.
In this situation, an attacker would be able to inject packets from one VLAN to another, without the
participation of the router. This technique is vastly used during DoS attacks.
To avoid this scenario, you connect to the switches and ensure the native VLAN defined in the trunk links
doesn’t match any user VLAN ID.
© 2009 Cisco Learning Institute
CCNA Exploration: Accessing the WAN Chapter 4 Case Study
Since Radius’ network has 3 defined user VLANs (10, 20 and 30) you define the native VLAN as VLAN 5
in order to avoid an attacker from taking advantage of the 802.1q stacking. The commands are listed
below for future reference:
SW1(config)#int fa0/22
SW1(config-if)#switchport trunk native vlan 5
SW1(config-if)#end
SW1(config)#int fa0/23
SW1(config-if)#switchport trunk native vlan 5
SW1(config-if)#end
SW2(config)#int fa0/22
SW2(config-if)#switchport trunk native vlan 5
SW2(config-if)#end
SW2(config)#int fa0/23
SW2(config-if)#switchport trunk native vlan 5
SW2(config-if)#end
SW3(config)#int fa0/22
SW3(config-if)#switchport trunk native vlan 5
SW3(config-if)#end
SW3(config)#int fa0/23
SW3(config-if)#switchport trunk native vlan 5
SW3(config-if)#end
© 2009 Cisco Learning Institute
CCNA Exploration: Accessing the WAN Chapter 4 Case Study
Question 3:
Should this scenario be considered vulnerability?
Answer: No, this scenario is to be considered a bad configuration. Since the 802.1Q standard does not
necessarily force the users to use the native VLAN in these cases. As a matter of fact, the proper
configuration that should always be used is to clear the native VLAN from all 802.1Q trunks (alternatively,
setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN
cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this
VLAN for any other purpose. Protocols like STP, DTP, and UDLD should be the only rightful users of the
native VLAN and their traffic should be completely isolated from any data packets.
Note: Even though only two layer 2 vulnerabilities were addressed in this Case Study, there are many
others that deserve special attention. For more information refer to: LAN Switch Security - Cisco Press.
http://safari.ciscopress.com/1587052563
© 2009 Cisco Learning Institute