For each chain, the output of iptables -L (list rules) contains information on the target (ACCEPT, DROP, and REJECT are the most common targets), the TCP/IP protocol, and the packet source and destination.
When a TCP/IP packet is analyzed, a decision is made about what to do if that packet matches a rule. If the packet matches a rule, it is sent to a netfilter target, most likely ACCEPT, DROP, or REJECT.
We'll use an incoming SSH connection to a firewall as an example. It will be a TCP connection on port 22 on the INPUT rule at a bare minimum. If you have a rule that describes this packet, you need to tell the netfilter system to ACCEPT this packet into the TCP/IP stack for further processing by the kernel.
However, you can tell netfilter to DROP or REJECT the packet:
■ When a packet is sent to the DROP target, it simply disappears and the sending machine does not know this has happened until it times out.
■ When a packet is subject to the REJECT target, the sending machine is notified through an Internet Control Message Protocol (ICMP) message that the port was not reachable (that is, it was stopped).
T^TTT^*^^" If you configure the default policy of all chains to DROP/REJECT all non-triggered
~ ■"■> ■ packets, it is unlikely you need to use these as targets because any packets that have not been explicitly ACCEPTed will be subject to the DROP/REJECT target.
The netfilter firewalling code provides a stateful firewall, which is a great new feature of the netfilter code. In the past, it was up to the administrator to track all connections through the firewall, which produced a lot of rules that were difficult to manage. With a stateful firewall, netfilter keeps a record of connection states. With this information, netfilter can track a connection initiation and match up related network traffic.
For example, previously, if you wanted to allow an incoming connection to SSH on the firewall, you had to first allow the incoming connection and also the return traffic from the SSH server to the client. With stateful firewalls, you can tell the firewall to manage the subsequent outgoing connection automatically because it is aware that an incoming connection to the machine will produce traffic in the opposite direction. It does this by storing the state of a connection and acting upon it with connection tracking. A stateful firewall is also much harder to trick with spoofed packets because whether or not a spoofed packet from outside is accepted by the firewall depends on the current state of established connections rather than a rule that would always treat the packet in the same way.
To enable the stateful connection tracking, you need to enable states in the firewall. We see this in a small firewall script later in the chapter.
Was this article helpful?