%BPDU Guard% Archives %%page%%

Tag Archive for 'BPDU guard'

Switch Security Layer-2 Attacks – Three

Published

on May 28, 2008

in BCMSN, BPDU Filtering, BPDU Guard, BPDU Root Guard, Certification, Cisco Systems, Concepts and Constructs, DAI, DHCP Snooping, DHCP Spoofing, Dynamic ARP Inspection, IP Source Guard, Loop Guard and Unidirectional Link Detection

. 0 Comments

If the feature talks about trusted/untrusted ports then access ports (facing end-devices or downstream) are untrusted and trunk/other ports (facing distribution/core or upstream) are trusted

DHCP Spoofing and Starvation

DHCP is a protocol that allows end-devices to get network configurations from a central server (router, switch, MS Server). A DHCP server can be spoofed by an attacker whereby end-devices receive network configuration from the attacker DHCP and not the legitimate DHCP server.

The reason why one would want to spoof a DHCP server is because the intruder can configure end-devices with IP Address, Domain Name Service (DNS) and Default Gateway (DG) of their choosing and not the legitimate information; the attacker will then play man in the middle.

Mitigating DHCP Snooping

DHCP Snooping is a Cisco Catalyst feature allowing for configuration of switch ports as either trusted or untrusted so that the ports can respond to DHCP requests. Trusted ports can source all DHCP messages and can host or be an uplink to a DHCP server. Untrusted ports can source requests only. If a rogue device on an untrusted port attempts to send a DHCP response packet, the port is shut down (errdisabled).

Configuration

Step 1:Configure DHCP snooping globally.

switch#configure terminal switch(config)#ip dhcp snooping

Step 2: Configure Trusted and Untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#ip dhcp snooping trust By default all ports are untrusted

Step 3:Configure DHCP Option 82 Insertion.

switch#configure terminal switch(config)#ip dhcp snooping information option This is optional and is to let the forwarded DHCP request packet contain information on the switch port where it originated

Step 4:Configure rate limiting on untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/2 switch(config-if)#ip dhcp snooping limit rate packets per second rate

Step 5:Configure DHCP snooping for selected VLANs.

switch#configure terminal switch(config)#ip dhcp snooping vlan number 1,3-6

Step 6:Confirm the configuration

switch#show ip dhcp snooping

STP Comprimises – STP Operation Protection

STP has two protection methods on ports where PortFast has been enabled. In proper configs PortFast will only be enabled on downstream ports (outward facing) that connect to end-devices. As was discussed in previous posts it is an understood theory that Broadcast Packet Data Unit (BPDU) will not come from these interfaces, if this should happen BPDU guard and BPDU filtering provide protection (this could either signal config error or an attack).

BPDU Guard is used to protect the switched network from problems that may arise from the receipt of BPDUs from ports that they shouldn’t be coming from. This could be from honest mistake or someone trying to add a switch.
BPDU Filtering affects how the switch acknowledges BPDUs seen on PortFast configured ports. The functionality differs depending on whether it is configured globally or per-port.
BPDU Root Guard protects against a switch outside the designated network attempting to become the root bridge by blocking it access until the receipt of its BPDUs ceases.

STP Operation Protection – Configuration of BPDU Guard

Step 1:Enable BPDU Guard Globally

switch#configure terminal switch(config)#spanning-tree portfast bpduguard

Step 2 isplay BPDU Configuration information

switch#show spanning-tree summary totals

STP Operation Protection – Configuration of BPDU Filtering

As mentioned earlier there are two methods of configuring BPDU Filtering, below are the two methods and the differences in how these implementations will affect configuration

STP Operation Protection – Configuration of BPDU Filtering – Global

switch#configure terminal switch(config)#spanning-tree portfast bpduguard default

In a valid config, PortFast ports do not receive BPDUs. If a PortFast enabled port receives a BPDU then it signals an invalid config, BPDU Guard puts the port in errdisabled state.

BPDU Filtering has these affects:

Affects all operational PortFast ports on switches that do not have BPDU filtering configured on the individual ports (i.e. you can have Global and port-based active at the same time)
If BPDUs are seen, port loses PortFast status, BPDU filtering is disabled, and STP sends and receives BPDUs on the port as it should with other STP ports on a switch.
Upon startup, the port transmits 10 BPDUs. If this port receives any BPDUs during that time, PortFast and BPDU filtering is disabled.

STP Operation Protection – Configuration of BPDU Filtering – Port

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#spanning-tree bpduguard enable

