Mailing List Archive

On Thu, 2007-08-23 at 17:32 -0700, Alex Tang wrote:
> Hi folks,
>
> We run a linux based product (RHEL4 based, kernel-2.6.9-55, and
> iptables-1.2.11). During the running of the product, when we make
> changes to the iptables configuration, we use the SysV-like RHEL script
> "/etc/init.d/iptables restart", which effectively stops iptables,
> unloads all of the iptables based kernel modules, then starts iptables
> and all the kernel stuff.
>
> A colleague recently asked why we're not using "iptables-restore"
> instead of the script which does "stop/start". I'm looking to see if
> you know of any reasons why we should or should not use iptables-restore
> vs. "stop/start". Does it matter if the number of connections on the
> system is high? Our product can sometimes handle many millions of
> connections per day.
>
> Thanks.
>
> ...alex...
>
>
There is a dramatic difference in the time it takes to load the rules
and rule changes. In the ISCS network security management project
(http://iscs.sourceforge.net), we frequently generate rule sets in the
tens of thousands of rules and rule change sets in the thousands of
rules to implement micro-partitioned, highly granular security. We
found using just iptables was a showstopper.

Thus, ISCS not only loads its boot rule set using iptables-restore but
even makes dynamic changes by writing an iptables-restore rule file and
loading it via iptables-restore -n.

Hope that helps - John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com

Hi there,

On Sat, 25 Aug 2007 Alex Tang wrote:

> We run a linux based product (RHEL4 based, kernel-2.6.9-55, and
> iptables-1.2.11).

Both versions sound a little old but I guess the guys at RH know what
they're doing.

> During the running of the product, when we make changes to the
> iptables configuration, we use the SysV-like RHEL script
> "/etc/init.d/iptables restart", which effectively stops iptables,
> unloads all of the iptables based kernel modules, then starts
> iptables and all the kernel stuff.

There's no iptables 'daemon', the iptables binary just modifies some
table in the kernel, so the script in init.d doesn't really stop (nor
start) anything. The script probably just removes all the rules and
replaces them. While you have no rules in the tables, you might have
no firewalling!

> A colleague recently asked why we're not using "iptables-restore"

I might have asked the same question. :)

> I'm looking to see if you know of any reasons why we should or
> should not use iptables-restore vs. "stop/start". Does it matter if
> the number of connections on the system is high?

It depends what you're doing, what you want to know, exactly what's in
the script, and who is trying to do what to your machine. You won't
break any connections if you delete the rules in the kernel's table
using the iptables command, but you might break them if you add rules
which prevent packets reaching their destination when your previous
rules allowed them. I'd feel exposed if my start-stop script was
allowing unlimited access to a machine of mine even for brief periods.

We have tens of thousands of rules, and we also log packet and byte
counts. Using simple scripts like those found in many distros isn't
an option for us on performance grounds alone (iptables is notoriously
slow to insert large numbers of rules) and using the '-c' option of
iptables-restore allows us to maintain the packet and byte counts.

The iptables kernel code is very slow to process packets through large
rulesets unless you use something like ipsets. Performance with a few
hundred rules might be acceptable but if you have many more rules than
that, and if you have a lot of traffic, you should probably be looking
at better ways of doing it. There are quite a few good reports on the
performance of iptables and other packet filtering tools. Google will
find them for you.

Our rules are dynamically modified by scripts which call the iptables
and ipset binaries to add/delete individual rules. Rulesets with
thousands of entries (generally blocking sources of network abuse) are
handled using ipset, rulests with small numbers of entries (things like
permitting ssh access for our remote users) by iptables. Rulesets are
saved periodically as a backup by iptables-save (also ipset --save),
running from the crontab. At boot time (i.e. at least once a year:)
the rulesets are restored from the backups using iptables-restore and
ipset --restore.

Unfortunately using ipsets means patching the kernel, that might not
be an option for you unless either RH have included the appropriate
patches in their kernel or you're prepared to build your own (and no
doubt lose some RH support).

--

73,
Ged.

Alex Tang wrote:
> Hi folks,
>
> We run a linux based product (RHEL4 based, kernel-2.6.9-55, and
> iptables-1.2.11). During the running of the product, when we make
> changes to the iptables configuration, we use the SysV-like RHEL
> script "/etc/init.d/iptables restart", which effectively stops
> iptables, unloads all of the iptables based kernel modules, then
> starts iptables and all the kernel stuff.
> A colleague recently asked why we're not using "iptables-restore"
> instead of the script which does "stop/start". I'm looking to see if
> you know of any reasons why we should or should not use
> iptables-restore vs. "stop/start". Does it matter if the number of
> connections on the system is high? Our product can sometimes handle
> many millions of connections per day.

The RHEL start/stop scripts do use iptables-save and -restore. They are
as efficient as they can be.

HTH,
M4