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

· Network & System Administrator

Automate ARP Spoofing Protection on Linux Bridge with ebtables

Learn how to use ebtables and static ARP entries to block ARP spoofing on Linux bridges and prevent MITM attacks in your network.

NetworkebtablesARPLinux bridgesecurity

ARP spoofing remains a quiet but effective way for attackers to intercept traffic on bridged networks. In my environment, where Linux bridges are used for container networking and VM isolation, I rely on ebtables to enforce ARP inspection and static bindings. This isn’t about replacing firewalls — it’s about adding a link-layer safety net that drops spoofed ARP replies before they reach the host stack.

Why ebtables for ARP protection?

Standard tools like arptables are deprecated in favor of nftables, but ebtables still works reliably on bridge devices. When a VM or container connects to a Linux bridge, it can spoof ARP replies unless you enforce MAC-to-IP binding at the bridge level. I use ebtables to drop any ARP reply where the sender MAC doesn’t match the expected hardware address for that IP.

Here’s the core rule I deploy on bridge interfaces like br0:

ebtable -A FORWARD -p ARP --arp-op Reply \
  ! -s 00:11:22:33:44:55 --arp-ip-src 192.168.10.10 -j DROP

This says: if an ARP reply claims to be from 192.168.10.10 but the MAC isn’t 00:11:22:33:44:55, drop it. You’d repeat this for each static IP/MAC pair on the bridge.

Automating static ARP bindings with a script

Manually adding ebtables rules for every host is error-prone. Instead, I generate them from a trusted inventory — usually a CSV or DNS export. Here’s a simplified Bash snippet I run via cron or systemd timer:

#!/bin/bash
BRIDGE="br0"
INVENTORY="/etc/network/hosts.csv"  # format: IP,MAC,Hostname

# Flush existing ARP-related ebtables rules (careful in production)
ebtable -t filter -F FORWARD

while IFS=',' read -r ip mac hostname; do
  [[ "$ip" =~ ^# ]] && continue
  ebtables -A FORWARD -p ARP --arp-op Reply \
    ! -s "$mac" --arp-ip-src "$ip" -j DROP
done < "$INVENTORY"

I keep the inventory in Git, so changes are auditable. After updating the CSV, I run the script and verify with ebtables -L FORWARD -v.

Combine with static ARP entries on hosts

Even with ebtables filtering, I still set static ARP entries on critical hosts as a backup. This prevents the host from accepting spoofed replies even if they somehow bypass the bridge (e.g., misconfigured VLANs). On Linux:

sudo arp -s 192.168.10.10 00:11:22:33:44:55 -i eth0

To make it persistent, I add it to /etc/network/interfaces or a Netplan config depending on the distro.

Monitoring and debugging

If traffic breaks after deploying these rules, check:

  • Whether the bridge is actually forwarding (brctl showmacs br0)
  • If ebtables is loaded (lsmod | grep ebtables)
  • Use ebtables -L FORWARD -v to see hit counters
  • Temporarily log instead of drop: -j LOG --log-prefix "ARP-SPOOF: "

I’ve seen cases where DHCP-assigned IPs caused false positives — so this method works best for statically assigned devices like routers, servers, or managed VMs. For dynamic endpoints, consider 802.1X or port security instead.

Final thoughts

ARP spoofing protection at the bridge layer isn’t glamorous, but it’s one of those low-overhead controls that stops casual sniffing and basic MITM attempts. By combining ebtables filtering with static bindings and version-controlled inventory, I’ve reduced false alerts in our IDS and made lateral movement harder.

As I mentioned before in my post about [BGP route leak protection](https://furkanikkan.com/urun/bgp-route-leak-korumasi-rpki-ile-trafik-hijacking-i-engellemek-65), defense in depth starts at layer 2. If you’re managing Linux bridges in production, automate the ebtables rules — don’t wait for an ARP poisoning incident to wish you had.

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