At the interface level (port-level) you can enable BPDU guard without also enabling PortFast. When the port receives a BPDU it is put into a errdisabled state.

BPDU Filtering has these affects:

It ignores all BPDUs received.
It sends no BPDUs.

Config this on ports that connect to known end-points that would/should/will never ever see a BPDU.

AND EXPLICIT configuration of PortFast BPDU filtering on a port that is not connected to an end-device can create bridging loops. The port ignores BPDUs and changes to a forwarding state. This does not happen when PortFast BPDU Filtering is enabled globally. This means that if you config this on a port that may be/is connected to another switch and needs to participate in STP in some way/form then it is always in the forward state.

STP Operation Protection – Configuration of BPDU Filtering – Confirmation
switch#spanning-tree summary totals

Confirming Configuration on a specific port
switch#spanning-tree interface gigabitethernet 0/0 detail

STP Operation Protection – Root Guard

Root Guard is a feature that limits on which switch ports the root bridge can be negotiated on. If a root guard-enabled port receives BPDUs that are better that those of the current root bridge, then the port will transition into a root-inconsistent state (STP listenning state).

Root Guard is configured on a per-port basis, recovery requires no intervention. A root guard port is in an STP-designated port state. When root guard is enabled on a port, the switch does not allow that port to become an STP root port. The port remains an STP-designated port.

Root guard should be enabled on all ports that the root bridge is not anticipated on and never will be.

%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 01. Moved to root-inconsistent state

Configuration

Step 1:Enable Root Guard on an interface

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#spanning-tree guard root

Step 2:Verify Root Guard on an interface

switch#show running-config interface gigabitethernet 0/1

Step 3:Verify if any port is in the Root Guard inconsistent state

switch#show spanning-tree inconsistentports

STP Forwarding Loops – Unidirectional Link Detection (UDLD)

A unidirectional link occurs when traffic is transmitted between neighbours in only one direction; this can cause spanning tree loops. UDLD allows detection when this occurs and shuts down the affected interface when it is detected.

UDLD is a layer-2 protocol that works with Layer-1 mechanisms to determine the status of a link. The switch periodically transmits UDLD packets on a UDLD enabled interface; if the packets are not echoed back in a specific time frame, the link is flagged as unidirectional and shut down (for this to work devices on both ends must support UDLD).

UDLD falls outside STP but has benifits to STP in detecting unidirectional links which can cause loops. UDLD can do one of two things depending on whether it is configured as “Normal” or “Aggressive”.

Normal Mode UDLD changed the port to undetermined when UDLD messages/echoes stop coming back
Aggressive Mode UDLD errdisables the port after UDLD messages/echoes stop coming back and it makes 8 re-establishing attempts.

UDLD uses MAC 0100.0CCC.CCCC (01-00-0c-cc-cc-cc) with sub-network Access Protocol (SNAP) High Level Data Link Control (HDLC) protocol type 0×0111.

Configuration

Step 1: Enable UDLD

Step 1.1:On fiber and non-fiber (copper) interfaces

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#udld enable

Step 1.2:Globally on Fiber switch interfaces

switch#configure terminal switch(config)#udld enable

Step 2: Disable UDLD

Step 2.1:On nonfiber interfaces individually

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#no udld enable

Step 2.2:On Fiber interfaces

switch#configure terminal switch(config)#udld disable

Step 3:Reset all interfaces that have been errdisabled by UDLD

switch#udld reset

Step 4:Verify UDLD

switch#show idld interface gigabitethernet 0/1

STP Forwarding Loops – Loop Guard

Similar to UDLD, Loop Guard grants protection for STP when a link is unidirectional and BPDUs are being sent and not received. Without loop guard a unidirectional link will transition to forwarding when it stops receiving BPDUs. When loop guard is enabled and a link stops receiving BPDUs, the interface will move into a STP loop-inconsistent blocking state.

SPANTREE-2-LOOPGUARDBLOCK: No BPDUs were received on port 0/1 in vlan 2. Moved to loop inconsistent state.

When a BPDU is received again on the port, the port will transition to the appropriate state without intervention.

Configuration

Step 5:Enable Loop Guard

Step 5.1:Globally configure Loop Guard

switch#configure terminal switch(config)#spantree global-default loopguard enable/disable

Step 5.1 er-Port Loop Guard

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#spanning-tree guard loop

Step 6:Verify Loop Guard

switch#show spantree guard 0/1

