Answer by A.B for Best way to filter/limit ARP packets on embedded Linux

1. What xx-tables is the best to filter (limit, not drop) ARP packets?

   • iptables

     iptables starts from IP layer: it's already too late to handle ARP.

   • arptables

     While specialized in ARP, arptables lacks the necessary matches and/or targets to limit rather than just drop ARP packets. It can't be used for your purpose.

   • ebtables

     ebtables can be a candidate (it can both handle ARP and use limit to not drop everything).

     pro:
     − quite easy to use

     con:
     − it's working on ethernet bridges. That means if you're not already using a bridge, you have to create one and enslave your (probably unique) interface on it, for the sake of having it being usable at all. This comes with a price, both for configuration, and probably some networking overhead (eg: network interface is set promiscuous).
     − as it doesn't have the equivalent of iptables's companion ipset, limiting traffic is crude. It can't do per-source on-the-fly metering (so such source MACs or IPs must be manually added in the rules).

   • nft (nftables)

     pro:
     − this tool was made with the goal to replace other tools and avoid duplication of code, like duplicating match modules (one could imagine that arptables could also have received a limit match, but that would just be the third implementation of such a match module, after ip(6)tables' xt_limit and ebtables' ebt_limit ones). So it's intended to be generic enough to use the same features at any layer: it can limit/meter traffic at ARP level while also doing it per source rather than globally.

     con:
     − some features might require a recent kernel and tools (eg: meter requires kernel >= 4.3 and nftables >= 0.8.3).
     − since its syntax is more generic, rules can be more difficult to create correctly. Sometimes documentation can be misleading (eg: non-working examples).

   • tc (traffic control)?

     It might perhaps be possible to use tc to limit ARP traffic. As tc feature works very early in the network stack, its usage could limit ressource usage. But this tool is also known for its complexity. Even to use it for ingress rather than egress traffic requires steps. I didn't even try on how to do this.

2. CONFIG_IP_NF_ARPFILTER

   As seen in previous point, this is moot: arptables can't be used. You need instead NF_TABLES_ARP or else BRIDGE_NF_EBTABLES (or maybe if tc is actually a candidate, NET_SCHED). That doesn't mean it's the only prerequisite, you'll have to verify what else can be needed (at least what to make those options become available, and various match kernel modules needed to limit ARP).

3. What layer is best?

   I'd say using the most specific layer doing the job would be the most easier to handle. At the same time, the earlier handled, the less overhead is needed, but it's usually more crude and so complex to handle then. I'm sure there are a lot of different possible advices here. ARP can almost be considered being between layer 2 and 3. It's implemented at layer 2, but for example equivalent IPv6's NDP is implemented at layer 3 (using multicast ICMPv6). That's not the only factor to consider.

4. Does ebtables have any advantage over arptables?

   See points 1 & 2.

5. What is the best source on the internet to learn about limiting/filtering network traffic for different kind of packets and protocols?

   Sorry there's nothing that can't be found using a search engine with the right words. You should start with easy topics before continuing with more difficult. Of course SE is already a source of informations.

Below are examples both for ebtables and nftables

with ebtables

So let's suppose you have an interface eth0 and want to use ebtables with it with IP 192.0.2.2/24. The IP that would be on eth0 becomes ignored once the interface becomes a bridge port. It has to be moved from eth0 to the bridge.

ip link set eth0 up
ip link add bridge0 type bridge
ip link set bridge0 up
ip link set eth0 master bridge0
ip address add 192.0.2.2/24 dev bridge0

Look at ARP options for ebtables to do further filtering. As told above ebtables is too crude to be able to limit per source unless you manually state each source with its MAC or IP address with rules.

To limit to accepting one ARP request per second (any source considered).

ebtables -A INPUT -p ARP --arp-opcode 1 --limit 1/second --limit-burst 2 -j ACCEPT
ebtables -A INPUT -p ARP --arp-opcode 1 -j DROP

There are other variants, like creating a veth pair, putting the IP on one end and set the other end as bridge port, leaving the bridge without IP (and filtering with the FORWARD chain,stating which interface traffic comes from, rather than INPUT).

with nftables

To limit to accepting one ARP request per second and on-the-fly per MAC address:

nft add table arp filter
nft add chain arp filter input '{ type filter hook input priority 0; policy accept; }'
nft add rule arp filter input arp operation 1 meter per-mac '{ ether saddr limit rate 1/second burst 2 packets }' counter accept
nft add rule arp filter input arp operation 1 counter drop