Integration Value Add of 8021X
Data traffic originating from an end station is disallowed until 802.1X completes. A LAN segment, as previously shown, is comprised of exactly two ports. An authenticator can monitor an operational state and detect the presence of an active device at the remote end of the link or when an active device becomes inactive. Along with link state, these events trigger changes in the authorization state of the switch port. This process is a default condition, and it is demonstrated through port configurations for Cisco IOS-based switches using the following command:
dotlx port-control auto
802.1X is a control plane protocol that provides data plane protection from attack vectors. Other security features can be enabled to alter default network access or configured rules on the data plane. The next three sections examine integration components of such data plane components.
Spanning-Tree Considerations
IEEE 802.1D defines Spanning Tree Protocol (STP). STP is a control plane, linkmanagement protocol for bridged networks that provides path redundancy while preventing undesirable loops in networks built of multiple active paths.
STP is a useful protocol, but unfortunately, it was conceived with no security in mind; as a result, STP is vulnerable to several types of attacks. Chapter 4, "Are VLANs Safe?," discusses these attacks.
By default, 802.1X uses a group MAC address: the port access entity (PAE) group address. This MAC address is 0180.c200.0003, and the IEEE 802.1D assigned it for PAEs' use. In wired deployments, a supplicant's MAC address is unknown to an authenticator prior to any EAPOL exchange.
In a wireless deployment, a supplicant's MAC address might be known to an authenticator prior to an 802.1X exchange. One example is the MAC address of a supplicant being known by an authenticator that also uses IEEE 802.11. IEEE 802.11 establishes a pair-wise association between a station and an authenticator.
In environments that also use 802.11, all EAPOL frames sent by a PAE can then carry the individual MAC address associated with the destination point of a LAN attachment as the destination MAC address. Otherwise, the supplicant can be unknown to the authenticator and vice versa—which is typically the case for most wired deployments. Also, based on the fact that the PAE group address falls within the scope of 802.1D, this ensures that EAPOL is not transparently forwarded by an 802.1D-capable bridge.
Under normal circumstances, Layer 2 access ports connected to a single workstation or server need not participate in spanning tree. When enabled on a port, bridge protocol data unit (BPDU) filtering enables you to avoid sending BPDUs on portfast-enabled ports that are also connected to an end system.
Enabling BPDU-Filter
By default, spanning tree sends BPDUs from all ports regardless of whether portfast is also enabled. After you enable BPDU filtering, it applies to all portfast-enabled ports on the switch. Enabling BPDU-Filter on a port effectively disables spanning-tree capability for a Layer 2 access port.
When BPDU-Filter is explicitly configured on a port, it does not send any BPDUs and drops all BPDUs it receives. When configured globally, BPDU-Filter applies to all operational portfast ports.
Ports in an operational portfast state are supposed to be connected to hosts that typically drop BPDUs. If an operational portfast port receives a BPDU, it immediately loses its operational portfast status. In that case, BPDU-Filter is disabled on this port and STP resumes sending BPDUs on this port.
From an operational perspective with 802.1X, BPDU-Filter does not impact a potential deployment. BPDU-Filter also does not impact any device on the wire that is first authenticating using 802.1X either.
From a deployment perspective, however, this could have a potential impact. If you assume that any device on Layer 2 access ports are running 802.1X, running BPDU-Filter on a port does not buy you anything. The reasons for this are the fundamental rules of the control plane (defined by 802.1X), which state that access to a port is not granted (including the processing of other BPDUs) until 802.1X authorizes a port. Simply put, unless 802.1X has authorized a port, it does not matter if a rogue switch gets plugged in. This potential attack vector would be thwarted by 802.1X itself, anyway. Also, from a security best-practice standpoint, there is no tangible benefit to enabling BPDU-Filter, unless specific requirements dictate otherwise.
Enabling BPDU-Guard
Another spanning-tree security technique is BPDU-guard. BPDU-guard can shut down a port as soon as a BPDU is received on that port. In this way, BPDU-guard helps prevent unauthorized access and the illegal injection of forged BPDUs.
From an operational perspective with 802.1X, BPDU-guard does not impact a potential deployment. BPDU-guard also does not impact any device on the wire that is first authenticating using 802.1X either.
From a deployment perspective, however, this could have a potential impact. If you assume that any device on Layer 2 access ports are running 802.1X, running BPDU-guard on a port does not technically buy you anything. The reason for this are the fundamental rules of the control plane (defined by 802.1X), which state that access to a port is not granted (including the processing of other BPDUs) until 802.1X authorizes a port. Put simply, unless 802.1X has authorized a port, it does not matter if a rogue switch gets plugged in. This potential attack vector would be thwarted by 802.1X, not BPDU-guard. However, from a security best-practice standpoint, this is no reason to disable BPDU-guard.
In the future, 802.1X capability will appear on more network devices themselves as it becomes more pervasive. Hence, the need for BPDU-guard on Layer 2 access ports still remains valuable.
Trunking Considerations
By default, all Ethernet ports on Catalyst switches are set to autonegotiated trunking mode. Autonegotiated trunking allows switches to automatically negotiate Inter-Switch Link (ISL) and 802.1Q trunks. The Dynamic Trunking Protocol (DTP) manages the negotiation.
Setting a port to autonegotiated trunking mode makes the port willing to convert the link into a trunk link, and the port becomes a trunk port if the neighboring port is set as a trunk or configured in desirable mode.
Although the autonegotiation of trunks facilitates the deployment of switches, this also represents a potential attack vector to take advantage of this feature and easily set up an illegitimate trunk. For this reason, as a security best practice, the autonegotiation of trunking needs to be disabled on all ports connecting to user-facing ports.
In concert with 802.1X, disabling automatic trunking occurs by default. Furthermore, when enabling 802.1X, trunking itself is completely disabled. If a deployment of the protection of autonegotiation of trunks is planned for on a per-port basis, the deployment of 802.1X itself can deprecate the need for such a plan. In the future, this model might change as 802.1X becomes more prevalent on all port types.
Information Leaks
If a port can become a trunk, it might also have the ability to trunk automatically and, in some cases, even negotiate what type of trunking to use on the port. DTP provides this ability to negotiate the trunking method with the other device. In concert with 802.1X and the default operation previously examined, DTP should not be a concern of information leakage when examining potential attack vectors in a port-based access-control solution. The same can be said for VLAN Trunking Protocol (VTP) and Cisco Discovery Protocol (CDP). By enabling 802.1X, no DTP, VTP, or CDP information is sent by a switch on the wire until a port is authorized. These control planes and their threat vectors are discussed in Chapter 11, "Information Leaks with Cisco Ancillary Protocols."
NOTE Port Aggregation Protocol (PAgP), VTP, and CDP are discussed in detail in Chapter 11.
In most enterprise networks supporting multicast as a service, multicast hosts use the Internet Group Management Protocol (IGMP) to signal to multicast routers to join or leave an IP multicast group. Multicast routers periodically send an IGMP query message to learn the active members in the group. This is where information from the network might leak. In addition to IGMP, a network routing protocol can also rely on multicast. These types of frames include Open Shortest Path First (OSPF) PIMv1/v2 hellos and Enhanced Interior Gateway Routing Protocol (EIGRP) hellos. Other frames include Distance Vector Multicast Routing Protocol (DVMRP) probes or IGMP self-joins. All these frames might contain network information that serve attack vectors. By default, on Layer 2 access ports, all multicast frames from the network are forwarded on ports that are members of these groups. This includes environments where IGMP snooping constrains the flooding of multicast traffic. Per the default operation of 802.1X, this causes all multicast frames to be dropped until 802.1X authorizes the port. This can indirectly help to level-set other security features, such as port-based broadcast/multicast/unicast storm control.
802.1X frames are never 802.1Q tagged on Cisco switches. The specification for IEEE 802.1X explicitly calls for EAPOL to not be VLAN tagged, but it can optionally be priority tagged. This "native VLAN" approach for 802.1X is needed to be compliant to the 802.1Q specification, because IEEE never sends tagged BPDUs, including 802.1X. As a result, 802.1X and any sort of 802.1Q vulnerability or limitation is entirely an orthogonal issue. 802.1Q exploits typically have to do with piggybacking. The default implementation of 802.1X realizes the full benefit of completely circumventing port piggybacking, because a single physical access port is not partitioned into multiple distinct logical ports. Exceptions to this rule include environments such as IEEE 802.11 wireless LANs (WLAN). 802.1X does not preclude any existing 802.1Q exploits, but it needs to appropriately establish a reasonable level of trust because it is authenticating sessions to begin with. Note that 802.1X and 802.1Q can serve as a means to authorize policy. An authenticator might have access to various types of configured VLANs. These can be employee VLANs, student VLANs, guest VLANs, and so on. 802.1X can work in combination with 802.1Q from a signaling or authorization point of view. Through the use of EAPOL and EAP over RADIUS, authentication, authorization, and accounting (AAA) can instruct an authenticator which VLAN to grant access to on a per-port, per-session basis. (For more information on VLAN assignment, see the section, "VLAN Assignment.")
Continue reading here: Keeping Insiders Honest
Was this article helpful?