Best way to filter/limit ARP packets on embedded Linux

Question

I have an embedded Linux on some network device. Because this device is pretty important I have to make many network tests (I have a separate device for that). These tests include flooding my device with ARP packets (normal packets, malformed packets, packets with different size etc.)

I read about different xx-tables on the internet: ebtables, arptables, iptables, nftables etc. For sure I'm using iptables on my device.

1. What xx-tables is the best to filter (limit, not drop) ARP packets?
2. I heard something about /proc/config.gz file which suppose to have information what is included in the Kernel. I checked CONFIG_IP_NF_ARPFILTER which is not included. So - in order to use arptables - I should have Kernel compilled with CONFIG_IP_NF_ARPFILTER option enabled, correct? And the same goes to for example ebtables?
3. I read that ebtables & arptables works on OSI level 2 when iptables works on OSI level 3. So I would assume that filtering anything on level 2 is better (performance?) then on level 3, correct?
4. I found somewhere on this website answer to use ebtables to filter ARP packets. Does ebtables have any advantage over arptables?
5. EXTRA ONE. What is the best source on the internet to learn about limiting/filtering network traffic for different kind of packets and protocols?

Solution

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

Comments

[matt]

Thank you so much for your comment. I might have some question but that would be much later. Thank you again, greatly appreciated!

[matt]

Done. I have additional question. This is very newbie one - is TC (traffic control) somehow connected with all the x-tables? Is this software to manage those tables or this is something totally separated? My device cannot use ebtables (it's not a bridge), so I would go with nftables. At the moment we are using prerouting raw table from iptables and probably tc. I was shown only iptables, so I don't even know how to check that tc at the moment.

[A.B]

My answer tells it: 1/ iptables cannot be used. Forget it. 2/ ebtables can be used: add the bridge. It's in my example: ip link add bridge0 type bridge. Your device now has a bridge. You might have to recompile the embedded kernel if the feature isn't present. 3/ nftables is the overall easiest way to go. Same: kernel must be recent and feature present. 4/ tc works really differently than the 3 other tools. It's not using tables but hierarchies/queue disciplines/filters/actions, a concept harder to grasp, for me included. It has a limited communication with x-tables by reading marks.

[A.B]

here's a random tc presentation: Linux Traffic Control. If you have a question about tc, create a new question here on SE. Don't make it a "how can I use it" question: that would be off topic, and anyway it's probably too complex to be answered here. Look for documentation on internet and test it. It's easy to use any linux system with network namespaces, or else VMs, to do tests. Make a question about what you did and what doesn't work as expected

[Binarus]

Thank you very much, +1! That's a lot of starting points (trying to rate limit traffic INTO a VM by source, only knowing iptables quite well so far, and not wanting to change something with the network bridge the VM is connected to). Notably, thank you very much for the example which let us understand at a glance how complex (or not) it is.