Diagnosing DHCP Starvation Attacks at Home

A home network that suddenly drops every new device into an APIPA address (169.254.x.x) while existing leases

#Problem Statement: Pool Exhaustion via DORA Flooding

DHCP relies on a four-step handshake — Discover, Offer, Request, Acknowledge (DORA) — defined in RFC 2131. Each Discover broadcast carries a client hardware address (CHADDR) in the DHCP header. A legitimate client uses its NIC’s burned-in MAC. A DHCP starvation attack abuses the fact that most servers never validate CHADDR against the actual Ethernet source address, meaning a single physical NIC can forge thousands of unique CHADDR values in a Discover flood, each one requesting and completing a lease

Once the pool — say, 192.168.1.100 through 192.168.1.200, a 101-address scope typical of a home router — is fully allocated to forged identities, no genuine device can obtain an address. New joiners either fail outright or self-assign an APIPA address, and DNS resolution silently breaks because the default gateway was never learned. This is functionally identical to a Layer 2 denial-of-service, but it requires no elevated privileges and no exploit — just a NIC in promiscuous mode and a scripting language that can craft raw Ethernet frames.

#Why Home Equipment Is Uniquely Vulnerable

Enterprise switches mitigate this with DHCP snooping and port-level rate limiting at Layer 2, dropping any DHCP Discover exceeding a configured packets-per-second threshold on untrusted ports. Consumer routers and unmanaged switches have no concept of trusted versus untrusted ports — every port is implicitly trusted, and the DHCP server has no visibility into which physical port a Discover arrived on. This is the same trust-boundary failure discussed in broader network security fundamentals around implicit trust at Layer 2: without segmentation, a single compromised endpoint has the same standing as the router itself.

#Architectural Breakdown

Three architectural layers are involved in both the attack and its remediation:

• Layer 2 (switch fabric): Where DHCP snooping and rate limiting need to live. Without a managed switch, this layer is entirely permissive.
• Layer 3 (DHCP server / router): Responsible for lease allocation logic, lease timers, and — critically — MAC-to-lease binding validation.
• Layer 7 (client behaviour): The forging tool itself, typically a script using raw sockets (Scapy, dhcpstarv, Yersinia) that iterates CHADDR values while ignoring the actual source MAC.

A DHCP starvation attack exploits the gap between Layer 2 and Layer 3: the switch does no inspection, and the server trusts CHADDR unconditionally. Detecting it means instrumenting the layer the attacker assumes is invisible — the broadcast domain itself.

#Lease State Machine Under Load

Each DHCP server maintains a lease table keyed by MAC address with states: FREE, OFFERED, BOUND, EXPIRED. A DHCP starvation attack pushes the entire pool from FREE to BOUND within seconds because the attacker completes the full DORA cycle rather than stopping at Discover — a half-open flood (Discover only) is easier to detect because offers time out; a full-cycle flood is far more damaging because leases persist for their full lease-time (commonly 24-72 hours on consumer firmware), locking the pool long after the attacking process has stopped.

#Implementation Logic: Detection Workflow

The detection sequence, in order of operational priority:

• Confirm pool exhaustion via the router’s lease table (usually under Status > DHCP Clients on consumer firmware, or cat /var/lib/misc/dnsmasq.leases on OpenWrt/dnsmasq-based routers).
• Capture broadcast traffic on the LAN segment to count Discover packets per second and unique CHADDR values per source MAC.
• Correlate CHADDR entropy against source MAC consistency — a single source MAC generating dozens of distinct CHADDR values in a short window is the definitive signature.
• Isolate the offending port or device and apply lease-rate mitigation.

#Capturing the Signature with tcpdump

Run this from a machine connected to a mirrored/monitor port, or directly on the router if it supports packet capture (OpenWrt, pfSense, and OPNsense all do):

1tcpdump -i br-lan -n -e udp port 67 or udp port 68 -w dhcp_capture.pcap
2
3# Live triage without writing to disk
4tcpdump -i br-lan -n -e udp port 67 or udp port 68 | 
5  awk '{ print $2, $9 }' | sort | uniq -c | sort -rn | head -20

The -e flag prints the Ethernet header, exposing the source MAC alongside the DHCP CHADDR field carried inside the payload. If you see one consistent source MAC paired against dozens of different CHADDR values inside a 10-second capture window, you are looking at a live DHCP starvation attack rather than a legitimate burst of new devices joining.

#Quantifying Discover Rate

1tshark -i br-lan -Y "bootp.option.dhcp == 1" -T fields -e eth.src -e bootp.hw.mac_addr -e frame.time_relative | 
2  awk '{ print int($3); count[$1]++ } END { for (m in count) print m, count[m] }'

