Dynamically adding rules - are connection tracking states maintained?

Dynamically adding rules - are connection tracking states maintained?

[noa levy]

Hi All,

I'm trying to understand the impact of dynamically adding iptables rules, in terms of the resulting disruption to the firewall's performance. When I add a rule to (or delete a rule from) iptables, while it is running, does that have any effect on the states in the connection tracking table? Will the table be flushed? Are states linked to the rule that allowed the initial packet in, so that if a rule is deleted, only the corresponding state entry will be flushed?

Thank you!
Noa  


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: Dynamically adding rules - are connection tracking states maintained?

[Pascal Hambourg]

Hello,

noa levy a écrit :
> 
> When I add a rule to (or delete a rule from) iptables,
> while it is running, does that have any effect on the states in the
> connection tracking table?

No.

> Will the table be flushed?

No.

> Are states linked  to the rule that allowed the initial packet in [...] ?

No.

Re: Dynamically adding rules - are connection tracking states maintained?

[Jan Engelhardt]

On Thursday 2008-04-24 21:24, Pascal Hambourg wrote:
> noa levy a écrit :
>> 
>> When I add a rule to (or delete a rule from) iptables,
>> while it is running, does that have any effect on the states in the
>> connection tracking table?
>
> No.
>
>> Will the table be flushed?
>
> No.

the conntrack table remains;
the fw rule table is atomically exchanged.

>> Are states linked  to the rule that allowed the initial packet in [...] ?
>
> No.

(No,) but parameters attached to rules may get reset when loading a
new ruleset into the kernel. Now what constutitues an "attached" data
portion hm... xt_quota for example stores its quota counter with the
rule. xt_recent for example on the other hand stores its data in a
separate malloc'ed area that is safe.

Re: Dynamically adding rules - are connection tracking states maintained?

[noa levy]

Thank you very much for your replies. 
I still don't understand one thing though: Let's say I delete a rule that allows SSH traffic. There are probably many entries in the conntrack table for SSH sessions. Will these sessions continue to be allowed in, even though I have just deleted the rule that allowed SSH (and my default policy is DROP)? 


On Thursday 2008-04-24 21:24, Pascal Hambourg wrote:
> noa levy a écrit :
>> 
>> When I add a rule to (or delete a rule from) iptables,
>> while it is running, does that have any effect on the states in the
>> connection tracking table?
>
> No.
>
>> Will the table be flushed?
>
> No.

the conntrack table remains;
the fw rule table is atomically exchanged.

>> Are states linked  to the rule that allowed the initial packet in [....] ?
>
> No.

(No,) but parameters attached to rules may get reset when loading a
new ruleset into the kernel. Now what constutitues an "attached" data
portion hm... xt_quota for example stores its quota counter with the
rule. xt_recent for example on the other hand stores its data in a
separate malloc'ed area that is safe.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: Dynamically adding rules - are connection tracking states maintained?

[Pascal Hambourg]

noa levy a écrit :
> I still don't understand one thing though: Let's say I delete a rule
> that allows SSH traffic. There are probably many entries in the
> conntrack table for SSH sessions. Will these sessions continue to be
> allowed in, even though I have just deleted the rule that allowed SSH
> (and my default policy is DROP)? 

You are asking the wrong question. Iptables is a packet filter, it does 
not filter "sessions" (or connections). As already said, the conntrack 
table is not affected by rule deletion/insertion. So whether packets 
belonging to existing connections are allowed or not depends on the new 
ruleset. If the new ruleset says to ACCEPT packets in the ESTABLISHED 
state, then established connections are still allowed.

Re: Dynamically adding rules - are connection tracking states maintained?

[noa levy]

Thank you again for your response. Suppose I do want drop existing connections, but I don't want to add the "drop" rule above the "allow established" rule, for performance reasons. Does netfilter provide any API for flushing the conntrack table (all of it or specific entries)? Will stopping the firewall completely flush these entries?


--- On Tue, 4/29/08, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote:

> You are asking the wrong question. Iptables is a packet
> filter, it does 
> not filter "sessions" (or connections). As
> already said, the conntrack 
> table is not affected by rule deletion/insertion. So
> whether packets 
> belonging to existing connections are allowed or not
> depends on the new 
> ruleset. If the new ruleset says to ACCEPT packets in the
> ESTABLISHED 
> state, then established connections are still allowed.




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: Dynamically adding rules - are connection tracking states maintained?

[Josh Cepek]

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

noa levy wrote:
> Thank you again for your response. Suppose I do want drop existing connections, but I don't want to add the "drop" rule above the "allow established" rule, for performance reasons. Does netfilter provide any API for flushing the conntrack table (all of it or specific entries)?

Not easily, and not without disrupting other active connections.  If 
conntrack support is compiled in as modules you can unload and reload 
them, but this requires that no iptables rules reference the conntrack 
module (ie: you must delete such rules first.)  Once unloaded, the 
kernel will forget the maintained state table, but this also has the 
side-effect of breaking any active sessions that were in an ESTABLISHED 
state when you deleted the rules and reset the state table.

AFAIK there is no way to manually flush the conntrack state table or 
remove specific entries.

> Will stopping the firewall completely flush these entries?
>   

That depends entirely on what the script "stopping the firewall" 
actually does, but general the answer is "no".  If it simply flushes all 
chains and removes non-standard chains, the state table will still exist 
as this support is provided by the conntrack kernel modules, not the 
iptables rules themselves.  Most scripts I've seen on any distro will 
not actually unload the conntrack modules when the firewall initscript 
is stopped, and of course this wouldn't even be possible if conntrack 
support is compiled into the kernel rather than as a module.

It sounds like you might be using the wrong tool for the job; to 
disconnect a user with an active ssh session why not look at running 
sshd processes and send a SIGTERM or SIGINT signal to the one with the 
user or users you wish to disconnect?  This strikes me as a problem best 
handled at an application level rather than a kernel level.

>
> --- On Tue, 4/29/08, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> wrote:
>
>   
>> You are asking the wrong question. Iptables is a packet
>> filter, it does 
>> not filter "sessions" (or connections). As
>> already said, the conntrack 
>> table is not affected by rule deletion/insertion. So
>> whether packets 
>> belonging to existing connections are allowed or not
>> depends on the new 
>> ruleset. If the new ruleset says to ACCEPT packets in the
>> ESTABLISHED 
>> state, then established connections are still allowed.

-- 
Josh



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Dynamically adding rules - are connection tracking states maintained?

[Petr Pisar]

On 2008-05-01, Josh Cepek <josh.cepek@usa.net> wrote:
>
> AFAIK there is no way to manually flush the conntrack state table or
> remove specific entries.
>
There is a way how to do it. The tool is called "conntrack", it's part
of conntrack-tools package and it's distributed by Netfilter team.

-- Petr

Re: Dynamically adding rules - are connection tracking states maintained?

[Pablo Neira Ayuso]

Josh Cepek wrote:
> noa levy wrote:
>> Thank you again for your response. Suppose I do want drop existing
>> connections, but I don't want to add the "drop" rule above the "allow
>> established" rule, for performance reasons. Does netfilter provide any
>> API for flushing the conntrack table (all of it or specific entries)?
> 
> Not easily, and not without disrupting other active connections.  If
> conntrack support is compiled in as modules you can unload and reload
> them, but this requires that no iptables rules reference the conntrack
> module (ie: you must delete such rules first.)  Once unloaded, the
> kernel will forget the maintained state table, but this also has the
> side-effect of breaking any active sessions that were in an ESTABLISHED
> state when you deleted the rules and reset the state table.
> 
> AFAIK there is no way to manually flush the conntrack state table or
> remove specific entries.

This is no longer true as we have the conntrack-tools.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers