Block traffic to/from host from one side of a bridge

If I have two ethernet interface eth0 and eth1. They are bridged (br0). The host running the bridge can communicate with the network using any of eth0 or eth1 depending on wich are connected to the network.

Now to the question:

How can I prevent the host to communicate with the network through eth1?

What I would like to accomplish:

eth0 <-> br0: Accepted.
eth1 <-> br0: Rejected.
eth0 <-> eth1: Accepted.

Before saying that this is not possible and does not fit the OSI model you need to check out the following: br_netfilter (kernel module), net.bridge.bridge-nf-call-iptables and transparent firewalling: https://www.debian.org/doc/manuals/securing-debian-manual/bridge-fw.en.html

I already filter packages based on layer 3 in the bridge ( eth0 <-> eth1 ). What is left to do is to prevent the firewall it self communicating with the network on the wrong side of the firewall.

The nftables solution described in one of the comments is great and that is the way to go later but right now i need a quick fix that works until I have upgraded the platform and converted the application to use nftables.

Acceptable solutions to this question are based on iptables (preferably) or ebtables (i need to investigate this one, but it is for now a quicker way than nftables to solve this problem).

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.

I'm sorry but the question needs more explanation as it does not make sense at this time.

By joining eth0 and eth1 to br0 you have created a 2 port ethernet switch.

What you would like to accomplish:

eth0 <-> br0: Accepted.
eth1 <-> br0: Rejected.
eth0 <-> eth1: Accepted.

would be possible if you delete eth1 from the br0 and allow packet forwarding in kernel for eth0 and eth1.

iptables deal with IP addresses - i.e. layer 3 (network) in OSI model - therefore are not usable in this scenario.

You are talking about switching frames so layer 2 (link) in OSI model - therefore you need to consult ebtables to do any advanced filtering.

Links for your reference:

https://linux.die.net/man/8/ebtables

Is it possible to use ebtables to filter traffic by MAC-addresses on simple ethernet interface, without bridging?