Defence: port security, DHCP snooping and ARP inspection
MAC flooding, DHCP starvation, rogue DHCP and ARP spoofing all work because a plain switch, and the devices on it, believe whatever arrives. First watch each attack from the defender's side: what the switch, the router and the laptop see arrive, and why the old behaviour accepts it. Then turn on three switch features and watch each attack fail on the same switch: a cap on MAC addresses per port, trusted and untrusted ports for DHCP, and a binding table that every ARP message is checked against.
7 quick questions
Pick an answer to see why. Your score saves with your progress.
01On a switch with no defences, port 2 sends frames from thousands of made-up source MACs. Why does the attacker end up seeing other people's frames?
A switch learns source MACs into a table of fixed size and floods frames for MACs it does not know. Once fakes fill the table, real entries that expire cannot come back, so their frames go out of every port, port 2 included.
02An unasked-for ARP reply arrives at the laptop saying 192.168.1.1 is at the attacker's MAC. Why does the laptop believe it?
RFC 826 has no field that proves who sent a message, and its receive rule overwrites an existing entry for the sender's IP. So the laptop's frames for its gateway now go to the attacker.
03Port 2 is allowed one MAC address and already uses it. Frames arrive on port 2 with a new, made-up source MAC. What happens?
Each extra MAC breaks the port's limit, so the frames are dropped and counted, or the whole port is disabled in the strictest mode. The MAC table never fills, so the switch never falls back to flooding.
04With DHCP snooping on, which port may send a DHCPOFFER into the switch?
Server messages (OFFER, ACK, NAK) are accepted only on trusted ports. Client messages like DISCOVER and REQUEST are allowed from untrusted ports.
05What does a DHCP snooping binding record?
Snooping reads each DHCPACK it lets through and writes which MAC got which IP, on which port and VLAN, for how long.
06The attacker on port 2 sends an ARP reply saying 192.168.1.1 is at its own MAC. Why does Dynamic ARP Inspection drop it?
DAI checks the sender MAC and sender IP of ARP on untrusted ports against the bindings for that port and VLAN. The attacker's MAC is bound to 192.168.1.166, not to the router's address.
07A printer has a fixed IP address and sits on an untrusted port. What happens to its ARP messages with DAI on, if nobody adds a binding for it?
Bindings come from DHCP. A statically addressed device needs a binding added by hand (or a trusted port), or its ARP is dropped.
Glossary
- Port security
- A switch feature that limits how many source MAC addresses one port may use, and drops frames or disables the port when the limit is broken.
- MAC table (CAM table)
- The switch's list of which MAC address was last seen on which port. It has fixed room; frames for MACs not in it are flooded out of every other port.
- DHCP starvation
- Asking a DHCP server for address after address under made-up client MACs until its pool is empty, so real devices get none.
- DHCP snooping
- A switch feature that lets DHCP server messages in only through trusted ports and records each lease it sees as a binding.
- Trusted port
- A port the switch believes may carry DHCP server messages, usually the uplink toward the real DHCP server. All others are untrusted.
- Binding table
- DHCP snooping's list of leases: MAC address, IP address, port, VLAN and lease time.
- Dynamic ARP Inspection (DAI)
- A switch feature that checks ARP messages on untrusted ports against the binding table and drops any that do not match.
- Rogue DHCP server
- A device that answers DHCP requests without permission, often to hand out itself as the gateway.
Notes and sources
- A plain switch learns each frame's source MAC and floods frames for MACs it has not learned out of every other port (IEEE 802.1Q); learned entries age out, by default after 300 s (IEEE 802.1D).
- ARP (RFC 826) carries no proof of who sent a message, and a host updates an entry it already has from any ARP message. Plain DHCP has no way to tell a real server from a rogue one (RFC 2131 §7); optional DHCP authentication (RFC 3118) is rarely used.
- Starvation that fakes the frame's source MAC is stopped by port security. When only the client MAC inside the DHCP message is faked, switches can check that it equals the frame's source MAC and rate-limit DHCP on untrusted ports.
- MAC addresses 00:00:5e:00:53:xx are RFC 7042 documentation values; ff:ff:ff:ff:ff:ff is the real broadcast address. IPs are from the private range 192.168.1.0/24 (RFC 1918).
- Port security and Dynamic ARP Inspection are switch-vendor features, not IEEE or IETF standards; names and defaults differ between vendors. DHCP snooping's trusted ports and bindings are standardised for source address validation as SAVI-DHCP (RFC 7513).
- On a port-security violation a switch can drop the extra frames, drop and count them, or shut the whole port down until an administrator re-enables it.
- Devices with fixed (static) addresses never send a DHCPACK through the switch, so they have no binding; put them on trusted ports or add their bindings by hand.
- Many switches also rate-limit DHCP and ARP on untrusted ports, so a flood of those messages cannot overload the switch's checks.
- Frames cross a switch in microseconds; the figure slows everything down so you can watch.
- RFC 7513: SAVI solution for DHCP (trusted ports and bindings)
- RFC 7039: Source Address Validation Improvement framework
- RFC 2131: Dynamic Host Configuration Protocol
- RFC 2132: DHCP options (message types)
- RFC 826: Address Resolution Protocol
- RFC 3118: Authentication for DHCP messages (optional, rarely deployed)
- Wikipedia: MAC flooding
- Wikipedia: Forwarding information base (MAC table, flooding)
- Wikipedia: Rogue DHCP
- Wikipedia: DHCP snooping
- Wikipedia: ARP spoofing
Quiz Unlocks after the last step.