Rules and Targets
Fundamentally, most of the things we configure in an iptables (or ip6tables) firewall are the rules that are used to process packets. These rules ultimately result in processing jumping to one of several targets, which determine what happens to the packet.
Video Lecture
Rules and Chains
Processing in iptables is done by trying to match packets using rules, which may specify properties that match the packet. If a packet matches these properties, then the rule is applied. A rule that doesn’t specify any properties to match is always applied to any packet that encounters that rule. Rules normally specify a target to which processing jumps if the rule matches.
Recall that rules are organized into chains and are processed in order from the top (or head) of the chain to the end of the chain. The first matching rule that causes a jump either to another chain or to a special target normally terminates processing of that chain. The exception is that some targets are non-terminating, which means they RETURN to the original chain after processing.
Default Policies
Each chain in each table has a default policy, which is normally one of ACCEPT, DROP, or REJECT. If a packet does not match a rule in the chain, the default policy will be applied to the packet whenever it reaches the end of the chain.
Targets
As iptables processes a packet along a chain, the rules specified for the chain might cause the packet to jump to another chain or to a target. Eventually, the packet will wind up at one of the special targets built into iptables. This target may be reached by matching a rule that contains a jump, by encountering an unconditional rule that always jumps, or by application of the default policy if no rules in the chain have been matched. A number of special targets are available.
Common Targets
Some of the most common special targets in iptables are:
- ACCEPT
- The packet is accepted at this point and goes on for further processing by the next table. At the security table on an inbound firewall, an ACCEPTed packet normally goes to the network socket of the application.
- DROP
- The packet is discarded. No response or acknowledgment is sent back to the transmitter.
- REJECT
- The packet is discarded. An error response is sent back to the transmitter.
- RETURN
- In a user-defined chain, RETURN causes the packet to jump back to the previous chain for further processing. In the predefined chains, RETURN causes the default policy to be applied to the packet.
Rejecting a Packet
If the firewall is set to reject a packet, it may do so by using either the DROP or REJECT target. REJECT sends an error message packet (using ICMP or IPv6-ICMP) back to the sender. Sending a REJECT is desirable for the correct operation of certain protocols, such as the Transmission Control Protocol (TCP).
While sending a REJECT follows network standards, it is less desirable from a security perspective for a system that is directly connected to the Internet (for example, an edge router). Sending a REJECT from the firewall does two things that are problematic: first, it allows port scanners to find open ports on the system quickly and efficiently. Second, it acknowledges the existence of the system to third parties that are not involved in any desired communications with the system, making it easier for nefarious parties to troll the Internet looking for potential targets.
To balance standards compliance with cybersecurity, my recommended approach is to REJECT packets within a closed (and reasonably trusted) LAN environment but DROP unwanted packets arriving from the Internet. This way, local network services will fail fast in the event of a misconfiguration or service outage, instead of appearing to hang for a long time. At the same time, I want an uninvited network visitor from outside the LAN to be inconvenienced as much as possible.
Logging Targets
In the case of server systems, we typically want to log invalid connection attempts. Logging here serves several purposes. First, any server we deploy on the Internet will be attacked early and often. Logging these attacks allows for the addition of software such as Fail2ban1, which dynamically alters firewall rules to drop packets from attackers who are trying to break into the system. Fail2ban can monitor logs from both the firewall and individual services, blocking attack sources for a configurable period of time. This type of software greatly reduces the efficiency of brute-force attacks.
Another reason to log packets on servers (especially those dropped or rejected) is to spot configuration issues. If our firewall is sufficiently complex, it can be difficult to determine which rule is causing a connection to fail. Logging rejection actions makes it easier to debug the firewall and adjust it to permit desired traffic.
Two main targets are used for logging, both of which provide detailed per-packet information:
- LOG
- Sends the log data to the default system logging facility. Depending on the Linux distribution and logging facility used, these logs can wind up in a variety of different places and might be intermingled with other log data. Typical logging facilities include syslog and journald.
- ULOG
- Sends the log data to a special interface. Various software daemons (services) can listen to this interface and retrieve the log data as they arrive. These daemons can be configured to store the results in flexible locations, such as a file or database.
Both LOG and ULOG are non-terminating targets. These targets have RETURN statements that cause chain processing to continue after the packet has been logged. Therefore, a packet that is logged still needs to be handled. Note that rule order is important here: the logging needs to happen before the packet is handled. If the rule to ACCEPT, REJECT, or DROP a packet is encountered before a LOG or ULOG rule, then no logging will occur, since the (U)LOG rule will never be reached in the chain.
Source NAT Targets
Whenever we speak of Network Address Translation (NAT) colloquially, we technically mean Source Network Address Translation (SNAT), which is what we use to have multiple devices behind a router share a single public IPv4 address that is assigned to that router. There are actually two targets available for implementing SNAT:
- SNAT
- Enables Source NAT to rewrite source addresses to a static IP address, or load balance between a set of static IP addresses. This target is useful in situations where the router has one or more static IP addresses. This address (or set of addresses) must be specified in the firewall configuration.
- MASQUERADE
- Enables Source NAT but uses the IP address of the outgoing interface as the address used when rewriting the packet address. MASQUERADE differs from SNAT in that the firewall will look up the address of the outgoing network interface automatically. This behavior is useful when the router itself obtains an address from DHCP, which is normally the case when connecting a router to an Internet Service Provider (ISP).
In general, a NAT router will use the MASQUERADE target in the POSTROUTING chain of the nat table.
Destination NAT Targets
There is a second type of Network Address Translation that is less well-known and less commonly used than SNAT. This second type is Destination Network Address Translation (DNAT). Instead of rewriting the source address from which a packet appears to be sent, DNAT rewrites the destination address to which the packet is forwarded. An automatic form of DNAT happens whenever a NAT router receives a reply in response to a packet that has had SNAT applied. However, there are certain cases where DNAT rules need to be configured manually.
One common case where a DNAT rule is used is when port-forwarding. With port-forwarding, a connection from the outside network to a specified port on the router is sent directly to some other system on the inside network. DNAT allows for a server to be hosted on another machine inside the private network, creating a DeMilitarized Zone (DMZ) from which a public-facing service can be offered from an otherwise protected network.
When configuring DNAT using iptables or ip6tables, note that it is only a valid target when used in the nat table. Furthermore, jumping to the DNAT target is only permitted from the PREROUTING and OUTPUT chains.
Other Targets
Other targets are constantly being added to, and removed from, the Linux kernel as it is developed. Some targets might only become available once a kernel module is loaded. A non-exhaustive list of some of these other targets includes:
- Targets for Quality of Service (QoS) and TCP tuning: CLASSIFY, DSCP, ECN, FTOS, NFQUEUE, QUEUE, TCPMSS, TOS
- Targets for clustering, arcane types of NAT, etc.: CLUSTERIP, NETLINK, NETMAP, NOTRACK, ROUTE, SAME
- Marking packets or connections for processing by other rules: CONNMARK, CONNSECMARK, MARK, SECMARK
- Proxying and connection obfuscation: IPV4OPTSSTRIP, REDIRECT, TTL, XOR
