Connections with SYN aren't NEW

Connections with SYN aren't NEW

[Loïc Minier]

     Hey list,

 I am using a 2.4.22 with the ebtables + br-nf patch of
 ebtables.sourceforge.net. I am currently not DROPping packets, only
 logging for a while as a safety for my new rules on this host.

 I face a problem with some TCP connections: I want to accept new
 TCP connections only if they match both --syn and -m state --state
 NEW. This turns out to be a bad practice in some case where I see
 legitimate new TCP connections with correct flags matching --syn but
 which do not match -m state --state NEW.
   This happens a lot with HTTP clients and with DNS requests, and I
 think this is because of port reuse:
   - the HTTP client opens a connection from port xyz to port 80
   - it finishes the session and closes the connection
   - it reopens another connection with the same port xyz to the same
     host on port 80

 However, grepping the /proc/net/ip_conntrack shows two different
 entries in such cases.

 Am I wrong in thinking the connections should match -m state --state
 NEW, even if a connection happened with the same ports/ips a few
 seconds ago? What can I change to fulfill my wishes?


   Kind regards,

-- 
Loïc Minier <lool@dooz.org>

Re: Connections with SYN aren't NEW

[Antony Stone]

On Sunday 14 December 2003 4:23 pm, Loïc Minier wrote:

>  I face a problem with some TCP connections: I want to accept new
>  TCP connections only if they match both --syn and -m state --state
>  NEW. This turns out to be a bad practice in some case where I see
>  legitimate new TCP connections with correct flags matching --syn but
>  which do not match -m state --state NEW.
>
>    This happens a lot with HTTP clients and with DNS requests, and I
>  think this is because of port reuse:
>    - the HTTP client opens a connection from port xyz to port 80
>    - it finishes the session and closes the connection
>    - it reopens another connection with the same port xyz to the same
>      host on port 80
>
>  Am I wrong in thinking the connections should match -m state --state
>  NEW, even if a connection happened with the same ports/ips a few
>  seconds ago? What can I change to fulfill my wishes?

It depends what happens at the second stage in your description above "it 
finishes the session and closes the connection".

Basically, netfilter will match NEW if there isn't an entry in the 
conntracking table for the packet (ie: it's not ESTABLISHED, nor RELATED).

An entry will only get removed from the conntrack table after being 
ESTABLISHED if netfilter:

 - sees the FIN packet/s, or
 - sees a RST packet, or
 - times out (after 5 days....)

So, if your HTTP client is just dropping a connection without closing it 
nicely (using FIN, or even RST) then netfilter will think it is still 
ESTABLISHED.

I don't know if this explains the problem you are seeing, but it's a reason 
why netfilter may think the connection is in a different state than the 
client does.

Antony.

-- 
In science, one tries to tell people
in such a way as to be understood by everyone
something that no-one ever knew before.

In poetry, it is the exact opposite.

 - Paul Dirac

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Connections with SYN aren't NEW

[Antony Stone]

On Sunday 14 December 2003 4:23 pm, Loïc Minier wrote:

> I want to accept new TCP connections only if they match both --syn and -m
> state --state NEW.

Just out of interest, why?

What do you gain from having them match NEW, which isn't already true if they 
match --syn?

Antony.

-- 
Ramdisk is not an installation procedure.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Connections with SYN aren't NEW

[Loïc Minier]

Antony Stone <Antony@Soft-Solutions.co.uk> - Sun, Dec 14, 2003:

> So, if your HTTP client is just dropping a connection without closing it 
> nicely (using FIN, or even RST) then netfilter will think it is still 
> ESTABLISHED.

 I should have written that the connection is closed nicely, with a FIN
 packet (I just re-checked). Please note that the conntrack keeps closed
 connection for a while exactly like a normal connection, and with the
 [ASSURED] flag but it adds a TIME_WAIT flag to closed connections.

> I don't know if this explains the problem you are seeing, but it's a reason 
> why netfilter may think the connection is in a different state than the 
> client does.

 Yes, it could have been a good explanation.

-- 
Loïc Minier <lool@dooz.org>

Re: Connections with SYN aren't NEW

[Loïc Minier]

Antony Stone <Antony@Soft-Solutions.co.uk> - Sun, Dec 14, 2003:

> What do you gain from having them match NEW, which isn't already true if they 
> match --syn?

 Frankly speaking, I am not certain of the true benefits I will ever
 enjoy of forcing both NEW and --syn. But the topic of where to place
 the limit in the types of traffic you accept would be too much of a
 troll to discuss here... ;)
   I see the TCP flags and the conntrack as two different providers for
 the information "this is a new TCP connections". I think I should only
 believe a new connection takes place when both agree, because my goal
 is to stop suspicious traffic.

 As a dumb example of traffic I could reject with such a rule, I could
 take an injected SYN packet in the middle of a real TCP connection
 generating a tcp-reset and effectively closing the connection. This
 could be an efficient manner of closing a connection in a way which
 couldn't easily be seen. Call me paranoid, I prefer to call myself
 ignorant of what somebody could do if I don't disallow this :)

 Is this clear enough? or too far-fetched?

   Sincerely,

-- 
Loïc Minier <lool@dooz.org>