iptables Options in RHEL/CentOS
Today in class we were talking about how you needed to save your iptables changes using service iptables save before rebooting at the end of the test, or else you'll fail that section of the test. I brought up the setting IPTABLES_SAVE_ON_STOP to "yes" in /etc/sysconfig/iptables-config, and no one else knew about that file. There's some pretty cool settings in there - read on for details.
The file /etc/sysconfig/iptables-config provides a place to configure the behavior of the iptables initscript in /etc/init.d/iptables. The file is documented very well, so give it a quick read. Here's some of the more interesting settings:
- IPTABLES_SAVE_ON_STOP - this defaults to "no". When set to "yes", every time the initscript is called with the argument of "stop" (whether via command line or via system shutdown), the initscript will take the current iptables ruleset and dump it into /etc/sysconfig/iptables. Essentially, this is doing a service iptables save behind the scenes when you do a service iptables stop. This is great for sysadmins who get distracted often and forget to commit their iptables commands to persistent storage often.
- IPTABLES_SAVE_ON_RESTART - defaults to "no". When set to "yes", it does the exact same thing as IPTABLES_SAVE_ON_START except this does a save operation when the initscript is called with the "restart" option.
- IPTABLES_SAVE_COUNTER - defaults to "no". Everytime service iptables save is called (including in the two cases above), the rule and chain counters are saved to the file, and restored on startup. This prevents your counters from being reset every time you restart the service.
- IPTABLES_STATUS_NUMERIC - defaults to "yes". When you do a service iptables status, this will print IP's instead of hostnames when set to "yes". When set to "no", it will do reverse DNS lookups on all the IP's and /etc/services lookups on all ports.
- IPTABLES_STATUS_VERBOSE - prints packet and byte counters in the output of service iptables status.
There's a few other settings in there, but these are the ones that I'm usually interested in. Happy firewalling!

Comments
alternative method for using iptables on the rhce exam
i believe i've found a simpler method for using iptables on the rhce exam. just edit /etc/sysconfig/iptables manually, then run "/etc/init.d/iptables restart" to apply your changes. i prefer this method, because it frees me from having to memorize iptables command line options (which i will never use in the real world anyway, since i prefer to manage one centralized hardware firewall rather than many individual software firewalls). just base your additional rules on the default ssh rule (i.e. copy and paste).
if you use this method, the only thing you need to remember is that you cant use any other method to edit this file (e.g. system-config-securitylevel, "service iptables save," etc.). doing so will completely overwrite the file.
That's actually how I've
That's actually how I've always done it on Red Hat distros. While a system-config-securitylevel will blow away your changes, you actually can do a "service iptables save", provided you've done a "service iptables restart" since you edited the file. The save option takes the currently loaded iptables config and dumps it to the file.
Some words of caution
There are a few reasons you might not want to have the running iptables rules saved at restart or stop.
If you have someone making modifications to the running rules and they attempt to "reset" the rules to remove their changes, they may use restart obviously not having the desired effect.
You make a change to the running rules and discover you accidentally locked yourself out. If you don't have console(surprising common occurrence in many environments), hopefully you at least have the ability to reboot/power-cycle the server, restoring the old iptables rule set.
I have found that when you have more than one person potential working on a server, not requiring changes to configurations being explicitly made leads to many headaches. Just suggesting that you think about potential consequences when changing default behavior on a system. Particularly important in some environments.
Post new comment