From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D4885158091 for ; Fri, 17 Jun 2022 01:33:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 738B6E08FC; Fri, 17 Jun 2022 01:32:54 +0000 (UTC) Received: from esa1.hc4949-98.iphmx.com (esa1.hc4949-98.iphmx.com [216.71.144.186]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D4C49E08BB for ; Fri, 17 Jun 2022 01:32:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openeye.net; i=@openeye.net; q=dns/txt; s=CES; t=1655429573; x=1686965573; h=from:to:subject:date:message-id:mime-version; bh=dC8Y2tMV06GXTWmf0nzWhMDboAG/DRdOli5G+2i4wR0=; b=A+1uR6AUnVyczYEgT29o0l8kth2uzShT356BT4s7SXnJemNvEUUVA4RK 8y8dmT+yH6xJb653f8/QiuSbMS63BrVVZAUE5398+AZHOGAOoRHX0SXjX Xw3zG626yAcJpSSuWTlsddtlNyihF8GyCqtIXa1x8DGiFk5DUjtW14ZJs Y=; X-IronPort-RemoteIP: 104.47.55.168 X-IronPort-MID: 36298999 X-IronPort-Reputation: None X-IronPort-Listener: Outgoing X-IronPort-SenderGroup: RELAY_O365 X-IronPort-MailFlowPolicy: $RELAYED Received: from mail-bn8nam12lp2168.outbound.protection.outlook.com (HELO NAM12-BN8-obe.outbound.protection.outlook.com) ([104.47.55.168]) by ob1.hc4949-98.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2022 21:32:52 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzOUA/mnAzIrJzh3iumG/EZT3Fall3ciK8clN6iDZPgweLJqc/oEvlEjffCWLtTYE5n5gASZFBhS1PY5Kc4BrsP4Mhf8xmV4mebRWwpfEN3nJYVk1hyjWuh0qMExBiwt18iynp571KuYknXy+gJe8xx4K+HMWa03zyh3lA01LLRefsIdj2e/wFjGyc78UiAvA5tK3BQNLpF1kWvRhDichl0FYg0zktAo/TqjTlJx3G9L+0haU6F0ubrAoLtDwkbvKAY6LceM0D4GlahtO7JPOuFKZQg7HrHzyM+1uf8YiALtwEABO5L8XNgrQYYQY77L6G+imZemHzTiVlVGUjfSdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=RrGShmaS2TQnY+IK7f++/YlDwZa5g4USi4xXm5mtDSM=; b=lHzJjqrR0FZVaR8H7H0ykr3Yld/UUEoGnY1gX1pJwJy9Iv/Ii6VwWmdlkm7YfOVvywCtkZSMoVXNmDgVePp95GsKWqZY2+6gvoeJnh6FUH3paZ28+7SRhn2w0dUPT02su1esXtOv1YU/PK+QcfBHmaIeCs7Xm4k19KT6yM8HNQm6nvoTs+vRIdxO2fWAWj+PdnnLeJ1VKVxazOaJlut40lNKX1I719S3ykpk0R6I0ExQJA951RISsx16vAhgBiaEw0Dlq02NmxsqrdzMomLTj2PLy5IQvzirRlOzaqFolEiC1IsWHBhWo5HNmEluQK3TG5PG8iu4SwPXN0GFvwdcxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=openeye.net; dmarc=pass action=none header.from=openeye.net; dkim=pass header.d=openeye.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alarmcom.onmicrosoft.com; s=selector2-alarmcom-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RrGShmaS2TQnY+IK7f++/YlDwZa5g4USi4xXm5mtDSM=; b=kbhhx2Wym3lJviryvZCQvam2wgJQpvBYUU3qwxUmYD0el1d7SdTIY/7tOi7yxSxsRn0Eo1GJU+dq1gj2+ZiuYoo/b3FADAEAqzSmnCuU+RHYx3MG1saGwb6crIMxUGY77nS78KYG/9+UJMsWEBzJ9ibiW1k21n8iMqnItUBnPq4= Received: from MW2PR07MB4058.namprd07.prod.outlook.com (2603:10b6:907:9::28) by CY4PR0701MB3715.namprd07.prod.outlook.com (2603:10b6:910:93::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.18; Fri, 17 Jun 2022 01:32:49 +0000 Received: from MW2PR07MB4058.namprd07.prod.outlook.com ([fe80::d99e:c834:8e20:cb8f]) by MW2PR07MB4058.namprd07.prod.outlook.com ([fe80::d99e:c834:8e20:cb8f%5]) with mapi id 15.20.5353.015; Fri, 17 Jun 2022 01:32:49 +0000 From: Laurence Perkins To: "gentoo-user@lists.gentoo.org" Subject: [gentoo-user] netfilter partial MAC filtering Thread-Topic: netfilter partial MAC filtering Thread-Index: AdiB6iZ+9XtnnuAWRpKuGLH9AW7G4Q== Date: Fri, 17 Jun 2022 01:32:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=openeye.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 22a5e073-86ef-414b-7234-08da500149f0 x-ms-traffictypediagnostic: CY4PR0701MB3715:EE_ x-microsoft-antispam-prvs: x-outbound-auth: mysecretkey x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Mdq3VZaso7bVnAi2L2jFQLNSE/dwHGWnBOqDnhy0kwiPtSNdHVov20ku4Ovfx7YXR1hI7UocXFMymYzL7dqVCzNM8Ba19hUQwUfjKZObXD/Dvb9+V6P43MChniOp2wPaDcXym1zMCB4QmMmES3GnnwlHSBHqZmVG/sRXZAbQyei4LUu2NMBalFGY7Qa9bXPYRbhF0nEwTBvKxfqev1vJsx3ZppoTVb8p7ZMggWmJoARBhap+TJoTgpLf10QcQEQqZrXywAyRvhr2+Haq0RmIuVoV4cHCKNVoAkZ4j8EAPlaZ82CJ7PONOsKCNCmmBxk0RRs9VbuGL73f0gHEsM/OPH2HlQfyNuptAD00447scyyES9i5Y1lX6yElZ1V2fRthTA2wjfNd+jAZT7ZI/XW6vwtmmdSrVAFTO+/1fDw2r2+NpKhT7yf54kf18edQdfO/INH8rOjQE5uPBZS8EKid/hm9BeCteVhZp6MIPSsNHWZ1ieMHDd1oiOxkeF+uEUJt/dxp2fbu7O7fNaoEL9rN0ND/dEOkoKsOb7U/62oFce8ijPAiMwk0bOvLUEpjQcMXkUnqIq5yK9AWmYb5EXw4Hnr8PTSlf2HX4KexS6ylkBAciW7B69Hc8A9kvbz1mKBO4xF8Q4Q7RBKwmKFVi1ptM+ZeeC+ORfn5FlFn8cjqS7DDcsLwPAGEXrSpP7GawmXpYOD8ZCQjsoMlg8c00W/F+3cRmA9wXc0V/dRHGTM9xtiz55vUeLXS0s0JK3wDNlsJvkiFoHNLbnmjjC+OL6a+UNWtCzc6I2+1GxWYzfnRpHs= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW2PR07MB4058.namprd07.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230016)(4636009)(366004)(33656002)(71200400001)(498600001)(52536014)(76116006)(66946007)(186003)(966005)(2906002)(8676002)(7696005)(83380400001)(38100700002)(166002)(8936002)(55016003)(38070700005)(316002)(64756008)(9686003)(26005)(3480700007)(5660300002)(6916009)(6506007)(66556008)(122000001)(66446008)(66476007)(86362001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rEAM4ACzmC4fHM0zPxXxKcO/ebNi3mV0mLRcpE5lIDJTfsOEumQHICg8aSkg?= =?us-ascii?Q?oOYu4mQYs+4pJbltQouJD3RNtUb/MvcColVjPZVwWD3HRfsbP7mqLllnqpj0?= =?us-ascii?Q?kjQHhHqH+f41kvoOtNLukN5RXAO1ayfqetFzyW6P4FQ2BHwN3iIpGZ06XB8r?= =?us-ascii?Q?eda8wQdtu3W3/6Kua/xei8ycfjo+4WGucNsBO1mPxvdZyrc/4UjE+u9cicFM?= =?us-ascii?Q?SKIB6rEBTn7UlC+6SIPBa3KzKwlqjtY3TkkUTK5p124za4c84H6z0CHrHp2U?= =?us-ascii?Q?cs8AGbcKbpE76HE4pZvkoKThicsF4P2D3d/in8bFEVwSi9Gr9cX2NS9pa2jz?= =?us-ascii?Q?SWTZGxMzYz5PeBx/Uue6iUpythpxFc2SLu5GPfiIDB0Ke8TL4QcySNj7TqaY?= =?us-ascii?Q?B5ecqyq+WzQVkYN4+UKWxi/4eisPvpLxuZGl2auqeR0Bsqzmh0InpEhAEmzf?= =?us-ascii?Q?89lv3RoIJL0G0xmTpe9W7b6Tkl9HCq4KN+L6uZjnykG4B8XrXqHHDmxvDOA5?= =?us-ascii?Q?3v4zza/8/wZb0VH5e+DjE0dRqeU9sSfaT5OViD7N/Qpo9MWqE6rRmdf9lZlu?= =?us-ascii?Q?jGoTWQz2hIJDftJARqt90EWGDs8Fn9dGJVkxyyqPb2UFEZmiXnMQ6Vh9nUAe?= =?us-ascii?Q?TtdK5v8wJagvkaahLOLHKYxc7097jQ/5CKcfBgTq8akqG8V7zQNwe6R4xKk5?= =?us-ascii?Q?gHniqryqaZJu3wgHKBdrYWPmdUbHBStQWyHDVF7wKvsSNetyoa0+ZIpZXzif?= =?us-ascii?Q?GNFOfp9c7VzesJXd5PAETRijidyauc9j5b+0NRyPVGnsSiIpriXGBwzsR26b?= =?us-ascii?Q?FXQM2Di3OcWYRqityET4uofVPxF5SG2K2LnRgWCL6rSiE5/DnZsg6RnCLPuy?= =?us-ascii?Q?ZcpmMLbZ03US30SYmG6q3r2drHNRoamkf0lJcuDWsBVsGn74aFBxxvFX4x0Z?= =?us-ascii?Q?YxlpMSJRuyJ9VnrzyBpX25B6KxKQ5b7THBp4HNWeZ0XZeOw+SSXOEx/qwMqP?= =?us-ascii?Q?motVLzzuBbz8VzKVXxHO5VwGpfF8IA5hVC1gajy17rNanqCmg1kyUM+nLVBn?= =?us-ascii?Q?7SbdFjyXxhly4g4qNJHg+GtZ9us9M0AnRpDceNxXdPz2djZrozbtj55e8pM+?= =?us-ascii?Q?Jkv6zrwxWCh/pjdbiLw5u0zsxqpP2Z0xoguSbFWVd99icP0MHpzk5sfLwqSP?= =?us-ascii?Q?uxpNVliuBXC4yENvdlfDoR9kGmd049EjcZbSbTjv94u3kaqE8H75V9VRYwt/?= =?us-ascii?Q?BwyVxpVc1+s/UQQlj4DO88NMrSDyC0SRH2+Ip1jz1tr/O4ZG/dVoZAz9sHIk?= =?us-ascii?Q?5gCr756g+zV9JSrCgQYivMQE49S36om5BnEDauWmg3fYQuhyl4Y1pGpbIE7A?= =?us-ascii?Q?sSBipqfoPS7MYSLuThaembosokXouxE2fHJDQknpX1brND3B3gUBJzN555d3?= =?us-ascii?Q?PtipAJlTlMxtZReWmj+RMeRDh67+rOT8zubUWCKaKTlEOdCk5W5bUHBqgnlC?= =?us-ascii?Q?79BHXgc36t+UCCyvhIuliVlodhhbkkly//NBqgQol3WvgW9DNlQeHyfEeESv?= =?us-ascii?Q?0aZ2P9uzfA8YI1ewAMaDkh1TSLn9GoqE8dVDZhDqQI1ipTM6MMKZ/8WNh9ud?= =?us-ascii?Q?2dLtKP/dpFvr91n32JKk7f/d5VLupG9MCH2ebpdSdKvnLKcCPRaumsipn+on?= =?us-ascii?Q?juxkx/fwhdKMCHkth6nanZKcyPpTT+Lji0YPZMj0rzUuDBr1crqFrBcKbcL/?= =?us-ascii?Q?S+RAg6Q/zQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_MW2PR07MB40580B41FABAB9BA1A7D1371D2AF9MW2PR07MB4058namp_" Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-OriginatorOrg: openeye.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW2PR07MB4058.namprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 22a5e073-86ef-414b-7234-08da500149f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2022 01:32:49.1561 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 01aaba89-c0e5-4a25-929f-061e1350d674 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pXc3ZNuXn7DLTAMNt9/uiYpeQKQENfjg9h5PLurIyOUfnIVHlRgO5jVVZokNygmmVIp1NquZqPJ5/npb0KZqYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0701MB3715 X-Archives-Salt: 67f6b5ba-6666-4f02-94c7-55a22a27c9fd X-Archives-Hash: 1d0159ac178edf863d91d257b0f88b22 --_000_MW2PR07MB40580B41FABAB9BA1A7D1371D2AF9MW2PR07MB4058namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am designing a small system with a switch and an uplink. It needs to be = able to forward traffic from trusted, and only trusted, devices connected t= o the switch out through the uplink. Since all potential trusted devices will have the same MAC OUI prefix in th= is case, the immediately obvious course of action would be to base the deci= sion on that. Unfortunately, there doesn't seem to be a good way to do so. There was htt= ps://serverfault.com/questions/877576/shorewall-wildcard-filter-by-source-m= ac-address from a few years ago, with the answer being "You can't." While I didn't bother to test it, I'm guessing that adding about 16 million= MAC filtering rules to the firewall won't be good for performance. I brie= fly thought I could use the string matching or the U32 filters, but unfortu= nately it appears that they can't access anything prior to the start of the= IP section, so picking bytes out of the ethernet header isn't possible. I did find https://martin.uy/blog/wildcard-support-for-mac-addresses-in-net= filter-linux-kernel-and-iptables/ But it's old, and has something of a gl= aring flaw with regard to false wildcard matches. I can think of a few ways to do this, mostly involving somehow monitoring i= ncoming packets and noting the MAC addresses which have the correct prefix,= and then having a little daemon pick up those addresses and add rules to l= et them through. Either that, or try to write a custom netfilter module. None of this seems particularly "fun" to sort out. Does anybody know of an= y common solutions for doing packet matching based on just part of a MAC ad= dress on Linux? Failing that, some advice about whether the system daemon = and packet inspection route or the netfilter module route is more likely to= be stable and maintainable would be appreciated. Thanks, LMP --_000_MW2PR07MB40580B41FABAB9BA1A7D1371D2AF9MW2PR07MB4058namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am designing a small system with a switch and an u= plink.  It needs to be able to forward traffic from trusted, and only = trusted, devices connected to the switch out through the uplink.=

 

Since all potential trusted devices will have the sa= me MAC OUI prefix in this case, the immediately obvious course of action wo= uld be to base the decision on that.

 

Unfortunately, there doesn't seem to be a good way t= o do so.  There was https://serverfault.com/questions/877576/shorewall-wildcard-filter-by-sourc= e-mac-address from a few years ago, with the answer being "You can= 't."

 

While I didn't bother to test it, I'm guessing that = adding about 16 million MAC filtering rules to the firewall won't be good f= or performance.  I briefly thought I could use the string matching or = the U32 filters, but unfortunately it appears that they can't access anything prior to the start of the IP section, so p= icking bytes out of the ethernet header isn't possible.

 

I did find https://martin.uy/blog/wildcard-support-for-mac-addresses-in-netfilter-linu= x-kernel-and-iptables/   But it's old, and has something of a= glaring flaw with regard to false wildcard matches.

 

I can think of a few ways to do this, mostly involvi= ng somehow monitoring incoming packets and noting the MAC addresses which h= ave the correct prefix, and then having a little daemon pick up those addre= sses and add rules to let them through.

 

Either that, or try to write a custom netfilter modu= le.

 

None of this seems particularly "fun" to s= ort out.  Does anybody know of any common solutions for doing packet m= atching based on just part of a MAC address on Linux?  Failing that, s= ome advice about whether the system daemon and packet inspection route or the netfilter module route is more likely to be stable= and maintainable would be appreciated.

 

Thanks,

LMP

--_000_MW2PR07MB40580B41FABAB9BA1A7D1371D2AF9MW2PR07MB4058namp_--