Mailing List Archive

I've been playing with the conntrack tool and trying to use it to forcibly
remove established and related entries from the conntrack table. The main
reason I'm doing this is I want the ability to forcibly terminate a TCP
session after the access rules have been removed that allow this connection
to be established in the first place (at the moment an SSH session - for
example - remains active until the session has been closed by the client), I
can't forcibly shut the session down because I have general "established and
related" rules that allow the connection to remain open.

The problem I've found with the conntrack tool (using 'conntrack -F' to
flush the entries) is that even though the entry "appears" to get removed
for the TCP session, the entry gets re-added immediately by the session
which is still open. This is kind of counter-intuitive as once the entry is
removed I had assumed this meant the session was no longer known to be
"established" and therefore the next packet should be unrelated and dropped?
Is this correct or is there something wrong with the tool?

kernel: 2.6.22.1
libnetfilter_conntrack.so.1.2.0
libnfnetlink.so.0.2.0
conntrack v0.9.5

Thanks,
Andrew.

Hi,

Le lundi 06 août 2007 à 18:31 +1000, Andrew Hall a écrit :
> Hi Pablo,
> The problem I've found with the conntrack tool (using 'conntrack -F' to
> flush the entries) is that even though the entry "appears" to get removed
> for the TCP session, the entry gets re-added immediately by the session
> which is still open. This is kind of counter-intuitive as once the entry is
> removed I had assumed this meant the session was no longer known to be
> "established" and therefore the next packet should be unrelated and dropped?
> Is this correct or is there something wrong with the tool?

This is linked with your ruleset. The point to consider is that for the
conntrack NEW is not equivalent to SYN packet for TCP. If you only
filter on NEW, then packet from the previously existing connection will
be classified as NEW and trigger the creation of a new valid entry.

BR,
--
Éric Leblond, eleblond@inl.fr
Téléphone : 01 44 89 46 39, Fax : 01 44 89 45 01
INL, http://www.inl.fr

> This is linked with your ruleset. The point to consider is that for the
> conntrack NEW is not equivalent to SYN packet for TCP. If you only
> filter on NEW, then packet from the previously existing connection will
> be classified as NEW and trigger the creation of a new valid entry.

This is true, but how? I no longer have a "new" rule to allow connection. Here's the logic of what I'm trying to do:

1. First, set up SSH connection with the following ruleset:

- add a rule matching "established and related" connections to be allowed
- add a rule matching "new" connections from host for SSH to be allowed
- Policy is drop all

2. SSH is connected from host running 'top' to keep the session active

3. delete the "new" connection rule and 'conntrack -F' to flush the existing connections.

At this point I would have thought the conntrack table doesn't know the existing connection is "established" because the table entry is gone and without the "new" rule providing connection establishment, the session should be lost?




"Blue Reef disclaimer: This electronic message transmission contains information that is confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this information is prohibited. If you have received this transmission in error, please notify us by telephone immediately."

Scanned by Sonar.
Date: 2007-08-06 18:54:24
From: temp02@bluereef.com.au
To: netfilter-devel@lists.netfilter.org
Mail id: challenge-63904640371

On Aug 6 2007 18:54, Andrew Hall wrote:
>
>> This is linked with your ruleset. The point to consider is that for the
>> conntrack NEW is not equivalent to SYN packet for TCP. If you only
>> filter on NEW, then packet from the previously existing connection will
>> be classified as NEW and trigger the creation of a new valid entry.
>
>This is true, but how? I no longer have a "new" rule to allow connection. Here's the logic of what I'm trying to do:

Fix your ruleset. From:

-m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

to:

-m conntrack --ctstate ESTABLISHED -j ACCEPT
-m conntrack --ctstate NEW -p tcp --syn -j ACCEPT
-m conntrack --ctstate NEW -p udp -j ACCEPT
# (and more for SCTP/DCCP if you need that)

>
>1. First, set up SSH connection with the following ruleset:
>
>- add a rule matching "established and related" connections to be allowed
>- add a rule matching "new" connections from host for SSH to be allowed
>- Policy is drop all
>
>2. SSH is connected from host running 'top' to keep the session active
>
>3. delete the "new" connection rule and 'conntrack -F' to flush the existing connections.
>
>At this point I would have thought the conntrack table doesn't know the existing connection is "established" because the table entry is gone and without the "new" rule providing connection establishment, the session should be lost?
>
>
>
>
>"Blue Reef disclaimer: This electronic message transmission contains information that is confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this information is prohibited. If you have received this transmission in error, please notify us by telephone immediately."
>
>Scanned by Sonar.
>Date: 2007-08-06 18:54:24
>From: temp02@bluereef.com.au
>To: netfilter-devel@lists.netfilter.org
>Mail id: challenge-63904640371
>

Jan
--

On Mon, 6 Aug 2007, Jan Engelhardt wrote:

>
> On Aug 6 2007 18:54, Andrew Hall wrote:
>>
>>> This is linked with your ruleset. The point to consider is that for the
>>> conntrack NEW is not equivalent to SYN packet for TCP. If you only
>>> filter on NEW, then packet from the previously existing connection will
>>> be classified as NEW and trigger the creation of a new valid entry.
>>
>> This is true, but how? I no longer have a "new" rule to allow connection. Here's the logic of what I'm trying to do:
>
> Fix your ruleset. From:
>
> -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
>
> to:
>
> -m conntrack --ctstate ESTABLISHED -j ACCEPT
> -m conntrack --ctstate NEW -p tcp --syn -j ACCEPT
> -m conntrack --ctstate NEW -p udp -j ACCEPT
> # (and more for SCTP/DCCP if you need that)

