[PATCH 0/3] iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

[PATCH 0/3] iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

[Peter Warasin]

Hi guys

This patchset introduces a new tool called iptables-edit, which allows
to apply iptables rules on an iptables-save'd state file 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 separate files.

The patchset is against iptables 1.3.8.

Please advice me if i should port it to another version or subversion
repository.

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

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   :: peter@endian.com

[PATCH 0/3] iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

[Peter Warasin]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

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   :: peter@endian.com

[-- Attachment #2: peter.vcf --]
[-- Type: text/x-vcard, Size: 279 bytes --]

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

Re: [PATCH 0/3] iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

[Max Kellermann]

On 2007/11/05 01:13, Peter Warasin <peter@endian.com> wrote:
[...]
> 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.

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.

[...]
> 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.

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

Max

Re: [PATCH 0/3] iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

[Jan Engelhardt]

On Nov 5 2007 01:13, Peter Warasin wrote:
>
>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.

fwbuilder uses (can use) iptables-save.

Re: [PATCH 0/3] iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

[Peter Warasin]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

Hi Jan

Jan Engelhardt wrote:
> On Nov 5 2007 01:13, Peter Warasin wrote:
>> Most firewall scripts (for example fwbuilder, shorewall, firehole,
>> etc..) work always this way:
> fwbuilder uses (can use) iptables-save.

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   :: peter@endian.com

[-- Attachment #2: peter.vcf --]
[-- Type: text/x-vcard, Size: 279 bytes --]

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

Re: [PATCH 0/3] iptables-edit: tool to apply iptables rules to iptables-save'ed statefiles

[Jan Engelhardt]

On Nov 7 2007 13:24, Peter Warasin wrote:
>Jan Engelhardt wrote:
>> On Nov 5 2007 01:13, Peter Warasin wrote:
>>> Most firewall scripts (for example fwbuilder, shorewall, firehole,
>>> etc..) work always this way:
>> fwbuilder uses (can use) iptables-save.
>
>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?.

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).

>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.

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.