Rogue DHCP server

DHCP has no authentication: a client takes the first offer it hears, and the offer sets its address, default gateway and resolver. An attacker runs a second DHCP server and races the real one — often winning by first starving the legitimate server so only its offers remain. Whoever answers becomes the victim's gateway and DNS, a clean man-in-the-middle: traffic can be read, and names redirected to a phishing page. The fix is DHCP snooping on the switch, which only trusts offers from the port where the real server lives.

How a rogue DHCP server works, step by step

DHCP (RFC 2131) has no way to prove who sent an offer, and a client takes the first offer it hears. A rogue DHCP server exploits that: it answers before the real one and hands the client a gateway and DNS server under the attacker's control. In the rogue DHCP lab the victim leases from the real server dhcpServer 10.0.1.10; the attacker 10.0.1.3 runs its own server on 10.0.1.0/24, and the real gateway is 10.0.1.2.

1. The attacker stands up a DHCP server bound to the LAN, with a pool of its own and two poisoned options: option 3 (router) and option 6 (DNS server) both set to 10.0.1.3, itself.
2. Two servers now answer. DORA is Discover, Offer, Request, ACK on UDP ports 67 and 68; whichever Offer reaches the client first wins. The rogue often wins by first starving the real server so only its offers remain.
3. The client accepts the rogue lease. Its default route becomes default via 10.0.1.3, and its resolver is the attacker. Every packet it sends off the LAN, and every name it looks up, now goes through the attacker first.
4. The attacker forwards and NATs the traffic to the real gateway, so pages still load and nothing looks broken, a clean man in the middle.
5. It redirects at will. Sitting in the path, the attacker rewrites the bank's web traffic to its own phishing page, or answers DNS with its own address; the victim types the usual address and lands on the fake.

The real cure lives on the switch, not the client: DHCP snooping, below.

What it looks like on a Linux machine

The attacker's dnsmasq config is three lines that make every offer point at the attacker:

dhcp-range=10.0.1.100,10.0.1.150,2m
dhcp-option=option:router,10.0.1.3
dhcp-option=option:dns-server,10.0.1.3

A probe shows two servers answering one Discover. nmap's script prints each server's identity and the router it offers:

$ nmap --script broadcast-dhcp-discover -e eth0
|     Server Identifier: 10.0.1.3
|     Router: 10.0.1.3
|     Server Identifier: 10.0.1.10
|_    Router: 10.0.1.2

After the victim renews, its default route points at the attacker:

$ udhcpc -i eth0 -n -q
udhcpc: lease of 10.0.1.120 obtained from 10.0.1.3, lease time 120
$ ip route | grep default
default via 10.0.1.3 dev eth0

The victim fetches its bank at the usual address and gets the attacker's page, because the attacker redirected it:

$ curl -s http://10.0.2.10/
FAKE BANK - enter your password

What goes wrong, and how you see it

The wrong gateway in the lease. The tell is default via 10.0.1.3 where it should be 10.0.1.2. The rogue answered first. A host can refuse to be steered by pinning its gateway: ip route replace default via 10.0.1.2 overrides the rogue's lease.

A second DHCP server you did not deploy. nmap --script broadcast-dhcp-discover returns two Server Identifier lines; only one is sanctioned. On a switch, show ip dhcp snooping would list the untrusted port the rogue sits on.

Intermittent gateway or DNS after a reboot. If the rogue and the real server race without starvation, clients flip between them as leases renew, so some machines work and some do not.

The switch cuts it off at the port. DHCP snooping trusts only the port toward the real server and drops DHCP server messages (Offer, ACK) on every other port; the rogue's replies never reach the victim, and a drop counter climbs. The layer 2 security lab shows the rogue being dropped at its port.

Questions people ask

Rogue DHCP vs DHCP starvation? Starvation drains the real pool so it cannot answer; a rogue server then answers instead. Attackers often chain them: starve first, so only the rogue's offers remain.

Can a rogue DHCP server be accidental? Yes. A home router or a virtualization host plugged in with its DHCP left on hands out its own gateway and breaks a network with no malice at all; the switch defence treats both the same.

Does it work against static addresses? No. A host with its gateway, mask and DNS set by hand never sends a Discover, so the rogue has nothing to answer. See DHCP.

See it on real machines