E-2-LOOPGUARDBLOCK: port 0/1 restored in vlan 2

Loop guard is enabled on ports that are participating in spanning tree and are redundant at Layer-2. When a switch stops receiving BPDUs on its root or blocking ports, it will transition the ports to loop-inconsistent, which does not pass traffic. Loop Guard is configured per port on, Loop Guard does not work with Root Guard, and should not be enabled on PortFast ports.

With Loopguard and EtherChannel. the first operational port is used for BPDUs; if the link is unidirectional, loop guard transitions ALL links of the channel to loop-inconsistent. This is not desirable because the inherit redundancy gained through channeling is lost.

MAC Spoofing – IP Source Guard

Similar to DHCP snooping, IP Source Guard this feature can be enabled on a untrusted port to prevent IP address Spoofing.

When started all IP traffic on the port is blocked, except DHCP packets that are caputred by the DHCP snooping feature. When a end-device then receives a valid IP Address from the DHCP server, or when a static IP Address is configured by the user, a per-port and VLAN Access Control List (PVACL) is instaled on the port.

This restricts the end-device to those source IP Addresses configured in the binding; any IP traffic with a different source IP address will be dropped.

Step 1:Configure DHCP snooping globally.

switch#configure terminal switch(config)#ip dhcp snooping

Step 2:Configure DHCP snooping for selected VLANs.

switch#configure terminal switch(config)#ip dhcp snooping vlan number 1,3-6

Step 3: Configure Trusted and Untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#ip dhcp snooping trust

By default all ports are untrusted

Step 4:Configure IP Source Guard, Source IP, and Source MAC Address filtering on the Port.

switch#configure terminal switch(config)#interface gigabitethernet 0/2 switch(config-if)#ip verify source vlan dhcp-snooping port-security

Step 5:Configure rate limiting on untrusted ports.

switch#configure terminal switch(config)#interface gigabitethernet 0/2 switch(config-if)#ip dhcp snooping limit rate packets per second rate

Step 6 Optional if not a DHCP End-Device) Configure a static IP Binding on the port.
switch#configure terminal Switch(config)#ip source binding mac-address vlan vlan-id ip-address interface interface-name

ARP Spoofing

Address Resolution Protocol (ARP) Operation is that a end-device (A) sends a broadcast to determine the MAC Address of a end-device (B) with a particular IP Address. The end-device (B) at that IP Address replies with a MAC Address. The originating end-device (A) caches the ARP response, uses it to populate the destination Layer-2 header and then goes on to send a packet.

By spoofing ARP operation an attacking system then plays man in the middle and appears to be the destination sought by senders. All packets sent to the attacker will be forwarded to the correct end-device after being relayed through the attacking system.

Dynamic ARP Inspection (DIA)

DIA determines the validity of an ARP packet based on a valid MAC address-to-IP Address binding stored in a DHCP snooping database. To ensure validity these actions are taken:

Forwards ARP packets received on trusted interfaces without any checks.
Intercepts all ARP packets on untrusted ports.
Verifies that each intercepted packet has a valid binding before forwarding the packet that can update a local ARP Cahce.
Drops, logs or drops and logs ARP packets with invalid bindings.

Configuration

Step 0:Enable DHCP Snooping

Step 1:Configure DIA on a VLAN or VLAN Range

switch#configure terminal switch(config)#ip arp inspection vlan 1,2,3,4,5

Step 2:Enable DIA trust on an interface (sets the interface as trusted)

switch#configure terminal switch(config)#interface gigabitethernet 0/1 switch(config-if)#ip arp inspection trust

Step 3:Configures DIA to drop ARP Packets when the IP Addresses are invalid, or when MAC Addresses in the body of the ARP packet do not match the addresses specified in the Ethernet header.

switch#configure terminal switch(config)#ip arp inspection validate src-mac dst-mac ip

A post to do with DIA can be found at Richard Bannisters CCIE Blog

Notes and Notices:

This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

Switch Security – Wireless

Published

Deon Botha

on May 27, 2008

in 802.11, Access Point, BCMSN, BPDU Guard, Certification, Cisco Systems, Concepts and Constructs, Root Guard, STP and Wireless

. 0 Comments

This post will be broken into five (including this one) smaller posts. This is taking me far longer than I imagined to finish “Switch Security” (the last section of work before revision) as a section and I have had a few too many close calls in losing this draft post as it gets bigger and bigger.

