< Previous | Contents | Next >
7.4.1. Netfilter Behavior
Netfilter uses four distinct tables, which store rules regulating three kinds of operations on packets:
• filter concerns filtering rules (accepting, refusing, or ignoring a packet);
• nat (Network Address Translation) concerns translation of source or destination addresses and ports of packets;
• mangle concerns other changes to the IP packets (including the ToS—Type of Service—field and options);
• raw allows other manual modifications on packets before they reach the connection track- ing system.
Each table contains lists of rules called chains. The firewall uses standard chains to handle packets based on predefined circumstances. The administrator can create other chains, which will only be used when referred by one of the standard chains (either directly or indirectly).
The filter table has three standard chains:
• INPUT: concerns packets whose destination is the firewall itself;
• OUTPUT: concerns packets emitted by the firewall;
• FORWARD: concerns packets passing through the firewall (which is neither their source nor their destination).
The nat table also has three standard chains:
• PREROUTING: to modify packets as soon as they arrive;
• POSTROUTING: to modify packets when they are ready to go on their way;
• OUTPUT: to modify packets generated by the firewall itself.
These chains are illustrated in Figure 7.1, “How Netfilter Chains are Called” [page 155].
Figure 7.1 How Netfilter Chains are Called
Each chain is a list of rules; each rule is a set of conditions and an action to perform when the conditions are met. When processing a packet, the firewall scans the appropriate chain, one rule after another, and when the conditions for one rule are met, it jumps (hence the -j option in the commands) to the specified action to continue processing. The most common behaviors are stan- dardized and dedicated actions exist for them. Taking one of these standard actions interrupts the processing of the chain, since the packets fate is already sealed (barring an exception mentioned below). Listed below are the Netfilter actions.
• ACCEPT: allow the packet to go on its way.
• REJECT: reject the packet with an Internet control message protocol (ICMP) error packet (the --reject-with type option of iptables determines the type of error to send).
• DROP: delete (ignore) the packet.
• LOG: log (via syslogd) a message with a description of the packet. Note that this action does not interrupt processing, and the execution of the chain continues at the next rule, which is why logging refused packets requires both a LOG and a REJECT/DROP rule. Common parameters associated with logging include:
– --log-level, with default value warning, indicates the syslog severity level.
– --log-prefix allows specifying a text prefix to differentiate between logged messages.
– --log-tcp-sequence, --log-tcp-options, and --log-ip-options indicate extra data to be in- tegrated into the message: respectively, the TCP sequence number, TCP options, and IP options.
• ULOG: log a message via ulogd, which can be better adapted and more efficient than syslogd for handling large numbers of messages; note that this action, like LOG, also re- turns processing to the next rule in the calling chain.
• chain_name: jump to the given chain and evaluate its rules.
• RETURN: interrupt processing of the current chain and return to the calling chain; in case the current chain is a standard one, there’s no calling chain, so the default action (defined with the -P option to iptables) is executed instead.
• SNAT (only in the nat table): apply Source Network Address Translation (SNAT). Extra options describe the exact changes to apply, including the --to-source address:port option, which defines the new source IP address and/or port.
• DNAT (only in the nat table): apply Destination Network Address Translation (DNAT). Extra op- tions describe the exact changes to apply, including the --to-destination address:port option, which defines the new destination IP address and/or port.
• MASQUERADE (only in the nat table): apply masquerading (a special case of Source NAT).
• REDIRECT (only in the nat table): transparently redirect a packet to a given port of the firewall itself; this can be used to set up a transparent web proxy that works with no con- figuration on the client side, since the client thinks it connects to the recipient whereas the communications actually go through the proxy. The --to-ports port(s) option indicates the port, or port range, where the packets should be redirected.
Other actions, particularly those concerning the mangle table, are outside the scope of this text. The iptables(8) and ip6tables(8) man pages have a comprehensive list.
What is ICMP? Internet Control Message Protocol (ICMP) is the protocol used to transmit ancillary information on communications. It tests network connectivity with the ping com- mand, which sends an ICMP echo request message, which the recipient is meant to answer with an ICMP echo reply message. It signals a firewall rejecting a packet, indi- cates an overflow in a receive buffer, proposes a better route for the next packets in the connection, and so on. This protocol is defined by several RFC documents. RFC777 and RFC792 were the first, but many others extended and/or revised the protocol.
➨ http://www.faqs.org/rfcs/rfc777.html
➨ http://www.faqs.org/rfcs/rfc792.html
For reference, a receive buffer is a small memory zone storing data between the time it arrives from the network and the time the kernel handles it. If this zone is full, new data cannot be received and ICMP signals the problem so that the emitter can slow down its transfer rate (which should ideally reach an equilibrium after some time).
Note that although an IPv4 network can work without ICMP, ICMPv6 is strictly re- quired for an IPv6 network, since it combines several functions that were, in the IPv4 world, spread across ICMPv4, Internet Group Membership Protocol (IGMP), and Ad- dress Resolution Protocol (ARP). ICMPv6 is defined in RFC4443.
➨ http://www.faqs.org/rfcs/rfc4443.html
What is ICMP? Internet Control Message Protocol (ICMP) is the protocol used to transmit ancillary information on communications. It tests network connectivity with the ping com- mand, which sends an ICMP echo request message, which the recipient is meant to answer with an ICMP echo reply message. It signals a firewall rejecting a packet, indi- cates an overflow in a receive buffer, proposes a better route for the next packets in the connection, and so on. This protocol is defined by several RFC documents. RFC777 and RFC792 were the first, but many others extended and/or revised the protocol.
➨ http://www.faqs.org/rfcs/rfc777.html
➨ http://www.faqs.org/rfcs/rfc792.html
For reference, a receive buffer is a small memory zone storing data between the time it arrives from the network and the time the kernel handles it. If this zone is full, new data cannot be received and ICMP signals the problem so that the emitter can slow down its transfer rate (which should ideally reach an equilibrium after some time).
Note that although an IPv4 network can work without ICMP, ICMPv6 is strictly re- quired for an IPv6 network, since it combines several functions that were, in the IPv4 world, spread across ICMPv4, Internet Group Membership Protocol (IGMP), and Ad- dress Resolution Protocol (ARP). ICMPv6 is defined in RFC4443.
➨ http://www.faqs.org/rfcs/rfc4443.html