1. The Netfilter Subsystem: Tables and Chains
Linux packet filtering operates inside the kernel via the netfilter framework, configured in user space through the iptables utility.[1] Packets traversing network interfaces encounter decision points organized into tables and sequential chains.[1] Selecting the correct table determines how the kernel parses, alters, or evaluates each network frame.[1]
Five independent tables structure packet manipulation: filter, nat, mangle, raw, and security. The filter table represents the default operational namespace when no -t flag is passed, holding primary built-in chains: INPUT for packets addressed to local sockets, FORWARD for packets routed across interfaces, and OUTPUT for locally originating transmissions. Network address translation takes place in the nat table during connection initialization across PREROUTING, INPUT, OUTPUT, and POSTROUTING chains. Specialized byte alteration uses the mangle table, while the high-priority raw table processes packets before conntrack hooks evaluate state.[1]
+-----------------------------------------------------------------------+
| Network Interface |
+-----------------------------------------------------------------------+
|
v
+-----------------------+
| raw: PREROUTING |
+-----------------------+
|
v
+-----------------------+
| conntrack tracking |
+-----------------------+
|
v
+-----------------------+
| nat: PREROUTING |
+-----------------------+
|
v
[ Routing Decision ]
/ \
[ Local Destination ] [ Forwarded Traffic ]
/ \
v v
+--------------------+ +--------------------+
| filter: INPUT | | filter: FORWARD |
+--------------------+ +--------------------+
| |
v v
[ Local Applications ] [ Routing Decision ]
| |
v |
+--------------------+ |
| filter: OUTPUT | |
+--------------------+ |
\ /
\ /
v v
+-----------------------+
| nat: POSTROUTING |
+-----------------------+
|
v
[ Outbound Wire ]2. Stateful Inspection with the Conntrack Engine
Stateless firewalling evaluates headers in isolation, requiring administrators to open bidirectional ports for ephemeral response sockets. Modern stateful filtering uses the netfilter conntrack module to trace packet session state.[5] The -m conntrack --ctstate extension inspects whether an inbound datagram belongs to an established exchange, matches an expected related negotiation, or represents a new connection attempt.[5]
Rules classify packets into discrete states: NEW, ESTABLISHED, RELATED, INVALID, and UNTRACKED.[5] Packets matching INVALID cannot be associated with a known connection or violate sequence or window boundaries; dropping them prevents malformed or out-of-order packets from reaching higher layer stacks, though it does not replace higher-level transport verification.[5] Established traffic matching ESTABLISHED,RELATED bypasses subsequent per-rule evaluations, accelerating throughput for active SSH, database, and HTTP flows.[5]
# Discard packets that fail connection tracking validation
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
# Unconditionally accept established and related session traffic
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Accept internal traffic traversing the loopback interface
iptables -A INPUT -i lo -j ACCEPT3. Remote Lockout Prevention: The iptables-apply Mechanism
Applying firewall policies on a remote cloud server across an active SSH connection carries operational risk. A single error in an interface name, CIDR subnet, or default policy can block remote management access, requiring hosting provider out-of-band console intervention.[4]
The Netfilter toolchain provides iptables-apply to reduce lockout hazards during remote reconfigurations.[4] When invoked, iptables-apply activates the proposed ruleset and prompts the interactive terminal for explicit administrator confirmation.[4] If the newly committed rules block SSH traffic, the prompt cannot be answered; the utility detects the timeout and rolls the kernel tables back to the previous known-good state.[4]
Crucial Operational Trap: An existing SSH session in which iptables-apply runs is already an ESTABLISHED connection. If a rule incorrectly drops new SSH handshakes on port 22 or a custom port, the existing prompt continues to accept keystrokes because it matches the ESTABLISHED,RELATED -j ACCEPT rule! Confirming the prompt based solely on the current session staying connected will lock you out the moment you disconnect. Always open a secondary, independent SSH connection in another terminal window to verify new connections succeed before confirming the prompt.[4][5]
# Ensure iptables-apply is installed on your host first
which iptables-apply || sudo apt-get install -y iptables
# Test new rules with a 15-second safety fallback timeout
iptables-apply -t 15 -w /etc/network/iptables.save /etc/network/iptables.test.rules
# Inside another local terminal, open a NEW SSH session to verify:
# ssh -p <configured-port> user@server-ip
The default rollback timer is 10 seconds, but administrators can tune this via the -t seconds parameter to accommodate latency on remote links.[4] Successfully confirmed policies can be saved directly to a designated persistent path using the -w savefile flag, maintaining a reliable audit trail of working system configurations.[4]
4. Atomic Serialization with iptables-save and iptables-restore
Modifying firewall rules sequentially with individual iptables -A or iptables -I shell commands creates non-atomic intermediate states. During the execution gap between flushing an existing chain and inserting replacement policies, the host can operate in an exposed state. Furthermore, high-frequency command execution incurs kernel context switches and xtables lock contention.[1][3]
Production system engineering relies on atomic updates using iptables-save and iptables-restore.[2][3] Note that in the traditional xtables framework, atomicity is guaranteed per-table rather than across all distinct tables simultaneously; each table is committed in a single kernel transaction. Systems using the modern nftables backend (e.g., iptables-nft) benefit from full transaction management across tables.[1][3]
The iptables-save utility dumps the running configuration of kernel tables into a parseable text format on standard output. Conversely, iptables-restore ingests this specification file, takes an exclusive lock on /run/xtables.lock, validates syntax, and commits the table structure in a single kernel operation.[1][3]
# Ensure target destination directory exists before redirecting
mkdir -p /etc/iptables
# Dump running IPv4 firewall ruleset to an archive file
iptables-save -c > /etc/iptables/rules.v4
# Verify syntax without committing changes to kernel memory
iptables-restore --test < /etc/iptables/rules.v4.new
# Atomically commit rules while preserving byte and packet counters
iptables-restore --counters < /etc/iptables/rules.v4.new
The -t or --test parameter allows administrators and deployment scripts to parse and validate ruleset syntax without touching kernel structures, catching formatting errors before production traffic is impacted.[3] When multiple automation processes interact with packet filtering, the -w seconds option instructs the utility to wait for the exclusive xtables lock rather than failing abruptly.[3]
5. Baseline Single-Host IPv4 Filtering Example
A standard host firewall operates under a default DROP posture on input chains.[1] Ports and protocols remain closed by default, requiring explicit allowlisting based on connection state, protocol, and destination port.[5] This configuration represents a baseline standalone IPv4 example for a server with public HTTP/HTTPS endpoints and SSH administration:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
# 1. Loopback Interface
-A INPUT -i lo -j ACCEPT
# 2. State Tracking: Discard Invalid, Accept Established/Related
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 3. Allow Essential ICMP (Ping & Path MTU Discovery)
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
-A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/sec --limit-burst 10 -j ACCEPT
# 4. Inbound Public Services (HTTPS & HTTP)
-A INPUT -p tcp -m tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
# 5. Protected Management Access (SSH: Verify port before applying!)
# Replace 22 with your actual SSH port from sshd_config
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --set --name SSH_BURST
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -m recent --update --seconds 60 --hitcount 4 --name SSH_BURST -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
# 6. Reject Logging (Rate-limited audit before final drop)
-A INPUT -m limit --limit 3/min --limit-burst 5 -j LOG --log-prefix "IPTABLES-DROPPED: " --log-level 4
-A INPUT -j DROP
COMMIT
Notice the inclusion of ICMP destination-unreachable datagrams.[1] Indiscriminately dropping all ICMP packets breaks Path MTU Discovery, causing encrypted TLS handshakes and large TCP packets to hang indefinitely across networks with smaller maximum transmission units. Rate limiting echo requests provides basic control against simple ping sweeps, though volumetric denial-of-service attacks must be mitigated at network edge or upstream scrubbing providers rather than local iptables rules.[1]
6. Verification and Troubleshooting Checklist
Before committing firewall rules to permanent boot configuration, run through the following operational verification steps:
- Out-of-Band Access Ready: Confirm server console access (VNC/KVM/serial) via your cloud hosting provider dashboard before applying rules.[4]
- Verify Real SSH Port: Check active SSH port with
ss -tlnp | grep sshdand ensure the ruleset matches the active port. - Directory Existence: Ensure destination directories (such as
/etc/iptables) exist before redirecting file output.[2] - Rule Listing and Counter Inspection: Inspect packet counters using
iptables -v -n -Lto verify that valid packets incrementACCEPTchains while dropped packets incrementDROPcounters.[1] - Test Dry Run: Always invoke
iptables-restore --teston new configuration files before reloading production rules.[3] - Lockout Safeguard: Run
iptables-applywith a 15-second safety window, and test a brand-new independent SSH connection before answering the prompt.[4][5] - Persistence Verification: Ensure persistent rule managers such as
iptables-persistentor custom systemd services restore the validated file at boot without syntax truncation.[3]