1 |
> -----Original Message----- |
2 |
> From: Samuraiii <samurai.no.dojo@×××××.com> |
3 |
> Sent: Thursday, June 16, 2022 9:48 PM |
4 |
> To: gentoo-user@l.g.o |
5 |
> Subject: Re: [gentoo-user] netfilter partial MAC filtering |
6 |
> |
7 |
> On Fri, 2022-06-17 at 01:32 +0000, Laurence Perkins wrote: |
8 |
> > I am designing a small system with a switch and an uplink. It needs |
9 |
> > to be able to forward traffic from trusted, and only trusted, devices |
10 |
> > connected to the switch out through the uplink. |
11 |
> > |
12 |
> > Since all potential trusted devices will have the same MAC OUI prefix |
13 |
> > in this case, the immediately obvious course of action would be to |
14 |
> > base the decision on that. |
15 |
> > |
16 |
> > Unfortunately, there doesn't seem to be a good way to do so. There |
17 |
> > was |
18 |
> > https://serverfault.com/questions/877576/shorewall-wildcard-filter- |
19 |
> > by-source-mac-address from a few years ago, with the answer being "You |
20 |
> > can't." |
21 |
> > |
22 |
> > While I didn't bother to test it, I'm guessing that adding about 16 |
23 |
> > million MAC filtering rules to the firewall won't be good for |
24 |
> > performance. I briefly thought I could use the string matching or the |
25 |
> > U32 filters, but unfortunately it appears that they can't access |
26 |
> > anything prior to the start of the IP section, so picking bytes out of |
27 |
> > the ethernet header isn't possible. |
28 |
> > |
29 |
> > I did find |
30 |
> > https://martin.uy/blog/wildcard-support-for-mac-addresses-in-netfilter |
31 |
> > -linux-kernel-and-iptables/ |
32 |
> > But it's old, and has something of a glaring flaw with regard to |
33 |
> > false wildcard matches. |
34 |
> > |
35 |
> > I can think of a few ways to do this, mostly involving somehow |
36 |
> > monitoring incoming packets and noting the MAC addresses which have |
37 |
> > the correct prefix, and then having a little daemon pick up those |
38 |
> > addresses and add rules to let them through. |
39 |
> > |
40 |
> > Either that, or try to write a custom netfilter module. |
41 |
> > |
42 |
> > None of this seems particularly "fun" to sort out. Does anybody know |
43 |
> > of any common solutions for doing packet matching based on just part |
44 |
> > of a MAC address on Linux? Failing that, some advice about whether |
45 |
> > the system daemon and packet inspection route or the netfilter module |
46 |
> > route is more likely to be stable and maintainable would be |
47 |
> > appreciated. |
48 |
> > |
49 |
> > Thanks, |
50 |
> > LMP |
51 |
> Hi, |
52 |
> I would recommend to look into nftables and its set feature... |
53 |
> It should perform better with one rule for multiple matches. |
54 |
> I bet no one had tried it with 16M items, but it is the best, as far as I know. |
55 |
> Cheers |
56 |
> S |
57 |
> |
58 |
> |
59 |
> https://wiki.nftables.org/wiki-nftables/index.php/Sets |
60 |
> https://developers.redhat.com/blog/2017/04/11/benchmarking-nftables#the_first_test |
61 |
> |
62 |
I guess it's worth a shot. If it has enough intelligence to collapse the search list so it only has to look for the prefix once then it would at least reject forbidden connections quickly...
|
63 |
|
64 |
I'll generate out the whole list and see what happens and let you guys know.
|
65 |
|
66 |
LMP |