Automatically restore firewall filter rules
Reloaded

© Lead Image © stylephotographs, 123RF.com
The Linux iptables packet filter lacks an easy way to load rules automatically after restarting a system, but you can automate this process several ways.
Every administrator has to determine how to protect a network reliably against unauthorized access and ensure that the (sub)network fulfills its task as expected and is not misused as a starting point for malicious activities. At the network level, you have various ways and means at your disposal, including, for example, managing credentials for authenticating users (e.g., via PAM and LDAP), the appropriate selection of correctly configured services, and correct network device configurations.
Routers and firewalls are often used to isolate individual network segments, and the Linux kernel manages the firewall rules in the system's RAM. I demonstrate different methods for permanently storing your firewall settings by using iptables, thus removing the need to enter them again whenever you reboot.
Firewall Protection
From a network perspective, a firewall's primary objective is selecting and limiting the network packets that reach a network via a monitored interface on another network. In practice, firewalls are deployed not only as software directly on the system to be protected, but also in the form of separate hardware appliances that often combine various services under one roof.
In short, a firewall is a packet filter. Filtering is performed, for example, on the basis of (1) the IP address, (2) the connection state, (3) the MAC address, or (4) the payload of a packet.
The iptables
package by the Netfilter project [1] includes the iptables
command, which covers cases 1 and 2; for case 3, ebtables
[2] steps in. In the future, nftables
will combine the iptables, ip6tables, ebtables, and arptables projects under one roof. For case 4, evaluating and limiting user traffic, you need an application-level firewall, such as the Squid [3] proxy. In this article, I only look at iptables.
Operations
The iptables
command works in chains with rules (filters) and actions (targets). On the basis of these criteria, the software fields packages (ACCEPT
) and discards (DROP
or REJECT
) or forwards and rewrites them (MASQUERADE
).
Listing 1 shows a typical call sequence. In this example, only connections via port 22 with a source IP address between 192.168.45.0 and 192.168.45.255 are allowed to pass. The entry in line 1 clears all the existing rules; the commands in lines 2 to 4 set the default behavior.
Listing 1
Typical iptables
Line 5 adds a filtering rule to the chain for received packets. This limits the accepted packages (-j ACCEPT
) to TCP packets (-p tcp
) for the target port 22 (--dport 22
) from the subnet 192.168.45.x (-s 192.168.45.0/24
). Line 6 allows also the corresponding response packets (-j ACCEPT
) – original from port 22 here (--sport 22
) to the target network 192.168.45.x (-d 192.168.45.0/24
) and only for existing connections (--state ESTABLISHED
).
To apply these commands to IPv6, you need to use the new ip6tables
, which uses the same syntax.
Validity
As mentioned previously, the iptables rules apply only as long as the system is running. The software does not store the rules persistently; it only keeps them in main memory. If you turn off the computer or reboot it, the current firewall settings will be lost. To prevent having to enter them every time you reboot, you need to store the rules permanently and enable them automatically when the computer starts up.
The variants discussed here are based on my own experience and the firewall entries from the Debian wiki [4]. The intent was to use only built-in tools. The variations also show a selection of solutions – you can decide which best fit your purposes.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Red Hat Migrates RHEL from Xorg to Wayland
If you've been wondering when Xorg will finally be a thing of the past, wonder no more, as Red Hat has made it clear.
-
PipeWire 1.0 Officially Released
PipeWire was created to take the place of the oft-troubled PulseAudio and has finally reached the 1.0 status as a major update with plenty of improvements and the usual bug fixes.
-
Rocky Linux 9.3 Available for Download
The latest version of the RHEL alternative is now available and brings back cloud and container images for ppc64le along with plenty of new features and fixes.
-
Ubuntu Budgie Shifts How to Tackle Wayland
Ubuntu Budgie has yet to make the switch to Wayland but with a change in approaches, they're finally on track to making it happen.
-
TUXEDO's New Ultraportable Linux Workstation Released
The TUXEDO Pulse 14 blends portability with power, thanks to the AMD Ryzen 7 7840HS CPU.
-
AlmaLinux Will No Longer Be "Just Another RHEL Clone"
With the release of AlmaLinux 9.3, the distribution will be built entirely from upstream sources.
-
elementary OS 8 Has a Big Surprise in Store
When elementary OS 8 finally arrives, it will not only be based on Ubuntu 24.04 but it will also default to Wayland for better performance and security.
-
OpenELA Releases Enterprise Linux Source Code
With Red Hat restricting the source for RHEL, it was only a matter of time before those who depended on that source struck out on their own.
-
StripedFly Malware Hiding in Plain Sight as a Cryptocurrency Miner
A rather deceptive piece of malware has infected 1 million Windows and Linux hosts since 2017.
-
Experimental Wayland Support Planned for Linux Mint 21.3
As with most Linux distributions, the migration to Wayland is in full force. While some distributions have already made the move, Linux Mint has been a bit slower to do so.