iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

Hi guys

I resend this patchset because i ported it from 1.3.8 to the current subversion revision 7086 and did some minor changes. I also explain more of it's advantages at the end of this mail.

This patchset introduces a new tool called iptables-edit, which allows to apply iptables rules on an iptables-save'd state file (dump) instead of applying it to the kernel.

This allows to minimize the outage of firewall script which rebuild the entire ruleset from scratch when something changed within it's configuration.

It uses functionality from iptables-save and iptables-restore, therefore the patchset reorganizes those functionality in a separate file iptables-dump.c

I will start with man page and ip6tables-edit as well if the patch makes sense to you.

Let me do an example and better explaination of the advantages:

--------------------------------------------------------------------

$ iptables-save > netfilter.dump
$ cat dump
# Generated by iptables-save v1.4.0rc1 on Mon Nov  5 00:29:41 2007
*filter
:INPUT ACCEPT [17577:13507071]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [19227:2350905]
COMMIT
# Completed on Mon Nov  5 00:29:41 2007

now you want to apply these rules on the file netfilter.dump:

$ cat > rules << EOF
iptables -N test
iptables -A test -p tcp --dport 80 -j DROP
EOF

$ iptables-edit -i netfilter.dump < rules > netfilter_edited.dump
$ cat netfilter_edited.dump
# Generated by iptables-save v1.4.0rc1 on Mon Nov  5 00:33:33 2007
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:test - [0:0]
-A test -p tcp -m tcp --dport 80 -j DROP
COMMIT
# Completed on Mon Nov  5 00:33:33 2007

now you can atomarily commit all the rules at once to the kernel using

$ iptables-restore netfilter_edited.dump

--------------------------------------------------------------------

Most firewall scripts (for example fwbuilder, shorewall, firehole, etc..) work always this way:
- They flush and remove all iptables chains
- Apply the iptables rules successively by:
o Compile a shell script with an iptables rule per line
o Calculating the iptables rules from a configuration file on the fly.

Both possibilities have the disadvantage that they cause a network outage between flush and re-creation of the rules, which can loosely be a couple of seconds (which in many cases is way to much outage).

Imagine of the shell overhead which causes the execution of the iptables tool when called a several hundreds of times when hundreds of rules need to be applied.

iptables-edit allows those scripts to apply the changes to a dump file first and apply then with iptables-restore at once with an outage of a few milli seconds.

Another advantage could be something like this:

$ iptables-restore netfilter_edited.dump && sleep 10 && \
iptables-restore netfilter.dump

which automatically would jump back to the old ruleset if the administrator did something wrong and locket out himself.

Please let me know what you think

Regards,
peter

:: e n d i a n
:: open source - open minds

:: peter warasin
:: http://www.endian.com   :: [email protected]

begin:vcard
fn:Peter Warasin
n:;Peter Warasin
org:Endian GmbH/Srl
adr:;;Pillhof 47;Frangart/Frangarto;BZ;I-39010;Italien/Italia email;internet:[email protected]
tel;work:+39 0471 631763
tel;fax:+39 0471 631764
x-mozilla-html:FALSE
url:http://www.endian.com
version:2.1
end:vcard

On 2007/11/05 01:13, Peter Warasin <[email protected]> wrote:
[...]

I'm taking the chance to move some attention to my "ferm" project (which you did not mention): ferm uses iptables-restore to install the new rules atomically.

http://ferm.foo-projects.org/

ferm does not do that by default (yet), because iptables versions prior to 1.3 were too bugged for that to work properly - you have to run "ferm --fast" to take advantage of atomical iptables-restore.

[...]

This is implemented in ferm as "interactive" mode (ferm --interactive).

Max

fwbuilder uses (can use) iptables-save.

Hi Jan

I see, cool! I missed that one the last time i tried. Think i should give it another try.

At the other hand it's a compiler, which rebuilds from scratch, isn't it?. Another advantage (can also be a disadvantage) is that iptables-edit don't rebuild the entire firewall ruleset from scratch, so one can have it's manually added iptables rules which then do not disappear after next iptables-restore.

Furthermore option handling will be done by iptables extensions itself and it's not necessary anymore to separately implement it within the compiler. Could be an advantage.

peter

:: e n d i a n
:: open source - open minds

:: peter warasin
:: http://www.endian.com   :: [email protected]

begin:vcard
fn:Peter Warasin
n:;Peter Warasin
org:Endian GmbH/Srl
adr:;;Pillhof 47;Frangart/Frangarto;BZ;I-39010;Italien/Italia email;internet:[email protected]
tel;work:+39 0471 631763
tel;fax:+39 0471 631764
x-mozilla-html:FALSE
url:http://www.endian.com
version:2.1
end:vcard

Yes, like most other compilers (e.g. C/C++) do, it turns a list of "GUI rules" into implementation-specific (e.g. iptables) commands. I would not even see why it would have to use iptables-edit (not that it would be useless, but translators do not need it).

GUI progs generally do not support modifying a "running table" (the one the kernel uses), exactly because you do not know which rules are automatically generated and which are not. Which is why you will have to add your custom rules inside the GUI.