Stand up a rogue DHCP server and catch it

applied · 50 min · Objective 4.2

Task

Reproduce the most common "some machines work and some do not" fault on a network: a second DHCP server handing out its own gateway. You will run the rogue server yourself so you can see the race, then detect it the way you would in production.

Steps

  1. Confirm the legitimate service first. On Host A release and renew, then read what it was given: it should have gateway 192.168.10.1 and the router's DNS. Write those values down as the correct answer.
  2. On Host C, start a competing DHCP server that offers itself as the gateway. With dnsmasq: sudo dnsmasq --interface=eth0 --no-daemon --dhcp-range=192.168.10.150,192.168.10.199,1h --dhcp-option=3,192.168.10.30 --dhcp-option=6,192.168.10.30. Option 3 is the gateway and option 6 is DNS — both now point at the attacker.
  3. On Host A, release and renew several times in a row. Because clients accept whichever offer arrives first, some renewals now come back with gateway 192.168.10.30. That intermittent, per-client wrongness is the exact symptom the exam describes.
  4. Detect it without knowing where it is. From Host A, ask the network which servers answer a DHCP discover: sudo nmap --script broadcast-dhcp-discover -e eth0. Two distinct server identifiers in the output is the finding — one network should have one DHCP server.
  5. Identify the rogue by its address, then stop dnsmasq on Host C and confirm Host A renews cleanly back to the real gateway.

Verify

ip route show default
sudo nmap --script broadcast-dhcp-discover -e eth0 | grep -i "server identifier"
sudo dhcping -s 192.168.10.30 2>/dev/null; echo "rogue reachable exit $?"

The broadcast-dhcp-discover output listing two server identifiers is the proof the fault is a second DHCP server rather than a client misconfiguration. After you stop the rogue, the same command returning a single server is the proof the network is clean again — which is the state you were asked to restore.

Notes

The production defence is DHCP snooping on the switch: you nominate the ports that are allowed to send DHCP server responses — the ones facing your real servers — and the switch drops server-side DHCP messages arriving on any other port. A rogue plugged into an access port is silenced before a single client hears it.

Notice the detection did not require finding the rogue's cable. The offer itself carries the server's address, so one broadcast discover names the offender. That is the general shape of catching a rogue service: make it answer, and read the answer.

The accidental version of this attack is more common than the malicious one — a home router plugged in backwards, LAN port to the wall, serving DHCP to the office. The symptom is identical, which is why "some clients get a wrong gateway" should make you think second DHCP server before you think attacker.