Home / server / Questions / 6956
In Process
amarillion
Asked: 2009-05-12 03:05:16 +0800 CST

What is the canonical way to store iptables rules

  • 772

iptables, the standard Linux firewall, does not save rules between reboots. You have to take care of this yourself. There are many ways to do this. What is the canonical way to do this? What are best practices?

I'll answer with my own solution, but I'm interested in other / better solutions.

linux iptables

7 Answers

  1. Here are some example rules. Save them to /etc/iptables.rules

    # Generated by iptables-save v1.3.6 on Wed Oct 24 17:07:29 2007
*filter
:INPUT ACCEPT [89458:132056082]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [263904:15667452]
-A INPUT -i lo -j ACCEPT 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 
-A INPUT -j DROP 
COMMIT
# Completed on Wed Oct 24 17:07:29 2007

    add this line at the end of /etc/network/interfaces

    pre-up iptables-restore < /etc/iptables.rules
    • 6

  2. We use alot of iptables rules, so in order to ease administration we do the following:

    • Rules are all called from scripts - scripts are called from /etc/init.d/firewall (custom script)
    • A file of server names / network names (ip address variables) is kept, and included in every iptables script for consistency.
    • separate scripts are kept for each subnet (ie. private / DMZ / VPN, etc) to make things easier to find. Rules that belong in 2 scripts (such as those restricting communication b/w private and DMZ) are put in the more "secure" network's script
    • wherever possible, loops and nested loops are used to keep the scripts as short as possible.
    • every new rule or change is documented with comments preceding the appropriate section of the script.

    I don't know if this is the best way to do this, but it has worked well for us.

    • 4

  3. While it is true this is environment and platform dependent, I have seen two good approaches, depending on the platform:

    • RHEL / CentOS: store all rules in a single /etc/sysconfig/iptables file which is read in by the iptables startup script.

    • Debian/Ubuntu: store all rules in separate service-specific files in /etc/iptables.d/ directory. For example, /etc/iptables.d/port_http, /etc/iptables.d/port_dns, where port_service maps to a service name in /etc/services.

    In either case, the file or files are managed by a configuration tool like Chef or Puppet, and read in by the 'master' startup script for iptables that runs at boot time.

    • 3

  4. In addition to iptables-save (and iptables-restore), complicated firewall schemes are better handled with dedicated programs. For example, we've used shorewall ("iptables made easy") to configure iptables.

    Simpler tools are also available, like firestarter and kmyfirewall.

    • 1

  5. This is dependent on the distribution you use. Some distributions especially those based off a Red Hat distribution keep the iptables rules automatically but in there own special directory. I'm most familiar with RHEL and the iptables rules can be found at /etc/sysconfig/iptables. Becoming familiar with iptables rules syntax can be tricky at first but is quite easy once you get the hang of it.

    The netfilter website has a lot of documentation on iptables including some introductions. If your up for reading a bit you can find a lot of good information here: http://www.netfilter.org/documentation/

    • 1

  6. This question is very close to being a dup of 4934 and it is related to 397.

    I use firehol combined with a web interface that I developed to manage the configuration file.

    I really like firehol, it provides a simpler syntax then using iptables directly.

    • You can use the firehol debug command to exactly what iptables commands are generated
    • If you have an error in your configuration and you start the firewall, firehol detects the error and reverts to the previous state.
    • Firehol has a 'try' command which you can use to start the firewall remotely, if your changes kill your connection, firehol will revert to the previous state, if you didn't kill your connection then it will ask you to confirm the change.
    • Firehol has a large set of services pre-defined so you don't have to remember exactly what ports you have to have what ports to open for some obscure protocol.
    • 1

  7. We use a custom init-script, of course. I can use for-loops to iterate over a list of ports, parse other config files like the vpn-users, etc. Excellent!

    And iptables-restore is surely the most "canonical" way of saving it.

    What I want to add:

    Please note that current version of iptables will for every single invokation ask the kernel to give it back the full list of chains. Then it will make the one change you ask it to do. Then it will upload the list again.

    This is slow (O(n^2)), for us it needs 5 seconds which is too long ;-)

    If you use iptables-restore, it all goes through in one quick operation.

    • 1