Security has in the past been focused from the outside in and at the upper layers of the OSI model. Think of the deployment in most situations of a firewall (at the edge). Firewall and security devices often focus on edge routing devices and layer-3 and layer-4 information, stateful packet inspection, etc.

This being said internal communication is often open and unhindered. This is because out of the box “internal” trusted devices forward and just “trust” all. If an attack is launched from inside the network (trusted) then it often goes without notice for a long time. Many security features are available for internal network devices but they must be activated to work.

Access Points

With the large scale adoption of Access Points (APs) and other Wireless devices many employees want the same devices at work as those they enjoy at home. This brings with it the problem of employees plugging wireless AP devices into the office network (Malicious Rogues) when the IT department has no knowledge and has not given consent for these devices to operate on the enterprise network. This is a serious breach of company security because the APs are plugged into a network point (trusted) behind the firewall (untrusted) intentionally hidden from view (behind credenzas, filing cabinets, etc) and network view (SMTP, etc). Because John Doe office employee isn’t thinking about the L33t Hacker or Security ramifications they make the wireless AP work (without any security measures whatsoever).

To mitigate against Spanning Tree Protocol (STP) manipulation, use root guard and the BPDU guard enhancement commands. These commands enforce the placement of the root bridge in the network and enforce the STP domain borders. BPDU guard is best deployed towards user-facing ports to prevent rogue switch-network extensions by an attacker.

Notes and Notices:

Multiple Spanning Tree Protocol

Published

Deon Botha

on April 18, 2008

in BCMSN, Certification, Cisco Systems, Concepts and Constructs and MSTP

. 2 Comments

I noticed a hole in my notes that I was getting confuzzled with. Here are the standards that link to the protocols

STP IEEE 802.1D
MSTP IEEE 802.1S (MERGED LATER INTO IEEE 802.1Q-2003)
RSTP IEEE 802.1W (NOW IEEE 802.1D-2004)
PVST and PVST+ are both Cisco Proprietary and don’t have IEEE standards

There is one basic problem with Per-VLAN Spanning Tree (PVST) and that is when there are many VLANs present the processing required will create considerable load. Also keep in mind (N.B.) that PVST is only supported on ISL and not 802.1Q (this has problems of its own with ISL not supported on all Catalyst switch platforms)

</p>The alternative to this is Multiple Spanning Tree Protocol (MSTP) that creates a single instance of spanning tree (Common Spanning Tree or CST) to run on multiple VLANs. The objective is to reduce the number of instances to match the physical topology thereby reducing CPU load. The instances of spanning tree are reduced to the number of active links available.

Implemented on a large network any given switch would run 4094 instances of spanning tree, each with its own BPDU conversations, root bridge election and path selections. With MSTP one path runs some VLANs and another path runs the other VLANs then there are only 2 instances of spanning tree.

Using this method MSTP converges even faster than PVST+ and is backward compatible with 802.1D STP, 802.1w Rapid Spanning Tree Protocol (RSTP), and the Cisco Proprietary PVST+ architecture. This implementation is not a requirement of ECNM as the number of active VLAN instances in the model is small and very stable due to design.

MSTP allows one to build multiple spanning trees over trunks and grouping them by VLAN. Each instance can be topology independant of other instances. MSTP provides multiple forwarding paths (instances) for data traffic and enables load balancing.

A set of bridges are configured with the same MSTP configuration, which allows them to participate in a specific set of spanning tree instances. Interconnected bridges that have the same MSTP configuration are referred to as a Multiple Spanning Tree (MST) region. Bridges with a different config or legacy bridges (802.1d) are considered a different region.

Network Fault Tolerance is improved over Common Spanning Tree (CST) because failure in one instance (forwarding path) does not affect another instance. This VLAN-to-MSTP must be consistent across bridges within a MST region.

In PVST+ environments, the spanning tree parameters are tuned so that half the VLANs are forwarding on each up-link trunk. With this configuration the following is true:

Load balancing is achieved
One spanning tree for each VLAN is maintained

MST Regions:

MSTP differs from other spanning tree implementations in that it combines some (if not all) VLANs into a logical spanning tree. This brings with it that the BPDU must be tagged with the VLAN information to be able to say which VLAN goes where.

To provide for this each switch running in a MSTP region passes the following information:

An Alphanumeric name (32 bytes)
A configuration revision number (2 bytes)
A 4096-element table that associates the potential VLANs with the given instance.

As said to part of a given MSTP (MST) region the passed information must share the same configuration.

BID

