Furkan İkkan Türkçe
Back to posts
Post

· Network & System Administrator

Protect Linux Bridge from DHCP Starvation with ebtables Rate Limiting

Stop DHCP solicit floods on Linux bridges using ebtables rate limiting to prevent IP exhaustion and network disruption.

NetworkebtablesDHCPLinux bridgerate limiting

DHCP starvation attacks overwhelm a DHCP server with fake DISCOVER packets, exhausting the address pool and blocking legitimate clients. In my environment, I use Linux bridges for VM and container networking, making this a real risk. The fix isn’t complex: rate-limit DHCP solicit packets at the bridge level using ebtables. This drops excess traffic before it reaches the DHCP server, preserving availability.

First, identify the bridge interface—usually br0 or similar. I’ll use br0 as an example. The goal is to limit DHCPv4 solicit packets (destination port 67, source port 68) to a safe rate. I allow 5 packets per second with a burst of 10, which handles normal DHCP churn while blocking floods.

Here’s the ebtables rule I deploy:

ebtables -A INPUT -p IPv4 --ip-protocol udp --ip-destination-port 67 --ip-source-port 68 \
  -j limit --limit 5/second --limit-burst 10

This appends a rule to the INPUT chain of the bridge table. It matches UDP packets with source port 68 (client) and destination port 67 (server), then applies the limit. Exceeding the rate triggers a DROP by default.

To make this persistent across reboots, I save the rules. On Debian/Ubuntu, I use:

save ebtables rules

Actually, the command is:

ebtables-save > /etc/ebtables/rules

Then I ensure the ebtables service loads them at boot. On systemd systems, enabling ebtables.service usually does this.

You can verify the rule is active with:

ebtables -L INPUT -v

Look for the limit match in the output. If you see packets hitting the limit, it’s working.

Warning: Test this in a staging environment first. If your limit is too low, legitimate DHCP renewals or PXE boots might get dropped. Start with a higher rate like 20/second and adjust based on observed traffic.

As I mentioned before in my post on IPv6 neighbor discovery attacks, layering defenses at multiple points is key. Similarly, here I rely on ebtables as a host-based shield while trusting the infrastructure to handle spoofed sources at the edge.

This approach doesn’t require kernel patches or extra software. It uses existing netfilter tools, making it lightweight and reliable. For public-sector or e-commerce setups where uptime is critical, stopping DHCP starvation at the bridge is a simple, effective step I recommend.

Cover image: Unknown · CC0 (Openverse / kamu malı) · https://www.rawpixel.com/image/6038427/photo-image-public-domain-technology-line