The 10-Second Network Crash: Understanding DHCP Starvation
DHCP Starvation is an old-school exploit that remains incredibly effective. It targets the way local networks hand out IP addresses. An attacker uses a tool like Yersinia to flood your DHCP server with thousands of requests using fake MAC addresses.
In a typical /24 network, a single laptop can exhaust all 254 available IP addresses in less than two seconds. Once the pool is empty, legitimate devices can’t connect. This usually sets the stage for a Man-in-the-Middle (MitM) attack, where the attacker hosts a rogue DHCP server to hijack your data.
Enterprise switches usually have built-in toggles for this. However, many modern setups—like Proxmox clusters, KVM hosts, and edge gateways—rely on the Linux Bridge. I’ve deployed these software-defined defenses in production environments with hundreds of VMs. The results are rock-solid, providing hardware-grade security without the $5,000 price tag of a managed switch.
Choosing Your Defense Strategy
You have three main paths to secure a network against DHCP threats. Each has a specific use case depending on your hardware and scale.
- Hardware-Based Snooping: Native to brands like Cisco or Juniper. It’s fast and simple but locks you into specific vendors and expensive support contracts.
- Linux Bridge Filtering (ebtables/nftables): This is the manual, highly flexible approach. It works on any Linux box. It is the gold standard for cloud providers and custom-built routers.
- MAC Limiting: This stops the attack at the source. By restricting a single virtual port to only one or two MAC addresses, you kill the starvation attempt before the first packet reaches the server.
Is a Linux-Based Defense Right for You?
The Benefits
- No Licensing Fees: You are using standard tools like
ebtablesthat are already in your kernel. - Granular Control: You can write scripts that automatically update rules when a new VM is provisioned.
- Better Auditing: Use
journalctlto trigger alerts the moment a port starts dropping suspicious packets.
The Trade-offs
- Learning Curve: You need to understand the Linux networking stack. It isn’t as simple as clicking a button in a web UI.
- CPU Impact: On 10Gbps+ links with massive packet counts, software filtering adds a tiny bit of latency. For most office networks or management LANs, the impact is effectively zero.
A Multi-Layered Security Architecture
Don’t rely on a single firewall rule. I recommend a two-pronged strategy: MAC Address Limiting combined with DHCP Snooping emulation. MAC limiting prevents a single port from claiming the whole IP pool. Meanwhile, DHCP Snooping ensures that only your authorized server can hand out IP addresses. This setup catches both malicious attackers and the accidental “rogue router” plugged in by a well-meaning employee.
Step-by-Step Implementation
1. Prepare the Kernel
Before starting, verify that your bridge is configured to pass traffic through iptables and ebtables. Most modern distributions like Debian or Ubuntu have this on by default.
# Check if bridge filtering is active
sysctl net.bridge.bridge-nf-call-iptables
# If it returns 0, enable it immediately
sudo sysctl -w net.bridge.bridge-nf-call-iptables=1
2. Lock Down MAC Addresses
The most effective way to prevent spoofing is to tie a specific MAC address to a port. If you know that veth-customer1 belongs to a specific VM, drop everything else. This prevents the VM from sending out thousands of requests with random identities.
# Drop any packet from veth-customer1 that doesn't match the authorized MAC
ebtables -A FORWARD -i veth-customer1 -s ! 52:54:00:12:34:56 -j DROP
3. Emulate DHCP Snooping
We need to define “Trusted” and “Untrusted” zones. Your real DHCP server lives on a Trusted port. Everything else is Untrusted. Our goal is to block any DHCP “OFFER” or “ACK” packets if they originate from an Untrusted port.
In this example, eth0 is our uplink to the server, and br0 handles the clients.
# 1. Create a dedicated chain for DHCP traffic
ebtables -N DHCP_SNOOPING
ebtables -P DHCP_SNOOPING RETURN
# 2. Divert DHCP Server responses (UDP port 67) to our new chain
ebtables -A FORWARD -p IPv4 --ip-proto udp --ip-sport 67 --ip-dport 68 -j DHCP_SNOOPING
# 3. The Golden Rule: If a DHCP response comes from anywhere EXCEPT eth0, kill it
ebtables -A DHCP_SNOOPING -i ! eth0 -j DROP
4. Add a Safety Net with Rate Limiting
If you can’t lock MAC addresses—perhaps because a port connects to a sub-switch—use rate limiting. This slows an attack down to a crawl. It turns a 2-second network crash into an event that takes hours to succeed, giving your monitoring tools time to wake you up.
# Limit DHCP requests to 5 per second. This is plenty for normal use.
iptables -A FORWARD -p udp --dport 67 -m limit --limit 5/s -j ACCEPT
iptables -A FORWARD -p udp --dport 67 -j DROP
Testing Your Defenses
Once the rules are live, try to break them. Use a script to generate spoofed DHCP DISCOVER packets. You should see your DROP counters climb while your legitimate laptop still gets an IP without delay.
# Check the stats to see the rules in action
sudo ebtables -L --lc
If the DROP count in the DHCP_SNOOPING chain is increasing during your test, the filter is doing its job. Your legitimate clients will remain unaffected and connected.
Summary
Securing a Linux Bridge takes more manual effort than using a managed switch, but the control you gain is worth it. By combining MAC filtering with ebtables, you turn a basic software bridge into a security-aware gatekeeper. I have used this exact setup to stop broadcast storms and malicious actors in their tracks. It proves that with the right configuration, open-source tools provide enterprise-grade protection.
