Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
Very similar too serverfault.com/questions/4934/… –  Zoredache May 11 '09 at 16:28
add comment

7 Answers

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
share|improve this answer
1  
I'll point out that this is Ubuntu-specific. For Red Hat and Fedora variants, you'll be looking at /etc/sysconfig/iptables instead. –  esm May 15 '09 at 14:07
    
You mean instead of /etc/iptables.rules? That is not determined by Ubuntu, I chose that myself. –  amarillion May 15 '09 at 19:22
4  
I was referring to the addition to /etc/network/interfaces; my apologies, I should have been more clear. Fedora and RHEL have an initscript (cleverly named "iptables" ;) that, if enabled, essentially does an iptables-restore of /etc/sysconfig/iptables. –  esm May 16 '09 at 0:05
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
I would be real careful with your naming in your Debian/Ubuntu example. This is the kind of place where you want to prefix your rule names with 00, 04, 22, etc. There's a lot of iptables rules that are order dependent, and if you load them in the wrong order, you're going to have broken stuff. I'd suggest storing them in a single file unless you really know what you're doing. –  Christopher Cashell Jun 4 '09 at 20:20
add comment

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.

share|improve this answer
6  
I disagree. The simple cases can easily be handled with the dedicated programs, but for a complex rule, I can't think of anything clearer than iptables (clearer meaning non-ambiguous, not necessary beginner friendly) –  Mikeage May 11 '09 at 12:11
2  
Depends on why you want to simplify the rules. I think the iptables.rules file can be perfectly readable. It's important to take advantage of the comment arguments to make sense of it all. –  spoulson May 11 '09 at 12:25
    
I disagree with your disagreement. If you focus on making your iptables commands readable you won't order them or use chains so the rules are as efficient as they could be. –  Zoredache May 11 '09 at 16:30
1  
Zoredache - I think Mikeage is more right than wrong here. iptables rules can be pretty unambiguous, even though they would be (for a less skilled person such as myself) hard to read. I don't think Mikeage was was going for easy to read. –  Michael Kohne May 15 '09 at 10:59
add comment

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/

share|improve this answer
    
On redhat you may also want to keep /etc/sysconfig/system-config-securitylevel up to date. This is where system-config-securitylevel-tui gets its rules from at startup.If you don't keep /etc/sysconfig/system-config-securitylevel up to date, if someone runs system-config-securitylevel-tui you may lose the rules stored in /etc/sysconfig/iptables. –  Jason Tan May 30 '09 at 16:32
add comment

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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.