Introduction

Firewalls are an essential tool to protect your servers and infrastructure. In the Linux world, iptables is a widely used firewall tool that collaborates with the kernel’s packet filtering framework, netfilter. Creating reliable firewall policies can be challenging due to complex syntax and many interconnected parts. In this guide, we delve into the iptables architecture to make it more understandable for users who need to create their own firewall policies. We’ll discuss how iptables interacts with netfilter and how the various components fit together to provide a comprehensive filtering system.

What are IPTables and Netfilter?

The firewall software most commonly used in Linux for many years is called iptables. In some distributions, it has been replaced by a new tool called nftables, but iptables syntax is still frequently used as a starting point. The iptables firewall operates by interacting with the packet filtering hooks in the Linux kernel’s network stack. These kernel hooks are known as the netfilter framework. Each packet that traverses the network layer (inbound or outbound) triggers these hooks, allowing programs to interact with the traffic at crucial points. The kernel modules connected to iptables register with these hooks to ensure that the traffic complies with the firewall rules’ conditions.

Netfilter Hooks

There are five netfilter hooks where programs can register themselves. The hooks that a packet will trigger depend on whether the packet is inbound or outbound, the packet’s destination, and whether the packet has been rejected or dropped at an earlier stage. The following hooks represent these well-defined points in the network stack:

• NF_IP_PRE_ROUTING
• NF_IP_LOCAL_IN
• NF_IP_FORWARD
• NF_IP_LOCAL_OUT
• NF_IP_POST_ROUTING

Kernel modules registering with these hooks must also specify a priority number to determine the order in which they are called when the hook is triggered. Each module is called sequentially and returns a decision to the netfilter framework after processing, indicating what should happen to the packet.

IPTables Tables and Chains

The iptables firewall uses tables to organize its rules. These tables classify rules based on the type of decisions they are intended to make. Within each iptables table, rules are organized into separate “chains.” While tables are defined by the general purpose of the rules they hold, the built-in chains represent the netfilter hooks they are associated with. Chains determine when rules are evaluated. The names of the built-in chains reflect the names of the netfilter hooks they are associated with: PREROUTING, INPUT, FORWARD, OUTPUT, and POSTROUTING.

Which Tables Are Available?

The filter table is one of the most commonly used tables in iptables. It is used to make decisions about whether to forward a packet to its destination or reject the request. The NAT table is used to implement rules for network address translation. The Mangle table is used to modify the IP headers of the packet in various ways. The Raw table has a very narrowly defined function: it is used to mark packets to opt-out from connection tracking. The Security table is used to set internal SELinux security context markings on packets that affect how SELinux or other systems interpreting SELinux security contexts handle the packets.

IPTables Rules

Rules are placed in a specific chain of a specific table. The matching component of a rule specifies the criteria that a packet must meet for the associated action (“target”) to be executed. The availability of each target within rules depends on the context. Jumping to custom chains is also possible.

IPTables and Connection Tracking

Connection tracking allows iptables to make decisions about packets in the context of an ongoing connection. The tracked states in connection tracking allow administrators to create rules targeting specific points in a connection’s lifecycle.

Conclusion

The netfilter packet filtering framework and the iptables firewall form the foundation for most firewall solutions on Linux servers. By understanding how these pieces fit together, you can better leverage them to control and secure your server environments.