General Layer 2 Security Recommendations
Recall that the beginning of the “Layer 2 Security” section outlined the Cisco SAFE Blueprint
recommendations for user and unused ports and some general recommendations. The general
recommendations include configuring VTP authentication globally on each switch, putting unused
switch ports in an unused VLAN, and simply not using VLAN 1. The underlying configuration for
each of these general recommendations is covered in Chapter 2.
Additionally, Cisco recommends not using the native VLANs on trunks. The reason is that in some
cases, an attacker on an access port might be able to hop from its access port VLAN to a trunk’s
native VLAN by sending frames that begin with multiple 802.1Q headers. This attack has been
proven to be ineffective against Cisco switches; however, the attack takes advantage of unfortunate
sequencing of programming logic in how a switch processes frames, so best practices call for not
using native VLANs on trunks anyway. Simply put, by following this best practice of not using
the native VLAN, even if an attacker managed to hop VLANs, if there are no devices inside that
native VLAN, no damage could be inflicted. In fact, Cisco goes on to suggest using a different
native VLAN for each trunk, to further restrict this type of attack.
The last general Layer 2 security recommendation covered in this chapter is to consider the use of
private VLANs to further restrict traffic. As covered in Chapter 2, private VLANs restrict hosts on
some ports from sending frames directly to each other. Figure 18-8 shows the allowed flows as
dashed lines. The absence of a line between two devices means that private VLANs would prevent
them from communicating. For example, PC1 and PC2 are not allowed to send frames to one
another.
Private VLANs are created with some number of promiscuous ports in the primary VLAN, with
other isolated and community ports in one or more secondary VLANs. Isolated ports can send
frames only to promiscuous ports, whereas community ports can send frames to promiscuous
ports and other community ports in the same secondary VLAN.
Private VLANs could be applied generally for better security by making user ports isolated, only
allowing them access to promiscuous ports like routers, servers, or other network services. However,
other, more recent additions to Cisco switches, like DHCP snooping, DAI, and IP Source Guard,
are typically better choices.
Private VLAN Allowed Flows
If private VLANs are used, Cisco also recommends additional protection against a trick by which
an attacker can use the default gateway to overcome the protections provided by private VLANs.
For example, in Figure 18-8, PC1 could send a frame with R1’s destination MAC address, but with
PC2’s destination IP address (10.1.1.2). The switch forwards the frame to R1 because R1’s port is
promiscuous. R1 then routes the packet to PC2, effectively getting around the private VLAN
intent. To solve such a problem, the router simply needs an inbound ACL on its LAN interface that
denies traffic whose source and destination IP addresses are in the same local connected subnet.
In this example, an access-list 101 deny ip 10.1.1.0. 0.0.0.255 10.1.1.0 0.0.0.255 command would
prevent this attack. (Of course, a few permit clauses would also be appropriate for the ACL.)
Isolated
Ports Community
Ports
Promiscuous
Port
PC3 PC4
PC1
10.1.1.1
PC2
10.1.1.2
Secondary
VLAN 12
Secondary
VLAN 34
Primary VLAN,
Subnet 10.1.1.0/24