232 iptables: Deep Analysis of Rule Tables and Chains
Preface
In the previous article, we gained a deep understanding of Netfilter’s HOOK mechanism — that’s the underlying infrastructure of the entire framework. If we think of Netfilter as the ramp system of a highway, then iptables is the rulebook at the toll booths on those ramps. It defines “which cars can pass,” “which cars need to pay,” and “which cars get stopped immediately.”
iptables is the most classic and widely used firewall configuration tool in Linux. Although nftables is gradually replacing it in recent years, understanding iptables’ design philosophy remains essential for mastering the core logic of Linux network security.
This article comprehensively analyzes iptables from five dimensions: table-chain mechanism, match principles, rule processing flow, practical scenarios, and demos, while also comparing with the Windows WFP rule configuration model.
1. Table and Chain Architecture
1.1 Why Are “Tables” and “Chains” Needed?
Netfilter has only 5 HOOK points. If all rules were written directly on these 5 HOOKs, the rules would be very chaotic:
# Messy rule example (don't do this!)
-A INPUT -p tcp --dport 22 -j ACCEPT # This is firewall
-A INPUT -p tcp --dport 80 -j DNAT ... # This is NAT
-A INPUT -p tcp --dport 80 -j ACCEPT # This is firewall againiptables introduces Tables to separate different functional domains: the filter table focuses on “accept/reject,” the nat table focuses on “address translation,” and the mangle table focuses on “modifying packets.” Then within each table, Chains correspond to different HOOK points.
┌─────────────────────────────────────────────────────────────────┐
│ iptables Table and Chain Mapping Overview │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 5 Netfilter HOOK points (vertical) vs 4 iptables Tables (functional domains) │
│ │
│ PREROUTING LOCAL_IN FORWARD LOCAL_OUT POSTROUTING │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ raw Table │ │
│ │ (Highest priority, processed first, NOTRACK) │ │
│ └────────┬────────┬────────┬────────┬────────────┘ │
│ │ │ │ │ │
│ ┌────────▼────────▼────────▼────────▼────────────┐ │
│ │ mangle Table │ │
│ │ (Modify packet content: TTL/TOS/MARK/QOS) │ │
│ └────────┬────────┬────────┬────────┬────────────┘ │
│ │ │ │ │ │
│ ┌────────▼────────▼────────▼────────▼────────────┐ │
│ │ nat Table │ │
│ │ (Network address translation: SNAT/DNAT) │ │
│ └────────────────┬────────┬────────┬────────────┘ │
│ │ │ │ │
│ ┌────────────────▼────────▼────────▼────────────┐ │
│ │ filter Table │ │
│ │ (Packet filtering: ACCEPT/DROP/REJECT) │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘2. Detailed Table-Chain Mapping
Tables and their available chains:
raw table: PREROUTING, OUTPUT
→ Connection tracking NOTRACK, highest priority
mangle table: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING
→ Modify packet (TTL/TOS/MARK), all 5 HOOKs available
nat table: PREROUTING, INPUT, OUTPUT, POSTROUTING
→ SNAT/DNAT/MASQUERADE
→ First packet of a connection traverses nat;
subsequent packets are handled by conntrack
filter table: INPUT, FORWARD, OUTPUT
→ Core packet filtering (ACCEPT/DROP/REJECT)
→ Most commonly used tableTable processing order at the same HOOK point:
1. raw (highest priority, before conntrack)
2. mangle (modify packet)
3. nat (address translation, only first packet)
4. filter (packet filtering, lowest priority)
Example: PREROUTING chain processing order
raw PREROUTING → mangle PREROUTING → nat PREROUTING3. Rule Matching Principles
Structure of an iptables rule:
iptables -t <table> -A <chain> <matches> -j <target>
Matches: -s, -d, -p, --sport, --dport, -m state, -m limit, ...
Target: ACCEPT, DROP, REJECT, LOG, RETURN, DNAT, SNAT, ...
Matching order:
1. Rules are processed in order
2. If a rule matches, execute its target
3. If no rule matches, the chain's default policy (ACCEPT/DROP) applies
Important: Rule order matters!
- Put frequently matched rules first (improve performance)
- Put restrictive rules before permissive rules
- Default policy should be DROP (least privilege principle)4. Common Use Cases
1. Basic firewall (allow SSH, drop everything else):
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
2. NAT (IP masquerading for LAN):
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth1 -o eth0 -m state --state NEW -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
3. Rate limiting:
iptables -A INPUT -p tcp --dport 80 -m limit --limit 100/s -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
4. Logging:
iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "SSH: "5. Comparison with Windows WFP
iptables vs. Windows WFP rule model:
iptables WFP
Rule format Line-based CLI Structured API (Fwpm*)
Table types filter/nat/mangle/raw/security 11 layers (FWPM_LAYER*)
Matching fields IP/port/protocol/interface/... 5-tuple + app ID + user SID + ...
Target actions ACCEPT/DROP/REJECT/LOG/RETURN Block/Permit/Callout
State tracking conntrack ALE (Application Layer Enforcement)
Performance High (kernel) Medium (user+callout)
Dynamic updates Atomic (iptables-restore) Transactional (FwpmTransaction*)
Key differences:
1. WFP is API-based, iptables is command-line
2. WFP supports per-application rules (AppContainer/SID)
3. iptables is simpler and more intuitive
4. WFP has finer-grained filtering at the stream/session layer
Comments