[Ipchains-dev] My (newbie) thoughts about netfilter
Paul Rusty Russell
Wed, 01 Sep 1999 10:31:57 -0700
In message <E11LjEY-0006hWfirstname.lastname@example.org> you write:
> >I agree 8-(. Would a `--rename-chain' option to iptables help? It'd
> >be convoluted:
> You'd be without an active chain for a second which could introduce
> race conditions (the chain to be replaced could be designed to take
> care of certain states and the rules following that chain chould rely
> on these states already taken out).
No, renaming them would be have no semantic change, so:
# iptables -N foo
# iptables -A INPUT -j foo
# iptables --rename foo bar
Is *exactly* the same as:
# iptables -N bar
# iptables -A INPUT -j bar
Basically, all it would gain you is that you wouldn't have to remember
which of your two chains was `active': it'd always be the one called
`active' after your script has run.
This is because inside the kernel we only have a table with jumps in
it: all the names etc. are an illusion maintained by the userspace
library, and not necessary for functioning (internally this is a huge
change over ipchains).
> If swapping rules is not possible, I'd have to have an additional
> --copy-chain option to iptables.
Swapping rules is possible, of course, as well. It has the advantage
that it can have the unused `-S' flag, but the disadvantage that it's
> This would make possible doing things like that.
> # iptables --copy-chain A tmp
> # <make changes to tmp>
> # iptables --rename-chain tmp A
> --rename-chain would need to overwrite any target chain that already
> exists and would need to delete the overwritten rules to prevent
> memory leaks. I don't have a clue how the table structure is
> implemented, but I strongly feel that race conditions in a packet
> filter are to be avoided at all costs.
You atomically replace the entire table every time, then you add
counters back in. Hence, to insert a rule:
1) Read the rule table from the kernel:
1 2 3 4 5
2) Create a new table with your rule inserted and counters zeroed:
1 2 2' 3 4 5
3) Replace the rule table in the kernel (gives back the old counters
atomically: c1 c2 c3 c4 c5).
4) Add these counters back in (c1 c2 0 c3 c4 c5).
This technique allows ANY atomic change you can come up with: we just
have to decide what abstractions to allow in the library.
> ># ipchains -A logdeny -j LIMIT --limit-rate 5 1
> LIMIT would set a global limit for all LOG rules following it? Would
> it affect only the LOG rule following immediately?
[Oops, meant `iptables -A...', Doh!]
It would act as an accounting rule unless the limit is reached, when
it would act as a DROP rule (I'd probably make this configurable with
--limit-target). Cool, huh? This is just a simplification of the
existing RATE target (Jérôme de Vivie and Hervé Eychenne's excellent