This chapter is from the book
This chapter is from the book
This chapter is from the book
iptables Features
iptables uses the concept of separate rule tables for different kinds of packet processing functionality. These rule tables are implemented as functionally separate table modules. The three primary modules are the rule filter table, the NAT nat table, and the specialized packet-handling mangle table. Each of these three table modules has its own associated module extensions that are dynamically loaded when first referenced, unless you’ve built them directly into the kernel.
The filter table is the default table. The other tables are specified by a command-line option. The basic filter table features include these:
Chain-related operations on the three built-in chains (INPUT, OUTPUT, and FORWARD) and on user-defined chains
Help
Target disposition (ACCEPT or DROP)
IP header field match operations for protocol, source and destination address, input and output interfaces, and fragment handling
Match operations on the TCP, UDP, and ICMP header fields
The filter table has two kinds of feature extensions: target extensions and match extensions. The target extensions include the REJECT packet disposition, the BALANCE and CLUSTERIP targets, the CLASSIFY target, CONNMARK, TRACE, and the LOG and ULOG functionalities. The match extensions support matching on the following:
The current connection state
Port lists (supported by the multiport module)
The hardware Ethernet MAC source address or physical device
The type of address, link-layer packet type, or range of IP addresses
Various parts of IPSec packets or the IPSec policy
The ICMP type
The length of the packet
The time the packet arrived
Every nth packet or random packets
The packet sender’s user, group, process, or process group ID
The IP header Type of Service (TOS) field (possibly set by the mangle table)
The TTL section of the IP header
The iptables mark field (set by the mangle table)
Rate-limited packet matching
The mangle table has two target extensions. The MARK module supports assigning a value to the packet’s mark field that iptables maintains. The TOS module supports setting the value of the TOS field in the IP header.
The nat table has target extension modules for Source and Destination Address Translation and for Port Translation. These modules support these forms of NAT:
SNAT—Source NAT.
DNAT—Destination NAT.
MASQUERADE—A specialized form of source NAT for connections that are assigned a temporary, changeable, dynamically assigned IP address (such as a phone dial-up connection).
REDIRECT—A specialized form of destination NAT that redirects the packet to the local host, regardless of the address in the IP header’s destination field.
All TCP state flags can be inspected, and filtering decisions can be made based on the results. iptables can check for stealth scans, for example.
TCP can optionally specify the maximum segment size that the sender is willing to accept in return. Filtering on this one, single TCP option is a very specialized case. The TTL section of the IP header can also be matched and is a specialized case as well.
TCP connection state and ongoing UDP exchange information can be maintained, allowing packet recognition on an ongoing basis rather than on a stateless, packet-by-packet basis. Accepting packets recognized as being part of an established connection allows bypassing the overhead of checking the rule list for each packet. When the initial connection is accepted, subsequent packets can be recognized and allowed.
Generally, the TOS field is of historical interest only. The TOS field is either ignored or used with the newer Differentiated Services definitions by intermediate routers. IP TOS filtering has uses for local packet prioritizing—routing and forwarding among local hosts and the local router.
Incoming packets can be filtered by the MAC source address. This has limited, specialized uses for local authentication because MAC addresses are passed only between adjacent hosts and routers.
Individual filter log messages can be prefixed with user-defined strings. Messages can be assigned kernel logging levels as defined for /etc/syslog.conf. This allows logging to be turned on and off, and for the log output files to be defined, in /etc/syslog.conf. In addition, there is a ULOG option that sends logging to a userspace daemon, ulogd, to enable further detail to be logged about the packet.
Packet matches can be limited to an initial burst rate, after which a limit is imposed by the number of allowed matches per second. If match limiting is enabled, the default is that, after an initial burst of five matched packets, a rate limit of three matches per hour is imposed. In other words, if the system were flooded with ping packets, for example, the first five pings would match. After that, a single ping packet could be matched 20 minutes later, and another one could be matched 20 minutes after that, regardless of how many echo-requests were received. The disposition of the packets, whether logged or not, would depend on any subsequent rules regarding the packets.
The REJECT target can optionally specify which ICMP (or RST for TCP) error message to return. The IPv4 standard requires TCP to accept either RST or ICMP as an error indication, although RST is the default TCP behavior. iptable’s default is to return nothing (DROP) or else to return an ICMP error (REJECT).
Along with REJECT, another special-purpose target is QUEUE. Its purpose is to hand off the packet via the netlink device to a user-space program for handling. If there is no waiting program, the packet is dropped.
RETURN is another special-purpose target. Its purpose is to return from a user-defined chain before rule matching on that chain has completed.
Locally generated outgoing packets can be filtered based on the user, group, process, or process group ID of the program generating the packet. Thus, access to remote services can be authorized at the packet-filtering level on a per-user basis. This is a specialized option for multiuser, multipurpose hosts because firewall routers shouldn’t have normal user accounts.
Matching can be performed on various pieces of IPSec header, including the SPIs (security parameter indices) of the AH (authentication header) and ESP (encapsulating security payload).
The type of packet, be it broadcast, unicast, or multicast, is another form of match. This is done at the link layer.
A range of ports as well as a range of addresses are also valid matches with iptables. The type of address is another valid match as well. Related to type matching is the ICMP packet type. Recall that there are a number of valid types of ICMP packet types. Iptables can match against these types.
The length of the packet is a valid match, as is the time a packet arrived. This time matching is interesting. Using the time matches, you could configure the firewall to reject certain traffic after business hours or allow it only during certain times of day.
A good match for auditing, a random packet match is also available with iptables. Using this match, you can capture every nth packet and log it. This would be a method for auditing the firewall rules without logging too much information.
NAT Table Features
There are three general forms of NAT:
-
Traditional, unidirectional outbound NAT—Used for networks using private addresses.
-
Basic NAT—Address Translation only. Usually used to map local private source addresses to one of a block of public addresses.
-
NAPT (Network Address Port Translation)—Usually used to map local private source addresses to a single public address (for example, Linux masquerading).
-
Bidirectional NAT—Two-way address translation allows both outbound and inbound connections. A use of this is bidirectional address mapping between IPv4 and IPv6 address spaces.
-
Twice NAT—Two-way Source and Destination Address Translation allows both outbound and inbound connections. Twice NAT can be used when the source and destination networks' address spaces collide. This could be the result of one site mistakenly using public addresses assigned to someone else. Twice NAT also can be used as a convenience when a site was renumbered or assigned to a new public address block and the site administrator didn't want to administer the new address assignments locally at that time.
iptables NAT supports source (SNAT) and destination NAT (DNAT). The NAT table allows for modifying a packet's source address or destination address and port. It has three built-in chains:
The PREROUTING chain specifies destination changes to incoming packets before passing the packet to the routing function (DNAT). Changes to the destination address can be to the local host (transparent proxying, port redirection) or to a different host for host forwarding (ipmasqadm functionality, port forwarding in Linux parlance) or load sharing.
The OUTPUT chain specifies destination changes to locally generated outgoing packets before the routing decision has been made (DNAT, REDIRECT). This is usually done to transparently redirect an outgoing packet to a local proxy, but it can also be used to port-forward to a different host.
The POSTROUTING chain specifies source changes to outgoing packets being routed through the box (SNAT, MASQUERADE). The changes are applied after the routing decision has been made.
With regular SNAT, connection state is maintained for the duration of a timeout period. If a connection were reestablished quickly enough, any current network-related programs could continue undisturbed because the IP address hasn’t changed, and interrupted TCP traffic would be retransmitted.
The distinction between MASQUERADE and SNAT is an attempt to avoid a situation that occurred in previous Linux NAT/MASQUERADE implementations. When a dial-up connection was lost and the user reconnected immediately, he was assigned a new IP address. The new address couldn’t be used immediately because the old IP address and NAT information were still in memory until the timeout period expired.
Figure 3.4 shows the NAT chains in relation to the routing function and INPUT, OUTPUT, and FORWARD chains.
)
Figure 3.4 NAT packet traversal. (Figure based on "Linux 2.4 Packet Filtering HOWTO," v1.0.1, and "Linux 2.4 NAT HOWTO," v1.0.1.)
Note that, for outgoing packets, the routing function is implied between the local process and the OUTPUT chain. Static routing is used to determine which interface the packet will go out on, before the OUTPUT chain’s filter rules are applied.
mangle Table Features
The mangle table allows marking, or associating a Netfilter-maintained value, with the packet, as well as making changes to the packet before sending the packet on to its destination. The mangle table has five built-in chains:
The PREROUTING chain specifies changes to incoming packets as they arrive at an interface, before any routing or local delivery decision has been made.
The INPUT chain specifies changes to packets as they are processed, but after the PREROUTING chain is traversed.
The POSTROUTING chain specifies changes to packets as they are exiting the firewall, after the OUTPUT chain is traversed.
The FORWARD chain specifies changes to packets that are forwarded through the firewall.
The OUTPUT chain specifies changes to locally generated outgoing packets.
For the TOS field, the local Linux router can be configured to honor the TOS flags set by the mangle table or as set by the local hosts.
Little information is available about packet marking in the iptables documentation, beyond that it’s used by the Linux Quality of Service implementation and that it’s intended as a communication flag between iptables modules.
The preceding sections provided an overview of the features available in iptables and the general structure and functionality of the individual table modules. The following sections present the syntax used to invoke these features.