From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb

OECG – Chapter 21

2,094 Words. Plan about 13 minute(s) to read this.

This section of the chapter covers layer 2 security. You know, that wild, wild west of networking – at least it once was. Used to be that if it was on the same segment, it was tough to control. And while it’s still easier (at least more intuitive) to control traffic at layer 3 boundaries, layer 2 has much to offer. Much to offer that we, the aspiring CCIEs, are expected to know. Of course. The author classifies the layer 2 security concerns into classes of unused ports (not connected to anything), user ports (servicing end-user devices or a cable in an unprotected area) and trusted or trunk ports (ports connected to devices we completely trust, not only because we trust the device, but also because that device is in a physically secured area).

General Recommendations for Unused and User Ports

  • General Cisco recommendations
    • Disable dynamic protocols you don’t need, like CDP (no cdp enable) and DTP (switchport nonegotiate).
    • Disable trunking by configuring the port specifically as an access port (switchport mode access).
    • Leverage BPDU Guard (spanning-tree bpduguard enable) and Root Guard (spanning-tree guard root) to prevent spanning-tree attacks and help maintain STP stability.
    • Use dynamic ARP inspection (DAI) or private VLANs to prevent someone from sniffing frames you don’t want them to see.
    • Use port security to, for starters, limit the number MAC addresses you’ll allow. And maybe ratchet it down tighter by restricting to only certain MAC addresses. (Yikes! Can you say administrative nightmare?) See below sectino on “port security” for more info on this.
    • Use 802.1x user authentication.
    • Use DHCP snooping and IP source guard. This will help prevent DHCP denial of service and man-in-the-middle attacks.
  • More Cisco recommendations courtesy of the SAFE blueprint (SAFE is a framework for a secure network, sort of a theory class, although the whitepaper comes with a lot of sample configurations. You need to pass SAFE as an exam part of CCSP certification, last I paid attention, which was back in 2004 or so.)
    • Consider the deployment of private VLANs to not only prevent sniffing, but also to potentially prevent L3 devices from routing traffic between devices in private VLANs.
    • Use VTP authentication everywhere to prevent denial of service attacks.
    • Unused switch ports should be disabled and placed in an unused VLAN.
    • Don’t use VLAN1.
    • Don’t configure native VLANs on trunk links.
  • Port Security
    • When port security is enabled, the switch examines an inbound frame, and makes a decision about whether or not to add that MAC to the bridging table.
    • Port security can limit the number of MAC addresses that can be associated with a port.
    • Port security can limit which MAC addresses are associated with a port, in any of three ways:
      • Statically configuring which MACs are allowed.
      • Dynamically learning MACs up to the max number. These entries are then lost when the switch is reloaded.
      • Dynamically learning MACs up to the max numbers, but saving those MACs into the config so that they’re there when the switch reloads. This is known as “sticky learning”.
    • This prevents a DoS attack, where the switch is flooded with new MAC addresses by an attacker. The switch will, of course, time-out older entries. But then when traffic comes in for a MAC that’s not in the table, what does the switch do? It will flood that traffic to every port except the port that it came in on. This means that the attacker will get a copy of legitimate traffic, since the switch will be doing lots of flooding as the bridging table will be getting constantly cycled in the attack.
    • Another attack that port security prevents is where an attacker claims to be a legitimate MAC that he is not, trying to get the switch to forward the traffic to him instead of the appropriate end-host. Using port security to lock down specific MACs to specific ports can mitigate this kind of attack.
    • IOS commands to configure port security:
      • switchport mode {access|trunk} – you have to set one or the other.
      • switchport port-security [maximum <number>] – enables port security, with an optional count of allowed MAC addresses – defaults to 1.
        • By default, the first MAC address will be used, but that’s it.
        • If that first learned MAC times out of the bridging table, then another can be learned, but only one at a time is allowed.
      • switchport port-security mac-address <mac> [vlan {vlan-id | {access|voice}} – static definition of an allowed MAC, for a specific VLAN (if the port is a trunk), and for the access VLAN or the voice VLAN.
      • switchport port-security mac-address sticky – the switch will remember the MAC addresses it learns dynamically.
      • switchport port-security [aging] [violation {protect|restrict|shutdown}] – defines the Aging Timer and what to do when a violation happens.
        • “protect” – perform port security.
        • “restrict” – send an SNMP trap, and log event in addition to performing port security.
        • “shutdown” – send a voltage spike down the line sufficient to kill the meatspacer attempting to hack you. Not really. Just seeing if you’re awake. Really, it puts the port in an err-disabled state, where you have to shut/no shut to get it back.
  • Dynamic ARP Inspection (DAI)
    • In a man-in-the-middle attack, an attacker can broadcast an gratuitous ARP to poison ARP caches. Then he assumes gathers a large number of frames inappropriately sent to him. To stay hidden, he’ll grab the frame, then forward it on to the legitimate endpoint, thus being in the middle. The attacker will use the data in the frames for whatever.
    • DAI examines ARPs and drops naughty ones. How does DAI determine which ARP requests and replies are naughty?
      • If an ARP reply has an IP that wasn’t assigned by the DHCP server, DAI will drop that reply.
      • If an ARP reply has an IP that doesn’t match up with a static list of IPs and MACs, DAI will drop that reply.
      • If an ARP reply has a source MAC in the ethernet frame header that’s different from the source MAC in the ARP message payload, DAI will drop that reply.
      • Destination MACs and target MACs have to match as well.
      • DAI will review ARP messages for unexpected IPs like,, multicast addresses, etc.
    • IOS commands to configure DAI:
      • ip arp inspection vlan <range> – enabled DAI globally for that VLAN.
      • [no] ip arp inspection trust – interface paragraph command. “no” will enable. If the global command is on above, then the default for an interface is to be enabled. Thus “ip arp inspection trust” has the effect of disabling DAI if you’ve globally enabled it on the switch.
      • ip arp inspection filter <arp-acl-name> vlan <range> – this tells DAI to reference a list of static IP/MAC addresses to be checked for that VLAN.
      • ip arp inspection validate {[src-mac] [dst-mac] [ip]} – turns on the source MAC/payload MAC (and other MAC checks) referred to above.
      • ip arp inspection limit {rate <pps> [burst interval <seconds>}|none} – keeps the switch from being DoS’ed by a zillion ARP messages by dropping excessive ARP messages. 15 is the default, but use this command to tweak that number.
  • DHCP Snooping
    • DHCP snooping observes DHCP conversations, and drops DHCP frames it considers to be naughty. This mitigates attacks where an attacker on a LAN segment acts as a bogus DHCP server, setting itself to be the default gateway.
    • DHCP snooping will build a “DHCP snooping binding table” associating IP addresses and ports. This table is used by DAI and IP Source Guard.
    • DHCP snooping will filter DHCP messages received from UNTRUSTED ports under these circumstances:
      • All messages sent by DHCP servers.
      • DHCP release and decline messages are reviewed against the DHCP snooping binding table. The IP in the messages has to match the expected IP for messages coming from that port, else the messages are dropped.
      • You can also set DHCP snooping to make sure the MAC in the DHCP payload matches the source MAC of the ethernet frame. (Optional feature.)
    • IOS commands to configure DHCP snooping:
      • ip dhcp snooping vlan <range> – globally enables DHCP snooping
      • [no] ip dhcp snooping trust – the “no” version enables on an interface. Without the “no”, DHCP snooping is disabled.
      • ip dhcp snooping binding <mac> vlan <id> <ip-address> interface <id> expiry <seconds> – adds a static entry to the DHCP snooping binding database.
      • ip dhcp snooping verify mac-address – adds the optional check of the ethernet frame MAC with the client ID in the DHCP payload.
      • ip dhcp snooping limit rate <rate> – the maximum number of DHCP messages per second, mitigating DoS attacks
  • IP Source Guard
    • Source guard uses the DHCP snooping database to verify the source IP showing up on that particular port is an expected IP. Source guard can also check MAC and IP addresses against the DHCP database if desired. Naughty frames are dropped.
    • IOS commands to configure IP Source Guard:
      • ip verify source – interface paragraph command; will verify that the source IP matches the IP assigned to the host on that port according to the DHCP snooping database.
      • ip verify source port-security – same as above, but also verifies the MAC.
      • ip source binding <MAC> vlan <id> <IP> interface <id> – creates a static entry in the DHCP snooping database.
  • 802.1X Authentication Using Extensible Authentication Protocol (EAP)
    • 802.1X is a method of user authentication. This means that a human being has to provide a username and password, authenticated by RADIUS.
    • EAP is a protocol used by the 802.1X LAN user authentication RFC, number 3748.
    • The idea is for a human being to satisfy authentication requirements, using 802.1X as the framework. EAP is the protocol that carries the challenge betwen the “authenticator” (the switch), and the “supplicant” (the host the human is interfacing with). The authenticator will translate EAP payload into RADIUS attributes and messages, then passing it along to the “authentication server” (RADIUS). RADIUS will then bless (or not) the authentication attempt, a respond to the authenticator (the switch). The switch will then update the port status to authenticated, and via EAP let the supplicant know that the authentication was successful.
    • 802.1X with EAP is configured similarly to AAA. (Hitting the highlights here, not every command.)
      • aaa new-model
      • radius-server host & radius-server key
      • aaa authentication dot1x {default|group <name>}
      • dot1x system auth-control – global command that enables 802.1X globally.
      • dot1x system port-control {auto|force-authorized|force-unauthorized} – interface command
        • auto – Use 802.1X, let the results of the authentication speak for themselves.
        • force-authorized – skip 802.1X; the port is authorized.
        • force-unauthorized – skip 802.1X – the port is not authorized.

General Layer 2 Security Recommendations (A miscellaneous collection of motley facts that needed to be mentioned but perhaps don’t merit more than a brief look. I’m keeping it terse, because this post is way too long. I said a lot for not saying alot.)

  • Configure VTP authentication globally on each switch.
  • Put unused ports in an unused VLAN, not VLAN1. (None of us would do that, ever! The horror!! <ahem>)
  • Do not use native VLANs on trunks.
  • If you must use native VLANs, use a different one on different trunks to mitigate certain kinds of attacks.
  • Use private VLANs to isolate traffic. (We use these at work to isolate some of our colo customers from each other. Way cooler than giving them each their own /29 or /30 VLAN. Efficient use of IP address space, and they can’t see each other at all. But they’re sort of a turd to configure, not a terribly intuitive configuration.)
    • Promiscuous ports – in the primary private VLAN. Promiscuous ports can talk to any other port in the private VLAN.
    • Isolated ports – in a secondary private VLAN. Can only send to a promiscuous port.
    • Community ports – in a secondary private VLAN. Can sent to promiscuous ports, and other ports in the same community VLAN. You can have multiple community VLANs in a private VLAN. The communities ports can only talk to community ports in the same community vlan and promiscuous, but not to other community ports in other community VLANs.
    • You can use an ACL to deny traffic that attempts to work around the private VLAN by forwarding traffic to a host on the same network, but with the MAC of the router. The idea is that the frame hits the router, and then the router hairpin routes the frame to the host.

Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks