I run a few public-facing Linux bridges for VLAN trunking in our edge network. Lately we saw odd DHCP behavior — clients timing out, server logs flooded with DISCOVER bursts. After ruling out faulty cables and misconfigured scopes, the pattern pointed to a classic DHCP starvation attack: someone flooding the bridge with spoofed MAC addresses to exhaust the address pool.
In my environment, the bridge itself doesn’t run a DHCP server; it just passes traffic. So iptables wouldn’t see the packets — they’re bridged, not routed. That’s where ebtables comes in. It lets you filter and rate-limit frames at layer 2, exactly what we need for ARP and IPv4 DHCP traffic.
Here’s how I set up a simple rate limit on br0 to curb the flood without breaking legitimate renewals.
Why ebtables for DHCP Protection
DHCP starvation works by blasting DISCOVER packets with random chaddr fields. Each unique MAC tricks the server into offering a new lease, quickly exhausting the pool. Since these are layer 2 broadcasts, they breeze past iptables on the bridge interfaces. ebtables operates before the bridge decision, so we can drop or limit them early.
I first checked what was hitting the bridge:
watch -n 1 'ebtables -L -v'The output showed thousands of ARP and IPv4 frames per second from a single port — classic flood signature.
Rate-Limiting ARP and IPv4 Frames
Instead of dropping everything (which could break legit clients during reconnect), I chose a rate limit: allow a burst of 50 frames, then sustain 10 per second. This keeps the DHCP server from being overwhelmed while preserving normal operation.
I created two rules — one for ARP, one for IPv4 — using the ebtables limit match:
ebtables -A FORWARD -p arp --limit 10/sec --limit-burst 50 -j ACCEPT
ebtables -A FORWARD -p arp -j DROP
ebtables -A FORWARD -p IPv4 --limit 10/sec --limit-burst 50 -j ACCEPT
ebtables -A FORWARD -p IPv4 -j DROPThe --limit and --limit-burst options use the same syntax as iptables. After the burst, excess frames get dropped silently.
Making the Rules Persistent
On Debian/Ubuntu, I save the ruleset:
sudo ebtables-save > /etc/ebtables.rulesThen I added a restore line to /etc/network/interfaces for br0:
iface br0 inet manual
bridge_ports eth1 eth2
pre-up ebtables-restore < /etc/ebtables.rulesOn RHEL/CentOS, the equivalent is saving to /etc/sysconfig/ebtables and enabling the ebtables service.
Monitoring the Effect
After applying the rules, I watched the counters:
ebtables -L FORWARD -vThe ACCEPT rules showed steady traffic at ~10fps, while the DROP rules climbed — confirming the flood was being trimmed. DHCP DISCOVER logs on the server dropped from thousands per second to a manageable rate, and clients started getting leases again.
Limitations and Tuning Tips
This isn’t a silver bullet. A determined attacker could still exhaust the pool with slow, low-rate requests. For that, you need DHCP server-side protections like mac-address filtering or rate limiting per MAC (available in ISC dhcpd, Kea, or Windows Server).
Also, ebtables limit matching is connectionless — it doesn’t track per-MAC state. If you need per-client limits, consider combining this with ebtables + ipset or moving to nftables.
As I mentioned before in my post about journald rate limiting, the same burst/sustain principle applies here: absorb normal spikes, stop the flood.
If you’re seeing DHCP issues on a bridged network, check ebtables counters first. It’s lightweight, works in the bridge path, and doesn’t require touching the DHCP server itself.
Cover image: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line