lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <ZT9rkYsR0F3M+IxU@Laptop-X1> Date: Mon, 30 Oct 2023 16:38:41 +0800 From: Hangbin Liu <liuhangbin@...il.com> To: Florian Westphal <fw@...len.de> Cc: netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>, David Ahern <dsahern@...nel.org>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Ido Schimmel <idosch@...sch.org>, Nikolay Aleksandrov <razor@...ckwall.org>, Roopa Prabhu <roopa@...dia.com>, Stephen Hemminger <stephen@...workplumber.org>, netfilter-devel@...r.kernel.org Subject: Re: [RFC Draft PATCHv2 net-next] Doc: update bridge doc Thanks Florian, very appreciate for your comments. I'm not familiar with the bridge netfilter history and usage. I will summary and update the doc with your comments in next version(with the other's comments). Hope you could review it again. Regards Hangbin On Fri, Oct 27, 2023 at 02:31:30PM +0200, Florian Westphal wrote: > Hangbin Liu <liuhangbin@...il.com> wrote: > > [ cc nf-devel ] > > > The current bridge kernel doc is too old. It only pointed to the > > linuxfoundation wiki page which lacks of the new features. > > Indeed, thanks for taking time to improve the documention. > > > +Netfilter > > +========= > > + > > +The bridge netfilter module allows packet filtering and firewall functionality > > +on bridge interfaces. As the Linux bridge, which traditionally operates at > > +Layer 2 and connects multiple network interfaces or segments, doesn't have > > +built-in packet filtering capabilities. > > No, this is not what this module does. br_netfilter module should NEVER > be used. I'd love to remove it, but its very popular unfortunately. > > Suggestion: > > The bridge netfilter module is a legacy feature that allows to filter bridged > packets with iptables and ip6tables. Its use is discouraged. Users > should consider using nftables for packet filtering. > > The older ebtables tool is more feature-limited compared to nftables, but > just like nftables it doesn't need this module either to function. > > The br_netfilter module intercepts packets entering the bridge, performs > minimal sanity tests on ipv4 and ipv6 packets and then pretends that > these packets are being routed, not bridged. br_netfilter then calls > the ip and ipv6 netfilter hooks from the bridge layer, i.e. ip(6)tables > rulesets will also see these packets. > > br_netfilter is also the reason for the iptables 'physdev' match: > This match is the only way to reliably tell routed and bridged packets > apart in an iptables ruleset. > > Side note: > > You might want to somehow massage the bits below, perhaps it would be > good to have the historical context as to why br_netfilter exists in the > first place. > > > +With bridge netfilter, you can define rules to filter or manipulate Ethernet > > +frames as they traverse the bridge. These rules are typically based on > > +Ethernet frame attributes such as MAC addresses, VLAN tags, and more. > > +You can use the *ebtables* or *nftables* tools to create and manage these > > +rules. *ebtables* is a tool specifically designed for managing Ethernet frame > > +filtering rules, while *nftables* is a more versatile framework for managing > > +rules that can also be used for bridge filtering. > > ebtables and nftables will work fine without the br_netfilter module. > > iptables/ip6tables/arptables do not work for bridged traffic because they > plug in the routing stack. > > nftables rules in ip/ip6/inet/arp families won't see traffic that is > forwarded by a bridge either, but thats very much how it should be. > > br_netfilter is only needed if users, for some reason, need to use > ip(6)tables to filter packets forwarded by the bridge, or NAT bridged > traffic. > > Historically the feature set of ebtables was very limited (it still is), > so this module was added to pretend packets are routed and invoke the > ipv4/ipv6 netfilter hooks from the bridge so users had access to the > more feature-rich iptables matching capabilities (including conntrack). > > nftables doesn't have this limitation, pretty much all features work > regardless of the protocol family. > > > +The bridge netfilter is commonly used in scenarios where you want to apply > > +security policies to the traffic at the data link layer. This can be useful > > +for segmenting and securing networks, enforcing access control policies, > > +and isolating different parts of a network. > > See above, for pure link layer filtering, this module isn't needed.
Powered by blists - more mailing lists