Hardening DHCP
DHCP hands a booting machine its address, its gateway and its DNS, which is to say it tells every client where to send its traffic and whom to trust to resolve names.
The protocol has no authentication: a client takes the first offer it hears.
That single fact is the entire threat model.
A rogue DHCP server, a laptop with dnsmasq, answers faster than yours and now owns the gateway and the resolver of everyone who believed it and from there reads, redirects and rewrites traffic at will.
The defense is not in the DHCP server, it is in the switch, the only thing placed to decide which offers are allowed on the wire.
The two attacks and why they go together
The rogue server is the direct blow: plug it in, answer the DISCOVERs, point the gateway and DNS at yourself. Starvation is the groundwork that makes it reliable: flood the legitimate server with DISCOVERs under thousands of fake MAC addresses until its pool is drained, so that each new client has nowhere to get a lease but the rogue. Together they are a man in the middle for the whole segment and neither asks for more than a cheap tool and a port.
What makes it worse than plain interception are the options a rogue server can push on top of the gateway and DNS: a WPAD/PAC URL (option 252) that routes every browser through an attacker proxy, an NTP server (option 42) that skews clocks enough to break certificate validation and Kerberos, a TFTP/boot server that serves a tampered PXE image to a machine before its OS and therefore its antivirus, exists. The lease is a configuration channel and an unauthenticated one.
DHCP snooping: the first-line control
DHCP snooping makes the switch the arbiter the protocol lacks. Every port is untrusted by default and may only emit client messages; the handful of ports that reach a real DHCP server (the uplinks, the server port) are marked trusted and a server OFFER arriving on any other port is dropped. That single distinction kills the rogue server whatever its response speed:
ip dhcp snooping
ip dhcp snooping vlan 10,20,30
no ip dhcp snooping information option # unless your relay uses option 82
interface Gi0/1
description link-to-dhcp
ip dhcp snooping trust
interface range Gi0/2-48
ip dhcp snooping limit rate 15 # blunts starvation
While running, snooping builds a bindings table: the MAC, the IP, the VLAN and the port of every observed lease. That table is the valuable by-product, because two other controls read it. Dynamic ARP Inspection checks every ARP against the bindings and drops those claiming an IP the table says belongs to another, which cuts the ARP spoofing that would otherwise reach the same man in the middle through another door. IP Source Guard filters by source address per port, so a host cannot spoof an IP it was never leased:
ip arp inspection vlan 10,20,30
interface range Gi0/2-48
ip verify source
Rate limiting on access ports is the anti-starvation defense: a port emitting far more DISCOVERs than a real client would trips the limit and is shut, which is exactly the wanted behavior against a laptop flooding MACs.
802.1X is the control that makes the question moot
Snooping, DAI and source guard defend the network against a device already plugged in. 802.1X asks the prior question, whether the device should be on the network at all, by requiring authentication to a RADIUS server before the port carries any traffic beyond the authentication exchange. A rogue DHCP server on an unauthenticated laptop never gets far enough to answer a DISCOVER, because its port never opens. Where it can be deployed, 802.1X with dynamic VLAN assignment is the strongest control and the one that turns “detect the rogue device” into “the rogue device could not connect”. The L2 controls above remain the defense for everything that cannot speak 802.1X, which in a real estate is always a long list: printers, phones, cameras, lab gear.
PXE boot, briefly
Network boot trusts the same unauthenticated DHCP to tell it where its boot image lives, so a rogue server also running TFTP can serve a tampered image to a machine before the OS loads, which is persistence beneath anything that would detect it. Snooping closes the rogue-server half; the other half is preferring HTTPS boot where the firmware supports it, verifying image signatures and keeping Secure Boot on the path rather than letting PXE bypass it by fallback.
Segment the leases
DHCP is also where network segmentation becomes concrete, because each VLAN’s scope is where its clients learn what they can reach. User, guest, IoT and admin networks get separate scopes with separate gateways and DNS, the server VLAN runs on static addresses with no DHCP to poison and the guest scope hands out a gateway that reaches the internet and nothing internal. The lease is the first thing a device learns; segmenting it costs less than de-segmenting a flat network after an incident.
What is actually worth watching
The useful signal is simple and switch-side: snooping already logs the server messages it drops on untrusted ports, which is a rogue server announcing itself and DAI logs the ARPs it rejected. A quick active check from a client also settles the “is there a second server” question in one command:
nmap --script broadcast-dhcp-discover # more than one OFFER is the finding
What I would not bother building is the SIEM-plus-ML apparatus these guides always add. The rogue server is dropped at the port whether a log is read or not; the log is for knowing it happened, not for stopping it.
Where to land
Turn on DHCP snooping on every access switch with only the uplinks and server ports trusted, layer DAI and IP Source Guard on its bindings table and rate-limit the access ports so starvation trips a shutdown rather than a pool drain. Push toward 802.1X where devices allow it, because authenticating the port is strictly stronger than policing what an unauthenticated device is allowed to say. Segment the scopes, keep the servers static and secure PXE so the lease cannot hand a poisoned image to a machine. The protocol will never authenticate itself; it is the switch’s job to do it in its place.