All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mart Frauenlob <mart.frauenlob@chello.at>
To: netfilter@vger.kernel.org
Subject: Re: iptables rules in comparable form
Date: Tue, 01 Jun 2010 15:27:58 +0200	[thread overview]
Message-ID: <4C050ADE.60403@chello.at> (raw)
In-Reply-To: <20100601112552.GA15745@q.uh.cz>

On 01.06.2010 13:26, rk@dat.cz wrote:

> I should clarify some facts about my conditions.
> 
> Whole iptables ruleset is represented by few files in /etc. Some of them
> are generated, some of them are hand written. I am able to feed /etc
> rules to iptables-restore or execute them as shell script. This is
> trivial. Although iptables-restore is faster than executing iptables in
> shell script, it is still very slow sometimes. Changes in /etc ruleset
> are small but frequent. But primarily both solutions reset couters if
> used and it is not good for me now. So I ended with script that does
> incremental updates.

iptables[-save/restore] have a -c switch to save/restore counters.


> 
> My script takes iptables-save output as first argument and desired
> ruleset declared in /etc files as second argument (but generally any two
> inputs). In first step it converts both inputs to comparable form and
> builds ruleset in internal representation. Then comes iptables_diff
> method, that is able to generate two rules
> 
>     iptables -D SSH 10
>     iptables -I SSH 10 -j REJECT -s 2.3.2.3
> 

you could use -R here.
if many rules look like that, use ipset?

> if rule 10 in chain SSH differs in first and second ruleset. It mostly
> works but it needs constant maintenance because of changes in iptables
> itself so I am not satisfied. I believe that it works as I intended
> because this utility dramaticaly lower reload times of firewalls on our
> busy routers. As I said, changes are small. Restoring 10000 rules via
> iptables-restore is often more slow than my python processing and
> executing two iptables commands.

using the -n switch of iptables-restore you might be able to create
'smaller' changes.

Best regards

Mart

  parent reply	other threads:[~2010-06-01 13:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-01  8:10 iptables rules in comparable form Radek Kanovsky
2010-06-01  8:50 ` Jan Engelhardt
2010-06-01  9:18   ` Mart Frauenlob
2010-06-01 11:25     ` Radek Kanovsky
2010-06-01 11:56       ` Jan Engelhardt
2010-06-01 16:03         ` Radek Kanovsky
2010-06-01 18:19           ` Jan Engelhardt
2010-06-01 18:35             ` Radek Kanovsky
2010-06-01 18:01         ` Radek Kanovsky
2010-06-01 18:26           ` Jan Engelhardt
2010-06-01 19:36             ` Radek Kanovsky
2010-06-01 20:29               ` Pieter Smit
2010-06-02  6:17                 ` Radek Kanovsky
2010-06-01 13:27       ` Mart Frauenlob [this message]
2010-06-01 16:47         ` Radek Kanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C050ADE.60403@chello.at \
    --to=mart.frauenlob@chello.at \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.