Linux桥防火墙.docx

1、Linux桥防火墙ebtables/iptables interaction on a Linux-based bridge（网桥式防火墙）跨越了TCP/IP模型，可在链路层实现 IP NAT 与 MAC NAT功能。 ebtables/iptables interaction on a Linux-based bridge Table of Contents 1. Introduction 2. How frames traverse the ebtables chains 3. A machine used as a bridge and a router (not a brouter)

2、4. DNATing bridged packets 5. Chain traversal for bridged IP packets 6. Using a bridge port in iptables rules 7. Two possible ways for frames/packets to pass through the iptables PREROUTING, FORWARD and POSTROUTING chains 8. IP DNAT in the iptables PREROUTING chain on frames/packets entering on a br

3、idge port 9. Using the MAC module extension for iptables 10. Using the iptables physdev match module for kernel 2.6 11. Detailed IP packet flow 1. Introduction This document describes how iptables and ebtables filtering tables interact on a Linux-based bridge. Getting a bridging firewall on a 2.4.x

4、kernel consists of patching the kernel source code. The 2.6 kernel contains the ebtables and br-nf code, so it doesnt have to be patched. 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 th

5、e 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 code sometimes violates the TCP/IP Network Model. As will be seen later, it is possible, f.e., to do IP DNAT

6、inside the Link Layer. We want to note that we are perfectly well aware that the word frame is used for the Link Layer, while the word packet is used for the Network Layer. However, when we are talking about IP packets inside the Link Layer, we will refer to these as frames/packets or packets/frames

7、. 2. How frames traverse the ebtables chains This section only considers ebtables, not iptables. First thing to keep in mind is that we are talking about the Ethernet layer here, so the OSI layer 2 (Data link layer), or layer 1 (Link layer, Network Access layer) by the TCP/IP Network Model. A packet

8、 destined for the local computer according to the bridge (which works on the Ethernet layer) isnt necessarily destined for the local computer according to the IP layer. Thats how routing works (MAC destination is the router, IP destination is the actual box you want to communicate with). Figure 2a.

9、General frame traversal scheme There are six hooks defined in the Linux bridging code, of which the BROUTING hook was added for ebtables. Figure 2b. Ethernet bridging hooks The hooks are specific places in the network code on which software can attach itself to process the packets/frames passing tha

10、t place. For example, the kernel module responsible for the ebtables FORWARD chain is attached onto the bridge FORWARD hook. This is done when the module is loaded into the kernel or at bootup. Note that the ebtables BROUTING and PREROUTING chains are traversed before the bridging decision, therefor

11、e these chains will even see frames that will be ignored by the bridge. You should take that into account when using this chain. Also note that the chains wont see frames entering on a non-forwarding bridge port. The bridges decision for a frame (as seen on Figure 2b) can be one of these: 12. bridge

12、 it, if the destination MAC address is on another side of the bridge; 13. flood it over all the forwarding bridge ports, if the position of the box with the destination MAC is unknown to the bridge; 14. pass it to the higher protocol code (the IP code), if the destination MAC address is that of the

13、bridge or of one of its ports; 15. ignore it, if the destination MAC address is located on the same side of the bridge. Figure 2c. Bridging tables (ebtables) traversal process Ebtables has three tables: filter, nat and broute, as shown in Figure 2c. 16. The broute table has the BROUTING chain. 17. T

14、he filter table has the FORWARD, INPUT and OUTPUT chains. 18. The nat table has the PREROUTING, OUTPUT and POSTROUTING chains. The filter OUTPUT and nat OUTPUT chains are separated and have a different usage. Figures 2b and 2c give a clear view where the ebtables chains are attached onto the bridge

15、hooks. When an NIC enslaved to a bridge receives a frame, the frame will first go through the BROUTING chain. In this special chain you can choose whether to route or bridge frames, enabling you to make a brouter. The definitions found on the Internet for what a brouter actually is differ a bit. The

16、 next definition describes the brouting ability using the BROUTING chain quite well: A brouter is a device that bridges some frames/packets (i.e. forwards based on Link layer information) and routes other frames/packets (i.e. forwards based on Network layer information). The bridge/route decision is

17、 based on configuration information. A brouter can be used, for example, to act as a normal router for IP traffic between 2 networks, while bridging specific traffic (NetBEUI, ARP, whatever) between those networks. The IP routing table does not use the bridge logical device, instead the box has IP a

18、ddresses assigned to the physical network devices that also happen to be bridge ports (bridge enslaved NICs). The default decision in the BROUTING chain is bridging. Next the frame passes through the PREROUTING chain. In this chain you can alter the destination MAC address of frames (DNAT). If the f

19、rame passes this chain, the bridging code will decide where the frame should be sent. The bridge does this by looking at the destination MAC address, it doesnt care about the Network Layer addresses (e.g. IP address). If the bridge decides the frame is destined for the local computer, the frame will

20、 go through the INPUT chain. In this chain you can filter frames destined for the bridge box. After traversal of the INPUT chain, the frame will be passed up to the Network Layer code (e.g. to the IP code). So, a routed IP packet will go through the ebtables INPUT chain, not through the ebtables FOR

21、WARD chain. This is logical. Figure 2d. Incoming frames chain traversal Otherwise the frame should possibly be sent onto another side of the bridge. If it should, the frame will go through the FORWARD chain and the POSTROUTING chain. The bridged frames can be filtered in the FORWARD chain. In the PO

22、STROUTING chain you can alter the MAC source address (SNAT). Figure 2e. Forwarded frames chain traversal Locally originated frames will, after the bridging decision, traverse the nat OUTPUT, the filter OUTPUT and the nat POSTROUTING chains. The nat OUTPUT chain allows to alter the destination MAC ad

23、dress and the filter OUTPUT chain allows to filter frames originating from the bridge box. Note that the nat OUTPUT chain is traversed after the bridging decision, so this is actually too late. We should change this. The nat POSTROUTING chain is the same one as described above. Figure 2f. Outgoing f

24、rames chain traversal Its also possible for routed frames to go through these three chains when the destination device is a logical bridge device. 3. A machine used as a bridge and a router (not a brouter) Here is the IP code hooks scheme: Figure 3a. IP code hooks Here is the iptables packet travers

25、al scheme. Figure 3b. Routing tables (iptables) traversal process Note that the iptables nat OUTPUT chain is situated after the routing decision. As commented in the previous section (when discussing ebtables nat), this is too late for DNAT. This is solved by rerouting the IP packet if it has been D

26、NATed, 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 bridge code and netfilter is enabled in the kernel, the iptables chains are

27、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 code will decide in which place in the network code the iptables chains will be tr

28、aversed. 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 co

29、de does and why it does it. Its possible to see a single IP packet/frame traverse the nat PREROUTING, filter INPUT, nat OUTPUT, filter OUTPUT and nat POSTROUTING ebtables chains. This can happen when the bridge is also used as a router. The Ethernet frame(s) containing that IP packet will have the b

30、ridges destination MAC address, while the destination IP address is not of the bridge. Including the iptables chains, this is how the IP packet runs through the bridge/router (actually there is more going on, see section 6): Figure 3c. Bridge/router routes packet to a bridge interface (simplistic vi

31、ew) This assumes that the routing decision sends the packet to a bridge interface. If the routing decision sends the packet to non-bridge interface, this is what happens: Figure 3d. Bridge/router routes packet to a non-bridge interface (simplistic view) Figures 3c and 3d assume the IP packet arrived

32、 on a bridge port. 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 functionality. See the next section. 4. DNATing bridged packets Take an IP packet received by the bridge. Lets 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 decides