Proper management of iptables?

[droopy4096]

for quite a while inside of our organization we've been editing /etc/sysconfig/iptables directly without much issues. However it was suggested to us that by doing so we risk losing all those rules whenever some package decides to use lokkit or "system-config-firewal*"

Several different sources suggested that modifying iptables on-the fly (via CLI) and then saving rules via

service iptables save

is a proper technique.

Doing a bit of analysis I can't really find any trace of code that would prevent us from maintaining iptables just the way we were (as long as *we* don't use lokkit or system-config-firewall*) since "service iptables save" is a valid technique and uses iptables-save script which is part of iptables package and *not* part of system-config-firewall*

So we've got some evidence that may confirm our usage as valid, however it would be nice to know if indeed this is *not* a recommended way of maintaining iptables and we should reconsider how we approach it.

[AndrewSerk]

Hello droopy4096,

I have been editing ..../iptables by hand for years without issue. It is a frowned upon way to configure/edit iptables, The file iptables even has a line in it that reads" # Manual customization of this file is not recommended" and for fun I change it to " # Manual customization of this file is not recommended unless U R me."
If you have not had any issues, why change? Unless I too am missing something

[jpollard]

Actually - it depends.

If you edit the file, and load the tables, then the file MAY be updated - but it will be updated to the rules currently loaded, which should be identical to what was in the file before the update - possibly missing comments.

The only time you will have problems is if you update the file, but don't update the system tables expecting that to happen on reboot.

The next reboot will not have the update.

This appears to be what happened to me a while back.

[AndrewSerk]

That makes sense and I could see where that could cause issues. I have got in the habit of editing the file > save > restart the service, and I haven't seen any issues (that I know of) from editing iptables this way.

[droopy4096]

yes, above is what we've been doing for quite a while now, however it never hurts to figure out current direction in that field to know what kind of minefield you're walking into

Overall it's not like we can't do it now, but more of whether there's some new/current development that may impact us in a big way.

Just like jpollard commented - using text file allows for comments etc. It looks like using lokkit for file inclusion is one way of doing it. Like for example have /etc/sysconfig/my.iptables and add it via

$ lokkit --custom-rules=ipv4:filter:/etc/sysconfig/my.iptables

but that would mean an extra step in workflow for changing firewall rules - run lokkit to re-compile /etc/sysconfig/iptables whereas path that wasn't cut off just yet with

$ iptables -A ....
$ service iptables save

is still open and lokkit plays no part in it.

[arifsaha]

Originally Posted by droopy4096

however it never hurts to figure out current direction in that field to know what kind of minefield you're walking into

I think that is the main question, will "power that be" move more and more to use lokkit, or keep the ambivalence of having 2 procedure that not compatible with each other, anybody knows?

Originally Posted by droopy4096

but that would mean an extra step in workflow for changing firewall rules - run lokkit to re-compile /etc/sysconfig/iptables whereas path that wasn't cut off just yet with

Actually there will be no extra step, just different one. If we edit
/etc/sysconfig/iptables directly, then we need to restart iptables service or do iptables-restore to load it into actual active iptables. With lokkit, we edit the file then run lokkit --enable which will do everything from compiling the rule, rewriting /etc/sysconfig/iptables, and activating the rules.

[jpollard]

And there is the conflict.

If one admn edits the iptables and loades it into memory, and another uses lockit --enable, which compiles and rewrites iptables (overwriting the first), and then activating (losing the first admins changes).

[beaker_]

If it's a relatively simple firewall where I don't need aliases or custom tables to keep it straight then I just save them as txt files and load them through system-config-firewall as a 'custom script.'

Edit:
First file flushes the tables... second file sets the policies... third file depends on what it is I want or need to accomplish..... could be a ninth it needed.

[droopy4096]

Originally Posted by jpollard

And there is the conflict.

If one admn edits the iptables and loades it into memory, and another uses lockit --enable, which compiles and rewrites iptables (overwriting the first), and then activating (losing the first admins changes).

Multiple admin using the box is less of an issue - this can be covered in verbal/written agreement not to do it. What I'm more curious about is non-explicit use of such tools, like during software installs/upgrades etc.

I wonder if any Fedora devs hang around here to sched some light on the Fedora policy (which so far is pretty vague and non-explicit if documentation is what represents it):

http://docs.fedoraproject.org/en-US/...les_Rules.html

While it is always a good idea to test a new iptables rule before committing it to the /etc/sysconfig/iptables file, it is possible to copy iptables rules into this file from another system's version of this file. This provides a quick way to distribute sets of iptables rules to multiple machines.

so above implies that playing with /etc/sysconfig/iptables is not too much of no-no it doesn't say explicitely whether anything beyong copy-pasting of those files is permitted (which by extension I'd say "yes" but that's me).

while documentation on /etc/sysconfig omits iptables file altogether:
http://docs.fedoraproject.org/en-US/...Directory.html

[flyingfsck]

I simply keep a tar ball of the whole /etc in the /root directory as a backup.