Defining network firewall policies is a crucial security responsibility for Linux server administrators. The Netfilter/iptables framework built into the Linux kernel provides powerful in-kernel packet filtering capabilities for implementing firewall rulesets. However, iptables policies defined interactively are held in memory and lost after a system reboot by default. The iptables-save utility offers the ability to persist iptables rules to disk, for reliable reloading after restarts. This guide covers practical examples for creating iptables rulesets and utilizing iptables-save for administration and durability across availability events.
About the Netfilter/iptables Framework
The Linux kernel includes the Netfilter software framework for monitoring and manipulating network traffic at the IP packet level. Core Netfilter hooks are built into the networking stack, allowing kernel modules to register functions triggered for each packet, without compromising performance.
iptables is the userspace tool for inspecting and manipulating filtering rules managed by the kernel packet filtering module.ABASE. Each table contains builtin chains, and users can also create custom chains:
| Table | Default Chains |
|---|---|
| Filter | INPUT, FORWARD, OUTPUT |
| NAT | PREROUTING, INPUT, OUTPUT, POSTROUTING |
| Mangle | PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING |
| Raw | PREROUTING, OUTPUT |
The filter table is most commonly used and contains policies for traffic traversing local system network interfaces. The NAT table alters source/destination IP addresses and ports to accomplish Network Address Translation tasks. Rules may be inserted to ACCEPT, DROP, REJECT, LOG, or Jump to another chain containing supplemental rules.
Additional Netfilter modules add capabilities like state tracking, bandwidth limiting, and mangling packet headers. Frameworks extending iptables functionality include ebtables (Ethernet bridging), arptables (ARP), and nftables among others.
Viewing Current iptables Policies
Review current iptables rules using various listing options. For example, show numeric IP addresses (-n) and verbose stats per rule (-v):
# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destinationWith no rules inserted yet, default policy accepts related and established input traffic, then drops everything else.
Adding and Manipulating iptables Rules
Insert a new rule blocking source IP 1.2.3.4 from sending any incoming traffic:
# iptables -A INPUT -s 1.2.3.4 -j DROPAppend (-A) this DROP rule for all protocols to the INPUT chain. List rules again:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DROP all -- * * 1.2.3.4 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Additional useful iptables options include:
- -D – Delete rule by line number
- -I – Insert as rule N
- -R – Replace existing rule
- -F – Flush all rules in chain
- -P – Set chain policy
- -S – Show rules as iptables-save format
- -Z – Zero counters
For example, change default input policy to DROP instead of ACCEPT:
# iptables -P INPUT DROP Sets policy to drop everything except matching rules.
iptables allows powerful controls – but by itself rules are transient, only held in memory.
Saving iptables Rules for Restoration
Export current in-memory rules using iptables-save:
# iptables-save > /etc/iptables.rulesThis writes a file /etc/iptables.rules containing a snapshot of the current iptables state, which can be restored on reboot:
# iptables-restore < /etc/iptables.rulesTo test, flush existing rules then list again:
# iptables -F
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destinationNow restore saved rules:
# iptables-restore < /etc/iptables/rules
# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
DROP all -- 1.2.3.4 anywhere
DROP all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination Blocking traffic from 1.2.3.4 is reloaded from rules file.
Additional iptables Capabilities
Connection tracking and NAT modules add significant functionality.
Connection Tracking and State
Netfilter includes connection tracking of related packets via conntrack modules. The state match extension classifies flows as NEW, ESTABLISHED, RELATED, or INVALID based on this tracking rather than just the 5-tuple of IPs, ports and protocol.
For example, accept established/related flows regardless of source while dropping invalid packets:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m state --state INVALID -j DROP Saving and restoring connection state table with rules ensures consistent behavior.
Source and Destination NAT
Destination NAT (DNAT) and Source NAT (SNAT) alter packet addressing appropriate for public/private IP masking.
Forward and NAT tables interact for dual-homed firewall configurations. For example public->private DNAT:
iptables -t nat -A PREROUTING -i eth0 -d 123.123.123.123 -j DNAT --to 192.168.1.5
iptables -A FORWARD -d 192.168.1.5 -j ACCEPTThis exposes internal host 192.168.1.5 on external IP 123.123.123.123.
Saving/restoring NAT associations ensures uninterrupted mappings after restarting the firewall.
nftables vs Legacy iptables
The nftables framework seeks to replace iptables, ebtables, arptables and ip6tables with a unified single tool using a ruleset format optimized for both simplicity and capabilities. Reaction has been mixed from Linux distributions and administrators. Compared to the iptables ecosystem built up over decades, nftables has tradeoffs:
nftables Advantages:
- Performance – faster path through simplified in-kernel rulesets
- Flexibility – expressive rule definitions in one utility
- Consistency – Common syntax/logic for IPv4, IPv6, Ethernet, ARP
iptables Advantages
- Maturity – Longstanding well-understood capabilities
- Compatibility – Most existing Linux firewalls utilize iptables
- Networking Stack Integration – Tight integration with routing, mangling
Ongoing Linux kernel improvements focus on backporting nftables performance gains while maintaining legacy iptables compatibility support. This preserves the reliability of existing iptables rulesets while allowing newer applications to transition to nftables where appropriate.
Additional Wrapper Tools
Several open source tools have emerged to assist managing iptables policies:
| Tool | Description |
|---|---|
| ferm | Language expressing rules declaratively vs imperatively |
| shorewall | Specialized firewall builder with conventions |
| puppet/ansible | Declarative firewall management via config modules |
These tools can ease constructing and deploying complex iptables rulesets. However, understanding raw iptables and iptables-save capabilities remains essential for debugging or extending beyond canned configurations.
Cloud IaaS Firewall Services
Leading public cloud platforms offer managed virtual firewalls limiting ingress/egress networking rules, port ranges, and protocols between instances and VPC networks.
Amazon Web Services Security Groups associate EC2 instances with filtering policies resembling libvirtd configurations or iptables rules. However, these lack ability to inspect application layer protocols or payload contents beyond basic TCP/IP stack attributes. Deep packet inspection requires diverting traffic through third party virtualized firewalls.
Azure, Google Cloud, and other IaaS providers deliver similar instance-attached virtual firewall services focused on Instance metadata attributes. This favors simplicity over depth when restricting VM access permissions.
For Linux administrators comfortable directly coding software defined networking policies with iptables, migrating wholesale to cloud service providers relinquishes that precision control. Maintaining a hybrid on-premises deployment mix, workload permitting, retains visibility into transport and application layers.
Conclusion
iptables provides the primary interface for directly managing Linux firewall policies as an integral component of the Netfilter packet filtering framework. Changes put into effect imperatively are volatile – stored only in memory and lost across system restarts. The iptables-save allows capturing point-in-time rulesets for reliable reloading using iptables-restore, avoiding manual recreation of complex policies. This guide covers practical use of these tools in addition to typical iptables insertions.
Additional related capabilities around connection tracking and NAT address translation also depend on saved iptables state for consistent behavior after availability events. Backup and restoration prevents dangling references or broken mappings as servers restart. Shared hybrid cloud configurations warrant maintaining on premises footholds to escape limitations of simplistic virtual firewall rulesets attached to transient auto-scaling instances.
The flexibility and maturity of iptables has yet to be completely supplanted by alternatives like nftables despite performance advantages. Linux distributions remain committed to supporting persistence of existing iptables firewall investments while evaluating potential next generation replacements.
