From fe31630f09c6c927432844b0d829d13c36c76b68 Mon Sep 17 00:00:00 2001 From: Bart De Schuymer Date: Mon, 23 Dec 2002 21:16:56 +0000 Subject: include fact that it's in 2.5 --- docs/br_fw_ia/br_fw_ia.html | 84 +++++++++++++++++---------------------------- 1 file changed, 32 insertions(+), 52 deletions(-) (limited to 'docs') diff --git a/docs/br_fw_ia/br_fw_ia.html b/docs/br_fw_ia/br_fw_ia.html index 6b05d50..f338d50 100644 --- a/docs/br_fw_ia/br_fw_ia.html +++ b/docs/br_fw_ia/br_fw_ia.html @@ -66,14 +66,14 @@ This document describes how iptables and ebtables filtering tables interact on a Linux-based bridge.
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 @@

- 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.



@@ -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.

All chains are now traversed while in the bridge code.
- This is the work of the br-nf-bds patch. Obviously this does not + This is the work of the br-nf code. Obviously this does not mean that the routed IP packets never enter the IP code. They just don't pass any iptables chains while in the IP code.
-

- 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.

-- cgit v1.2.3