Anything sustaining more than roughly 5-10 Discover packets per second from a single physical MAC for longer than a couple of seconds is well outside normal client behaviour — legitimate DORA retries back off exponentially per RFC 2131 section 4.1, so a flat, high-rate stream is itself an anomaly signature independent of CHADDR forgery.

#Mitigation: DHCP Snooping and Rate Limiting

If you have a managed switch (even an inexpensive one like a Netgear GS3xx or a TP-Link Omada unit), enable DHCP snooping and treat every access port as untrusted except the uplink to the actual DHCP server:

1# Cisco IOS-style configuration
2ip dhcp snooping
3ip dhcp snooping vlan 10
4!
5interface GigabitEthernet0/1
6 description UPLINK-TO-ROUTER
7 ip dhcp snooping trust
8!
9interface range GigabitEthernet0/2-24
10 description ACCESS-PORTS
11 ip dhcp snooping limit rate 10
12 switchport port-security
13 switchport port-security maximum 2
14 switchport port-security violation restrict

The limit rate 10 directive caps DHCP packets per second per port; combined with port-security maximum 2, a single port cannot flood the network with hundreds of forged CHADDR values even if the attacking device spoofs its own MAC on subsequent frames, because the switch’s CAM table entry limit blocks additional MACs on that physical port.

#Server-Side Mitigation Without Managed Switches

On OpenWrt or pfSense, where a managed switch is not available, mitigate at the DHCP server itself using dnsmasq’s rate-limiting and static lease reservation to shrink the exploitable pool:

1config dhcp 'lan'
2 option interface 'lan'
3 option start '100'
4 option limit '50'
5 option leasetime '4h'
6 option dhcpv4 'server'
7 list dhcp_option '6,192.168.1.1'
8 option ratelimit '20'
9 option rapidcommit '0'

Reducing leasetime from a default of 12h/24h down to 4h is deliberate: it shortens the window during which a completed DHCP starvation attack keeps the pool locked after the attacking process terminates, at the cost of marginally increased renewal chatter (~4 renewal cycles per day per client, negligible on a home LAN).

#Failure Modes and Edge Cases

Several failure conditions complicate detection and response in the field:

• False positives from mesh Wi-Fi backhaul: Mesh nodes relaying client traffic can appear to generate high Discover rates from a single upstream MAC when acting as a Layer 2 bridge; inspect the DHCP relay agent option (option 82) to distinguish relayed traffic from forged traffic.
• Partial exhaustion masking the attack: If the pool is large (a /23 or wider on a prosumer router), an attacker may only consume 30-40% of leases, which manifests as intermittent connection failures rather than a hard outage — much harder to correlate without lease-table logging enabled.
• Static reservations surviving exhaustion: Devices with DHCP reservations bound to their MAC will continue renewing successfully even mid-attack, which can mislead troubleshooting by suggesting the network is healthy when only unreserved clients are actually locked out.
• Rapid-commit exploitation: If rapidcommit is enabled, the attacker skips Offer/Request entirely and completes a lease in a single Discover-Ack-equivalent exchange, roughly doubling achievable exhaustion rate for the same packet volume — always disable rapid-commit on networks without strict CHADDR validation.
• Lease table corruption on restart: Some consumer firmware (notably older Broadcom-based routers) fails to persist the lease table across a reboot, meaning a completed DHCP starvation attack self-resolves on power cycle but gives zero forensic trail — always capture the lease table before rebooting a suspect router.

#Scaling and Security Trade-offs

Choosing a mitigation strategy involves genuine trade-offs rather than a single correct answer:

• Shorter lease times reduce attack persistence but increase broadcast traffic and DHCP server CPU load — negligible below ~50 clients, measurable above 200 on low-power router SoCs.
• DHCP snooping with port-security gives the strongest guarantee (hardware-enforced) but requires managed switching hardware, which most home users do not have between the router and end devices.
• 802.1X port authentication eliminates the attack surface entirely by refusing unauthenticated devices Layer 2 access at all, but the operational overhead (RADIUS server, supplicant configuration on every client, IoT device incompatibility) makes it impractical for most home labs and reasonable only for small-office deployments.
• Static reservation-only pools (disabling dynamic allocation entirely) are the most resistant to a DHCP starvation attack but eliminate plug-and-play convenience, pushing administrative burden onto whoever manages the network for every new device.
• Monitoring-only approaches (tcpdump/tshark alerting without active blocking) carry the lowest implementation cost and zero risk of false-positive lockouts, but provide no automated remediation — acceptable for a home lab, insufficient for anything with uptime requirements.

For a home lab or student environment, the pragmatic baseline is a reduced lease time, disabled rapid-commit, and a scheduled tcpdump capture triggered whenever the lease table crosses 80% utilisation — full DHCP snooping is worth the hardware investment only once the network hosts untrusted or IoT-heavy segments where a single compromised device becomes a realistic threat vector.