NetFilter, or more commonly known by the name of the manipulation utility, iptables, works, on the surface, similarly to the ipchains firewall code of earlier Linux kernels. The first thing you need to understand about NetFilter is the concept of tables, chains, and rules. Tables are used to provide certain types of functionality, which are defined in more detail through this chapter. Chains define the path in which a packet can travel. The chains are made up of rules, which define what action should be taken on packets that match the rule. An easy way to think about it is that chains simply contain a list of the rules, and tables contain the different types of chains. NetFilter has five builtin chains, which are grouped into the following three tables:
The filter table has three builtin chains that function in a similar fashion to the three primary chains of ipchains. The function of the chains in the filter table is to test the payload of the packets (as well as other characteristics) and to accept or reject the packets based on the results of that evaluation. The three builtin chains found in the filter table are as follows:
The INPUT chain evaluates packets that are destined for the firewall itself. The OUTPUT chain evaluates packets that originate from the firewall. The FORWARD chain evaluates packets that are traversing the firewall from one network interface to another. One of the key differences between the chains in NetFilter and ipchains is that in ipchains all packets going from one network interface to another traverse all three of the main chains (INPUT, FORWARD, and OUTPUT). In NetFilter, however, they need only traverse the FORWARD chain because that one is the one involved in forwarding packets between interfaces. Figures 7-1 through 7-3 show the chain traversal. Figure 7-1. NetFilter INPUT Chain ProcessingIn Figure 7-1, the packet from the source host 192.168.45.10 is directed to the firewall itself. To reach the firewall, the packet must traverse the rules that are in the INPUT chain of the filter table. In Figure 7-2, the traffic from host 192.168.45.10 is directed to the server at 10.1.1.1. Typically, this also requires NAT to be present so that the server 10.1.1.1 has an external address assigned to it, but this is beyond the scope of the current discussion. To reach the system 10.1.1.1, the traffic must traverse the rules in the FORWARD chain of the filter table because the traffic is going from one interface to another on the firewall. Figure 7-2. NetFilter FORWARD Chain ProcessingIn the final example of Figure 7-3, a process on the firewall is communicating with the host 192.168.45.10. The traffic must traverse the rules in the OUTPUT chain of the filter table on the firewall before reaching its destination. Typically, unless the firewall is filtering traffic in both directions, the OUTPUT chain is empty and all traffic is allowed out from the firewall (which could be considered a security risk in certain environments). Figure 7-3. NetFilter OUTPUT Chain ProcessingOne of the key features that NetFilter has over ipchains is that NetFilter is a stateful packet filter. Instead of requiring a specific inbound rule for every outbound connection, the NetFilter code can identify return traffic that is related to previously seen outbound traffic. This identification provides for a more efficient and secure firewall than is possible with ipchains. The NAT table performs Network Address Translation (and Port Address Translation) functions on packets. This includes destination NAT (DNAT), source NAT (SNAT), and masquerading. This table consists of three builtin chains:
The PREROUTING chain processes packets before the local routing table is consulted, and is used primarily for destination NAT. Destination NAT is where the destination address of the IP packets is modified as they traverse the NAT device. DNAT can be used to accomplish the following capabilities:
Port forwarding is where the firewall accepts packets for a destination host behind it and forwards the packet unchanged to the destination. Load balancing is where the firewall accepts packets destined for an externally visible IP address but distributes the connections across multiple servers behind it to ensure that no one server gets overloaded. Load balancing proves particularly useful in a web farm situation where multiple web servers serve identical content;to ensure consistent performance or high availability, the firewall directs connections to the various servers based on their current connection load. Although this is not the only way that you can accomplish load balancing, it is one of the more popular ways. Finally, transparent proxying is similar to port forwarding, but instead of allowing the connection from the client to the server to go unaltered, the firewall intercepts the connection. Although the client believes that it is communicating with the destination server, it is actually communicating with a firewall that is inspecting and potentially altering the packets before redirecting them to the destination system. Although the NetFilter code does not perform the proxying itself, this capability is possible using the Squid proxying software package. Because the DNAT occurs in the PREROUTING chain of the NAT table, the INPUT and FORWARD chains in the filter table see the real address of the destination system. The POSTROUTING chain processes packets after the routing decision has been made, and is primarily used for source NAT. This version of NAT modifies the source IP address in the packets as they traverse the NAT device. Whereas the INPUT and FORWARD chains see the modified IP address of a packet having undergone DNAT, all three chainsINPUT, OUTPUT, and FORWARDsee the unmodified IP address of packets undergoing SNAT. Masquerading is a simple version of SNAT in which packets receive the IP address of the output interface of the firewall as their source address. This functionality is the same as NAT overload in Cisco IOS code as well as the global command in the PIX. The final table in NetFilter is the mangle table. This table enables the firewall to modify numerous packet header fields, including Type of Service, Time To Live (TTL), Differentiated Service Code Point (DSCP) field, TCP Mean Segment Size (TCPMSS), and Explicit Congestion Notification (ECN). Additionally, this table allows for the marking of packets for later processing by userdefined chains in the firewall rules using the MARK match and MARK target. The MARK target is used to set special values on a packet to perform additional operations on the packet. This value could include specific routing considerations based on the MARK (using the iproute2 program) or bandwidth limiting or classbased queuing as well as other operations. For kernel 2.4.18 and later, this table has five builtin chains: PREROUTING, INPUT, FORWARD, OUTPUT, and POSTROUTING. Previous kernel versions have two builtin chains: PREROUTING and OUTPUT. NetFilter enables administrators to devise chains to extend the capabilities of the builtin chains. Each userdefined chain must be associated with one of the three tables in NetFilter. As with ipchains, packets can be diverted to the userdefined chains, and when the processing of the packet in the userdefined chain is complete, the packet processing continues at the first rule after the one that sent the packet to the userdefined chain. The next section covers the full path of packets through the various chains in NetFilter. |