Or:
-p tcp -m conntrack --ctstate NEW ! --syn -j INVALID_NewTCP
-m conntrack --ctstate ESTABLISHED,RELATED -j RETURN

And reset (--reject-with tcp-reset) such connections in INVALID_NewTCP
with something like:
iptables -A INVALID_NewTCP -p tcp -m limit --limit 6/s -j REJECT --reject-with tcp-reset
iptables -A INVALID_NewTCP -j DROP

One may also simply set: sysctl net.netfilter.nf_conntrack_tcp_loose=0 (or
net.ipv4.netfilter.ip_conntrack_tcp_loose on old kernels) but then it is
not possible to reset such connections so simply.

Best regards,

Krzysztof Olêdzki

Hello,

Andrew Hall a écrit :
>
> 1. First, set up SSH connection with the following ruleset:
>
> - add a rule matching "established and related" connections to be allowed
> - add a rule matching "new" connections from host for SSH to be allowed
> - Policy is drop all

I suppose this is the INPUT ruleset. What about the OUTPUT rules ?

> 2. SSH is connected from host running 'top' to keep the session active
>
> 3. delete the "new" connection rule and 'conntrack -F' to flush the
> existing connections.
>
> At this point I would have thought the conntrack table doesn't know
> the existing connection is "established" because the table entry is gone
> and without the "new" rule providing connection establishment, the
> session should be lost?

Just a guess. Could it be 'top' periodically refreshing the display
which causes the server to send traffic to the client over the SSH
session, and that traffic is accepted by the OUTPUT rules and re-adds
the conntrack entry ?

> Or:
> -p tcp -m conntrack --ctstate NEW ! --syn -j INVALID_NewTCP -m
> conntrack --ctstate ESTABLISHED,RELATED -j RETURN
>
> And reset (--reject-with tcp-reset) such connections in INVALID_NewTCP
> with something like:
> iptables -A INVALID_NewTCP -p tcp -m limit --limit 6/s -j REJECT --
> reject-with tcp-reset iptables -A INVALID_NewTCP -j DROP
>
> One may also simply set: sysctl net.netfilter.nf_conntrack_tcp_loose=0
> (or net.ipv4.netfilter.ip_conntrack_tcp_loose on old kernels) but then
> it is not possible to reset such connections so simply.
>

Thanks for coming back to me but I still don't believe this is a rule issue
- I believe it's an order problem in that a conntrack flush event will not
clear conntrack (add) events that are currently pending/locked. The reason I
believe this is because if I don't keep a constant flow of data traversing
between the host and firewall over SSH (in other words I stop the 'top') and
then flush the conntrack table, the SSH connection is now dead and any
subsequent packets from the host are then dropped as there is no longer any
applied state for this connection. Try it yourself:

1. Setup the following rules:

-s host -m state --state new -j ACCEPT
-s host -m state --state established,related -j ACCEPT
Policy drop everything else

2. open an SSH connection from host to firewall

3. check that the connection is there:

tcp 6 431995 ESTABLISHED src=10.1.1.103 dst=10.1.1.107 sport=56438
dport=22 packets=20 bytes=2828 src=10.1.1.107 dst=10.1.1.103 sport=22
dport=56438 packets=17 bytes=2681 [ASSURED] mark=0 use=1

4. now remove the --state new rule

5. check that the connection is still there and a few 'ps' to make sure the
connection is still alive. It is. New connections are not allowed, but the
existing connection remains open and active.

6. now conntrack -F

7. the connection is removed from the conntrack table and the SSH session is
dead (which is what I expect)

Now try the same test again, while maintaining a constant flow of SSH data
between host and firewall. This time, the connection won't die and the
connection re-adds itself to the conntrack table. According to my logic, as
far as the firewall is aware, a connection is only "established and related"
if there is an associated entry for it in the conntrack table. If the entry
is explicitly removed, how can any subsequent packets still be classified as
"related", as there is nothing to relate the connection anymore.

I'm sorry if I'm missing something plainly obvious here, but the case in
point doesn't make sense unless there is some locking function that
reinserts the state back into the table BEFORE the flush has a chance to
commit the removal.



"Blue Reef disclaimer: This electronic message transmission contains information that is confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this information is prohibited. If you have received this transmission in error, please notify us by telephone immediately."

Scanned by Sonar.
Date: 2007-08-07 14:00:21
From: temp02@bluereef.com.au
To: netfilter-devel@lists.netfilter.org
Mail id: challenge-64592217832

> I'm sorry if I'm missing something plainly obvious here, but the case
> in
> point doesn't make sense unless there is some locking function that
> reinserts the state back into the table BEFORE the flush has a chance
> to
> commit the removal.
>

Please disregard my last mail. I now realize that it is the return TCP
traffic that is keeping the conntrack populated.

Regards,



"Blue Reef disclaimer: This electronic message transmission contains information that is confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this information is prohibited. If you have received this transmission in error, please notify us by telephone immediately."

Scanned by Sonar.
Date: 2007-08-07 18:07:56
From: temp02@bluereef.com.au
To: netfilter-devel@lists.netfilter.org
Mail id: challenge-64740762800

Andrew Hall a écrit :
>
> I now realize that it is the return TCP
> traffic that is keeping the conntrack populated.

I think this should not happen any more if you disable the TCP
connection pickup (/proc/sys/net/netfilter/nf_conntrack_tcp_loose=0), or
drop INVALID packets in the return direction (in the OUTPUT chain, IIUC).