Firewall
One can use firewall rules at the Ethernet bridge level to implement OP's restrictions.
A Linux bridge has a special "self" port with the name of the bridge. The bridge as a whole participates in forwarding frames at L2 between (interfaces set as bridge-) ports but the bridge self port participates in routing packets at L3 like other interfaces. Compare this with a simple managed switch: it has ports, but can also be reached for management purposes over IP: such IP packets can reach it from any port (still as Ethernet frames) but are then sent to the switch itself rather than forwarded to an other port.
For the Netfilter firewall framework used by nftables and ebtables, this is translated by having the bridge-port to bridge-port traffic seen in the filter forward hook (filter/FORWARD chain for ebtables). Traffic from the self port to an other port is the filter output hook (filter/OUTPUT chain) and traffic from a port to the bridge self port is the filter input hook (filter/INPUT chain). This schematic describes it in the Link Layer (blue boxes in the lower blue field) part.
So here the traffic to block is between eth1
and the self interface (ie block further processing to the routing stack) and the other way around.
I'll assume there's only one bridge here. Now these tools were presented, more investment should be done to use them properly, especially in case of multiple bridges. Anyway the commands below will always work properly since eth1
can be the port of only one bridge at a time: here br0
.
Using ebtables:
ebtables -A INPUT -i eth1 -j DROP
ebtables -A OUTPUT -o eth1 -j DROP
There's no mention of br0
: it's represented by INPUT
and OUTPUT
.
As the various defaults are still to accept traffic, eth0
won't be blocked with br0
, nor traffic between eth0
and eth1
.
Using (recent enough to avoid syntax errors) nftables: it's the same with the initial boilerplate to add:
nft add table bridge mytable
nft add chain bridge mytable myinput '{ type filter hook input priority filter; policy accept; }'
nft add chain bridge mytable myoutput '{ type filter hook input priority filter; policy accept; }'
nft add rule bridge mytable myinput iif eth1 drop
nft add rule bridge mytable myoutput oif eth1 drop
Note
iptables is not used at the Ethernet layer (L2), but at the IP layer (L3) so is not the adequate tool for this. Arguably there's also a special feature called bridge netfilter that will convert Ethernet frames of type IPv4 to push artificial IP packets to iptables (still in the bridge path) so they can be processed and then will convert back those packets into Ethernet frames for further processing by ebtables. It would allow to use iptables
to do such filtering if one follows and understands correctly the handling of the green boxes (network level: packets) in the lower blue field (Link Layer: Ethernet) in the previous schematic , but it would most likely result in additional unwanted effects. Don't use this feature (nor experiment anything on a system already running Docker) before understanding what can break.