From fe31630f09c6c927432844b0d829d13c36c76b68 Mon Sep 17 00:00:00 2001
From: Bart De Schuymer
- There are five hooks defined in the Linux bridging code.
- The sixth hook (BROUTING) is added by the ebtables patch.
+ There are six hooks defined in the Linux bridging code, of which the
+ BROUTING hook was added for ebtables.
Getting a bridging firewall consists of patching the kernel source
- code with one or two patches.
- Kernels 2.5.39 and above only need the "br-nf-bds" patch, since ebtables has been integrated in the 2.5.x series.
- For other kernels, you need to first apply the patch that adds ebtables support in the kernel.
- The "br-nf-bds" patch makes bridged IP frames/packets go through the iptables chains.
+ code with one or two patches. Since kernel 2.5.39 (resp. 2.5.44), ebtables (resp. br-nf)
+ is in the standard 2.5 kernel releases.
+ Because the demand was high, patches for the 2.4 kernel are still available at the ebtables homepage.
+ The br-nf code makes bridged IP frames/packets go through the iptables chains.
Ebtables filters on the Ethernet layer, while iptables
only filters IP packets.
The explanations below will use the TCP/IP Network Model.
- It should be noted that the br-nf-bds patch sometimes violates the
+ It should be noted that the br-nf code sometimes violates the
TCP/IP Network
Model. As will be seen later, it is possible, f.e., to do IP DNAT inside the Link Layer.
We want to note that we are perfectly well aware that the word frame is used for the Link Layer,
@@ -111,8 +111,8 @@
@@ -251,7 +251,7 @@
decision, so this is actually too late. We should change this. The nat
POSTROUTING chain is the same one as described above.
@@ -289,23 +289,25 @@ Note that the iptables nat OUTPUT chain is situated after the routing decision. As commented in the previous section, this is too late for DNAT. This is solved by rerouting the - IP packet if it has been DNAT'ed, before continuing. + IP packet if it has been DNAT'ed, before continuing. For clarity: + this is standard behaviour of the Linux kernel, not something + caused by our code.
Figures 3a and 3b give a clear view where the
iptables chains are attached onto the IP hooks. When the
- br-nf-bds patch is compiled into the kernel, the iptables chains are
+ bridge code and netfilter is enabled in the kernel, the iptables chains are
also attached onto the hooks of the bridging code. However,
this does not mean that they are no longer attached onto their
standard IP code hooks. For IP packets that get into
- contact with the bridging code, the br-nf-bds patch will
+ contact with the bridging code, the br-nf code will
decide in which place in the network code the iptables
- chains are traversed. Obviously, it is guaranteed that no chain is
+ chains will be traversed. Obviously, it is guaranteed that no chain is
traversed twice by the same packet. All packets that do not come into
contact with the bridge code traverse the iptables chains
in the standard way as seen in Figure 3b.
The following sections try, among other things,
- to explain what the br-nf-bds patch does and why it does it.
+ to explain what the br-nf code does and why it does it.
It's possible to see a single IP packet/frame traverse the @@ -315,8 +317,7 @@ The Ethernet frame(s) containing that IP packet will have the bridge's destination MAC address, while the destination IP address is not of the bridge. Including the - iptables chains and assuming the br-nf-bds code is - compiled into the kernel, this is how the IP packet runs + iptables chains, this is how the IP packet runs through the bridge/router (actually there is more going on, see section 6):
@@ -344,7 +345,7 @@ What is obviously "asymmetric" here is that the iptables PREROUTING chain is traversed before the ebtables INPUT chain, however this cannot be - helped without sacrificing other functionality. See the + helped without sacrificing functionality. See the next section. @@ -352,7 +353,7 @@ 4. DNAT'ing bridged packets
- Take an IP packet received by the bridge. Let's assume we
+ Take an IP packet received by the bridge. Let's assume we
want to do some IP DNAT on it.
Changing the destination address of the packet (IP address
and MAC address) has to happen before the bridge code
@@ -366,9 +367,9 @@
This should explain the asymmetry encountered in Figures 3c
and 3d.
One should also be aware of the fact that frames for which the
- bridging decision would be the fourth from the above list will
- be seen in the PREROUTING chains of ebtables and
- iptables.
+ bridging decision would be the fourth from the above list (i.e.
+ ignore the frame) will be seen in the PREROUTING chains of
+ ebtables and iptables.
@@ -402,7 +403,7 @@ knowing when a box on the eth0 side changes its source IP address to that of a box on the eth1 side, except by looking at the MAC source address (and then still...). With - the br-nf-bds patch you can use eth0 and eth1 in your + the br-nf code you can use eth0 and eth1 in your iptables rules and therefore catch these attempts.
@@ -422,34 +423,15 @@
- Figure 6a. Chain traversal when routing and br-nf-bds
- is compiled into the kernel
+ Figure 6a. Chain traversal for routing, when the bridge
+ and netfilter code are compiled in the kernel.
- If one does not compile the br-nf-bds code into the kernel, the - chains will be traversed as shown below. However, then one - can only use br0, not eth0/eth1 to filter. -
-- -
-
- Figure 6b. Chain traversal when routing and br-nf-bds
- code is not compiled into the kernel
-
- Notice that the iptables PREROUTING chain is now in - the natural position in the chain list and too far to be able - to change the bridging decision. More precise: the iptables - PREROUTING chain is now traversed when the packet is already - in the IP code. -
6.2. IP DNAT for locally generated packets (so in the iptables nat OUTPUT chain): @@ -467,7 +449,7 @@
From section 6.1 we know that this - actually looks like this (due to the br-nf-bds code): + actually looks like this (due to the br-nf code):
@@ -491,7 +473,7 @@ chains
- With the br-nf-bds patch there are 2 ways a frame/packet can + Because of the br-nf code, there are 2 ways a frame/packet can pass through the 3 given iptables chains. The first way is when the frame is bridged, so the iptables chains are called by the bridge code. The @@ -548,7 +530,7 @@ echo '1' > /proc/sys/net/ipv4/ip_forward
The catch is in the first line. Because the iptables code gets executed for both bridged - packets and routed packets we need to make a distinction + packets and routed packets, we need to make a distinction between the two. We don't really want the bridged frames/packets to be masqueraded. If we omit the first line then everything will work too, but things will happen @@ -587,8 +569,8 @@ echo '1' > /proc/sys/net/ipv4/ip_forward 9. Using the MAC module extension for iptables
- The side effect explained here occurs when the br-nf-bds code - is compiled in the kernel, the IP packet is routed and the + The side effect explained here occurs when the netfilter code + is enabled in the kernel, the IP packet is routed and the out device for that packet is a logical bridge device. The side effect is encountered when filtering on the MAC source in the iptables FORWARD chains. As should be clear @@ -607,9 +589,7 @@ echo '1' > /proc/sys/net/ipv4/ip_forward to filter on the real MAC source address in the FORWARD chains would involve a very dirty hack and is probably not worth it. This of course makes the anti-spoofing remark of - section 6 funny. If I'm [BDS] - pressured enough I could hack something up to make this - unpleasant side effect go away. + section 6 funny.
@@ -641,7 +621,7 @@ Copyright (c) 2002 Bart De Schuymer <bart.de.schuymer@pandora.be>,
"http://www.gnu.org/licenses/fdl.txt">"GNU Free Documentation License".
- Last updated November 03, 2002. + Last updated December 23, 2002.