6.4a iptables fundamentals: chains, tables, and rules¶

🔍 Context Introduction¶

When managing AI servers, network traffic flows constantly between compute nodes, storage systems, and external users. Without a firewall, all traffic is allowed by default — which is dangerous for AI workloads handling sensitive data or model weights. iptables is the classic Linux firewall tool that gives engineers fine-grained control over what network packets enter, leave, or pass through a server. Understanding its three core concepts — chains, tables, and rules — is essential for securing AI infrastructure.

⚙️ What is iptables?¶

iptables is a command-line utility that configures the Linux kernel's Netfilter firewall. It works by inspecting each network packet and deciding its fate based on a set of ordered rules. Think of it as a traffic cop for your server's network interfaces.

• iptables operates at the kernel level, meaning it filters traffic before it reaches applications.
• Rules are evaluated top-down — the first matching rule determines the packet's fate.
• If no rule matches, a default policy (usually ACCEPT or DROP) applies.

📊 The Three Pillars: Tables, Chains, and Rules¶

These three components work together like a filing system:

🗂️ Tables — The Function Groups¶

iptables has several tables, but for AI infrastructure security, you will most often use these three:

🔹 filter table (default)¶

• Used for basic packet filtering (allow or block).
• Most common table for firewall rules.
• Protects the server itself.

🔹 nat table¶

• Used for Network Address Translation.
• Important when AI servers sit behind load balancers or need to route traffic to containers.

🔹 mangle table¶

• Used for specialized packet modifications (e.g., changing TTL or QoS markings).
• Rarely needed for basic AI server security.

⛓️ Chains — The Traffic Checkpoints¶

Each table contains built-in chains. Packets travel through these chains automatically depending on their direction:

For the filter table (most relevant for security):¶

• INPUT chain — Handles packets destined for the server itself (e.g., SSH connections to the AI server).
• OUTPUT chain — Handles packets leaving the server (e.g., model inference results sent to a client).
• FORWARD chain — Handles packets passing through the server (e.g., when the AI server acts as a router between two networks).

For the nat table:¶

• PREROUTING chain — Alters packets before routing decisions.
• POSTROUTING chain — Alters packets after routing decisions.

📊 Visual Representation: iptables Packet Processing Chains¶

This flowchart maps out the packet processing path through netfilter tables and chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING).

📜 Rules — The Decision Makers¶

A rule tells iptables what to do with a packet that matches certain criteria. Every rule has two parts:

1️⃣ Matching criteria (what to look for)¶

• Source or destination IP address
• Protocol (TCP, UDP, ICMP)
• Source or destination port number
• Network interface (e.g., eth0, ens5)
• Connection state (NEW, ESTABLISHED, RELATED)

2️⃣ Target action (what to do)¶

• ACCEPT — Allow the packet through.
• DROP — Silently discard the packet.
• REJECT — Discard and send an error back to the sender.
• LOG — Log the packet and continue evaluating rules.
• RETURN — Stop processing this chain and return to the calling chain.

🛠️ How Rules Flow Through Chains¶

When a packet arrives at an AI server:

1. The packet enters the PREROUTING chain (nat table) if NAT is configured.
2. A routing decision determines if the packet is for the server itself or needs forwarding.
3. If for the server → packet goes to the INPUT chain (filter table).
4. If forwarded → packet goes to the FORWARD chain (filter table).
5. If leaving the server → packet goes to the OUTPUT chain (filter table).
6. Finally, the packet passes through the POSTROUTING chain (nat table) if needed.

🧪 Practical Example for AI Engineers¶

Imagine you have an AI inference server that should only accept SSH (port 22) and HTTP (port 80) traffic from your internal network (192.168.1.0/24).

The iptables approach would be:

• Table: filter (default)
• Chain: INPUT
• Rules:
• Allow all traffic from the internal network on port 22 (SSH)
• Allow all traffic from the internal network on port 80 (HTTP)
• Allow established connections (so responses can come back)
• Drop all other incoming traffic

For reference:

iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -j DROP

📤 Output: The server now only accepts SSH and HTTP from the internal network. All other incoming traffic is silently dropped.

🕵️ Key Takeaways for New Engineers¶

• iptables is stateless by default — you must explicitly allow return traffic using connection tracking (ESTABLISHED,RELATED).
• Order matters — place more specific rules before general rules.
• Default policy is ACCEPT — until you change it, all traffic is allowed. Always set a default DROP policy on INPUT and FORWARD chains for production AI servers.
• Changes are immediate — but not persistent. Use a tool like iptables-save and iptables-restore to make rules survive reboots.
• Test rules carefully — a bad rule can lock you out of your own server. Always test with a separate SSH session open.

🔐 Why This Matters for AI Infrastructure¶

AI servers often handle: - Large model weights being transferred between nodes - Sensitive training data from storage systems - Inference requests from external clients

Without proper iptables rules, an attacker could: - Exfiltrate model weights - Inject malicious data into training pipelines - Disrupt inference services with denial-of-service attacks

Mastering chains, tables, and rules gives you the foundational skill to build secure, production-ready AI infrastructure from the network layer up.