Understanding IPTABLES

How IPTABLES Shapes Your Server’s Traffic

When a Linux server boots, the kernel’s Netfilter subsystem is already listening for packets that arrive on every network interface. IPTABLES is the user‑level tool that tells Netfilter how to react to each packet: allow it, block it, log it, or rewrite it. Think of IPTABLES as a set of decision trees that the kernel walks through for each packet that comes in or leaves. The order of those trees matters a lot – the first rule that matches decides what the packet will become, and the rest of the rules are ignored. This means that a single misplaced rule can unintentionally open or close a whole service, so understanding the structure of IPTABLES is critical.

Netfilter organizes its logic into five main tables: filter, nat, mangle, raw, and security. The filter table is the default, and it handles acceptance or rejection. Inside each table are chains – predefined lists of rules that Netfilter follows at specific points in the packet's journey. The filter table’s chains are INPUT, OUTPUT, and FORWARD. INPUT catches packets destined for the local machine; OUTPUT deals with packets that the machine is sending out; FORWARD handles packets that the machine is simply routing. Other tables add extra layers of processing. The nat table can change source or destination addresses before the filter table sees the packet. Mangle can adjust Quality of Service markings or change other header fields. Raw sits at the very beginning, allowing rules to bypass connection tracking. Security adds an additional security‑focused chain.

Each rule is a small recipe: a match condition, a target action, and optional modifiers. A match might test for an IP address, protocol, port, or even a connection state. When a packet satisfies the match, the target decides the outcome – ACCEPT, DROP, REJECT, LOG, SNAT, DNAT, and others. The optional part lets you limit how many packets trigger the rule per second, or count them, or chain them to other targets. Because Netfilter walks the chain from the top down, a general rule placed early can swallow more specific rules that come later. That is why you’ll often see a rule that accepts established connections near the top, followed by tighter rules that open only the services you truly need.

In practice, if you look at an IPTABLES rule set on a fresh installation, you’ll usually find a default ACCEPT policy for all chains, plus a handful of rules that allow SSH and other basic services. This permissive approach works for quick demos but is fragile for production. A single misconfiguration could expose a port that should be closed, or a missing rule could break a critical service. By contrast, a stricter default policy – such as setting DROP for INPUT, FORWARD, and OUTPUT – forces you to be deliberate about which connections you open. That deliberate approach is the cornerstone of hardening any Linux host.

Because the rules are stored in a chain, the order in which you add them is a first‑come, first‑served rule. IPTABLES does not sort the rules for you; it keeps them in the order you specify. Therefore, when you add a new rule, place it above any rule that might inadvertently match it. For instance, if you want to accept SSH traffic on port 22, you should add that rule before a blanket DROP rule that might come after. When you are troubleshooting, you can always insert a LOG rule in front of a suspect rule to see whether it’s matching. If the LOG rule never triggers, the packet never reaches that point, so you need to investigate earlier chains or tables.

Beyond the basic accept‑or‑reject logic, IPTABLES can modify packets. In the nat table, a DNAT rule rewrites the destination address, effectively forwarding an incoming request to a private server behind a firewall. Conversely, an SNAT rule changes the source address, so responses to outbound traffic look like they come from the firewall itself. The mangle table can change priority or set DSCP bits to influence routing decisions. Raw can bypass state tracking for performance, and security can enforce mandatory access control for certain packets. Each of these tables operates at a different stage of packet processing, and a comprehensive understanding of that order is essential to predict how a packet will behave.

All of these concepts fit together to form the logic that governs every byte of traffic that touches a Linux machine. Whether you’re protecting a web server, a database host, or an internal gateway, IPTABLES gives you fine‑grained control. The next sections will walk through how to turn these concepts into a working firewall, from a minimal rule set to advanced techniques and maintenance best practices.

Core Concepts: Tables, Chains, and Rules in Detail

The heart of IPTABLES lies in its division of work into tables, chains, and rules. Understanding this triplet is the key to mastering firewall logic. Think of tables as libraries, chains as sections within those libraries, and rules as individual books that describe exactly how a packet should be handled.

The filter table is the default, and its chains map directly to the traffic flow of a Linux host. INPUT catches inbound packets destined for the local host; OUTPUT deals with packets that the host itself initiates; FORWARD captures packets that are simply passing through the host. Each chain starts with a default policy, which is either ACCEPT or DROP. If a packet reaches the end of a chain without matching any rule, the default policy takes effect. For a secure baseline, most administrators set all three chain policies to DROP, creating a closed door that only opens where you explicitly allow traffic.

When you add a rule, you specify its target – a verb that tells Netfilter what to do – and its match – the conditions that a packet must satisfy. A match can be a simple IP address or a more complex expression, such as a connection state or a packet size. The target is usually one of ACCEPT, DROP, REJECT, LOG, SNAT, or DNAT. For example, the rule iptables -A INPUT -p tcp --dport 22 -j ACCEPT tells Netfilter to accept any TCP packet that arrives on port 22. Adding a LOG target in front of a DROP rule can give you insight into why traffic is being blocked, for example: iptables -A INPUT -j LOG --log-prefix "IPTABLES DROP: " --log-level 4

Modifiers give you additional control over how often a rule can fire or how many packets it can match. The -m limit module lets you cap the rate of matching to avoid flooding logs, while -m state or -m conntrack enables stateful inspection. A common pattern is to allow ESTABLISHED and RELATED connections before dropping everything else: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT. This pattern is the backbone of many secure configurations, because it keeps legitimate traffic flowing while blocking unsolicited inbound requests.