Packet filtering in bridge (iptables,ebtables)

Question

linux

The question is primarily addressed to Linux system administrators.
There is a PowerPC-based router board that runs under the OpenWRT (Linux) operating system. This board has only two network interfaces eth0 and eth1, combined into a network bridge.

[email protected]:/# brctl show
bridge name bridge id STP enabled interfaces
br-br0 8000.7e0410820000 no eth0
                                                        eth1

The task is to filter packets by IP address (namely, only by IP address!). So that only some computers on one network can see computers on the other. On the one hand, the task is trivial (to use iptables), but in fact it turned out to be non-trivial ...

To check the correctness of the settings, a computer with an IP address of 192.168. eth1). For convenience, the router itself has an IP address of 192.168.1.2.

So, I use ping as a test. Plus, I additionally use the local network of the enterprise as a “background” to check packet filtering. I ping both computers (each other), the router, and computers from the router - pings go. We look at tcpdump on the router and computers - packets are walking around the network. Now let's close up, and here the fun begins!

[email protected]:/# iptables -F
[email protected]:/# iptables -P INPUT DROP
[email protected]:/# iptables -P OUTPUT DROP
[email protected]:/# iptables -P FORWARD DROP
[email protected]:/#


It would seem , after that, silence should come in the network and no one should see or hear anyone, except for a computer that is on the same network as the enterprise. But no! Attention:
1. The router does not ping and does not ping computers, i.e. rules INPUT, OUTPUT DROP worked!
2. Computers see each other, ping and packets freely roam the network. This is seen by tcpdump on all computers except the router. This means that the FORWARD DROP rule for end-to-end traffic does not work!
Why is that, I don't know!

Let's go further. There is a firewall specifically for the bridge called ebtables . Its main drawback is that it is more low-level, and is at the channel level. The main filtering is based on MAC addresses. The syntax is similar to iptables. So let's try:

[email protected]:/# ebtables -F
[email protected]:/# ebtables -P FORWARD DROP


And that's it, the transmission is closed. You can open shapanskoe and celebrate the victory. But now we need to allow transmission from the computer with the address 192.168.1.10 to the computer 192.168.1.11 and vice versa. At the same time, it is not tied to MAC addresses. I tried this rule:
ebtables -A FORWARD -p ipv4 --ip-dst 192.168.1.11 --ip-source 192.168.1.10 -j ACCEPT
ebtables -A FORWARD -p ipv4 --ip-dst 192.168.1.10 -- ip-source 192.168.1.11 -j ACCEPT


But the miracle did not happen ... Computers did not hear, and do not hear each other. I pinch my hair, I read mana, but I don’t know what to do and how to do it. The question is generally simple, but the solution is not obvious.

Now the questions are:
1. Why didn't I manage to filter passing traffic using iptables?
2. Is it possible to configure packet filtering using ebtables by IP address, without being tied to the MAC? If possible, how?
3. Is it possible to have ebtables pass traffic filtering rules to iptables?

I don't get kicked a lot, I'm just starting to deal with it. I am not a system administrator, but the piece of iron that is being made will be used for routing and filtering, so I have to figure it out and smoke.

Answer 1

1. In order to be able to filter traffic passing through the bridge using iptables, you must set the following sysctl system variables:

net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1

2. Once you have your sysctl variables set, you can use iptables to do this using match -m physdev --physdev-in / --physdev-out
3. See previous answer.
Something like this.

Answer 2

And so, a detailed test report.
From the iron, a couple of voice gateways were at hand, which will be used as end devices (addresses 192.168.253.1 and 192.168.253.2), and a managed switch. We push each of the addpacks into a separate vlan, configure the binding of ports to vlans on the switch and start the experiment.
1. We create a bridge interface and two vlans on a typewriter, push the vlans into the bridge, raise everything, write the address on the bridge interface:

brctl addbr br0
ip l add l eth2 name eth2.10 type vlan id 10
ip l add l eth2 name eth2.11 type vlan id 11
ip l s up dev br0
ip l s up dev eth2.10
ip l s up dev eth2.11
ip a add 192.168.253.3/29 dev br0

2. Set the sysctl variables, there will be no filtering:

sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-filter-vlan-tagged=0

3. We check the connectivity between devices in different ports of the bridge and the host machine (we ping the other addresses from the addpack 192.168.253.1/29):

test-addpac-1# ping 192.168.253.2
PING 192.168.253.2 (192.168.253.2): 56 data bytes
64 bytes from 192.168.253.2: icmp_seq=0 ttl=64 time=10 ms
64 bytes from 192.168.253.2: icmp_seq=1 ttl=64 time=10 ms
64 bytes from 192.168.253.2: icmp_seq=2 ttl=64 time=10 ms
64 bytes from 192.168.253.2: icmp_seq=3 ttl=64 time=10 ms

--- 192.168.253.2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss'
round-trip min/avg/max = 10/10/10 ms
test-addpac-1# ping 192.168.253.3
PING 192.168.253.3 (192.168.253.3): 56 data bytes
64 bytes from 192.168.253.3: icmp_seq=0 ttl=64 time=15 ms
64 bytes from 192.168.253.3: icmp_seq=1 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=2 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=3 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=4 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=5 ttl=64 time=5 ms

--- 192.168.253.3 ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss'
round-trip min/avg/max = 5/6/15 ms

As you can see, everything works.
4. Set a variable so that traffic between ports gets into iptables, and add a rule to the firewall to block traffic between two devices with given addresses:

sysctl -w net.bridge.bridge-nf-call-iptables=1
iptables -A FORWARD \
  --src 192.168.253.1 --dst 192.168.253.2 \
  -j DROP

And we also check with the help of ping:

test-addpac-1# ping 192.168.253.2 
PING 192.168.253.2 (192.168.253.2): 56 data bytes

--- 192.168.253.2 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss'
test-addpac-1# ping 192.168.253.3
PING 192.168.253.3 (192.168.253.3): 56 data bytes
64 bytes from 192.168.253.3: icmp_seq=0 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=1 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=2 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=3 ttl=64 time=5 ms
64 bytes from 192.168.253.3: icmp_seq=4 ttl=64 time=5 ms

--- 192.168.253.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss'
round-trip min/avg/max = 5/5/5 ms

And check the counters in iptables (in the dynamics you will see how they increment):

[email protected]:~$ sudo iptables -L FORWARD 8 -n -v
  455 38220 DROP  all  --  *  *   192.168.253.1  192.168.253.2 

In summary: this is how you can filter traffic between bridge ports, completely without ebtables. To filter traffic between ports based on the interface, you need to use the physdev extension like this:

iptables -A FORWARD -m physdev \
  --physdev-in eth2.10 --physdev-out eth2.11 \
  --src 192.168.253.1 --dst 192.168.253.2 \
  -j DROP

It should also be noted that ebtables can also filter by L3 header fields if the corresponding modules are loaded.
You can do the same with ebtables:

ebtables -A FORWARD -p ip \
--ip-source 192.168.253.1 --ip-destination 192.168.253.2 \
-j DROP

As you can see, for filtering, you do not need to specify poppy addresses at all. You can find detailed information about ebtables modules in the mana. It will also be useful to play around with tcpdump on bridges and bridge ports when filtering - you will see that traffic comes to one port of the bridge, but is not forwarded to another port.

Answer 3

You have to understand the levels at which iptables and ebtables work - this is the time.
in the bridge (L2) - you need to work with MAC addresses.