As with PVST the Extended System ID is used in MSTP where the instance number is carried in the Extended ID field. In 802.1D STP each bridge must have a unique identifier. In PVST each VLAN needs a unique identifier. Before only 1023 VLANs were supported now all 4000 VLANs are supported by MAC address reduction.

MST Interactions with 802.1Q

An issue arises with MSTP design with the interoperability with the CST implementation in IEEE 802.1D. According to IEEE 802.1s a MSTP switch must be able to handle at least one Internal Spanning Tree (IST). The MST region consists of one IST and an arbitrary (one or many) number of MSTP instances.

The MSTP instances are simply RSTP instances that only operate within a region (MST). The IST (instance 0) runs on all bridges within a MST. It provides interaction at the boundary with other MST regions and compatibility with 802.1D (CST) and PVST+ networks connected to that given region.

IST receives and sends BPDUs to the CST for compatibility with 802.1D STP. IST is capable of representing the MST as a CST virtual bridge to switches networks outside the MST region. Think of the MST not of many independant switches but one “virtual bridge unit”.

The MST region appears as a single virtual bridge to adjacent CST and MST regions. The MST region uses RSTP port roles and operation.
MSTP switches run IST, augmenting CST information and internal information about the MST region.
IST connects all the MSTP switches in the region and any CST switched domains.
MSTP establishes and maintains additional spanning trees within each MST region. These spanning trees are termed MSTP instances. The IST is numbered 0, and the MSTP instances are numbered 1,2,3 up to 15. Any MSTP instance is local to the MST and is independent of other MST regions.
M-Record is a sub-field, within the BPDU of MSTP instances that enables corresponding instances to calculate a final topology.
MSTP instances combine at the MST regions to become the CST: M-Records are encapsulated within MSTP BPDUs. The original spanning trees (M-trees) are active only within the MST. M-trees merge with the IST at the MST Region to form the CST.
MSTP supports some of the PVST extensions: PortFast is supported, BPDU filter and BPDU Guard supported in MSTP mode, Loop guard and root guard supported in MSTP mode, and private VLANs (PVLANs), you must map a secondary VLAN to the same instance as the primary.

Configuration of MSTP

Entering the MSTP configuration Mode:
switch(config)#spanning-tree mst configuration
Displaying the current MSTP configuration on the Switch:
switch(config-mst)#show current
Setting the MST region name:
switch(config-mst)#name region_1
Set the MSTP configuration revision number:
switch(config-mst)#revision 1

Take note of the revision number, treat this number like a software version number in programming start from 1 and work upwards (1,2,3,4 etc). Keep in mind that you have to change it manually (this isn’t VTP) on all MST switches it doesn’t update automatically

Map the MSTP instance to VLANs:
instance 1 vlan 1-50 OR 1
Show the configuration that hasn’t been applied yet:
switch(config-mst)#show pending
Assign the current switch you are on as the primary or secondary Root:
switch(config-mst)#spanning-tree mst 1 root primary secondary
Apply the configuration and exit MSTP configuration mode:
switch(config-mst)#end
Enable MAC Address reduction (a.k.a Extended System ID):
switch(config)#spanning-tree extend system-id
If a neighbouring switch is using a pre-standard version of 802.1s:
switch(config-if)#spanning-tree mst pre-standard
Display general spanning-tree information for MSTP:
switch#show spanning-tree mst
Displaying the spanning-tree configuration:
switch#show spanning-tree mst configuration
Displaying the spanning-tree configuration for a specific instance:
switch#show spanning-tree mst 1
Displaying the spanning-tree configuration for a specific interface:
switch#show spanning-tree mst interface fastethernet 1/1
Displaying the spanning-tree configuration for a specific instance on a specific interface:
switch#show spanning-tree mst 1 interface fastethernet 1/1
Finally for DETAILED information on a specific instance:
switch#show spanning-tree mst 1 detail
In a situation when a legacy switch is placed then removed and it doesn’t revert back to PVRST+ or MSTP mode:
switch#clear spanning-tree detected-protocols

References:

MST based on IEEE 802.1s

Notes and Notices:

This is a part of my personal BCMSN notes and research to assist myself in learning and understanding the concepts and theory for the BCMSN exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BCMSN Certification.

Network Ninja

Tag Archive for 'BPDU guard'

Switch Security Layer-2 Attacks – Three

Switch Security – Wireless

Multiple Spanning Tree Protocol

Search

About

Latest

Archives

Categories