Re: [RFC] Die to NOTRACK/TRACE, long live MARK!

[Pablo Neira <pablo@eurodev.net>]

Hi Jozsef,

Jozsef Kadlecsik wrote:

>Willy Tarreau suggested that the TCP window tracking code could be used to
>protect connections against the "TCP vulnerabilities" brought up recently
>(see for example http://www.uniras.gov.uk/vuls/2004/236929). After some
>discussion and code-fragments the result is that it could be done fairly
>easily: the SYN/RST probes could be counted and when a threshold is
>reached, we'd deliberately drop in-window SYN/RST segments to protect the
>connection. However, it'd then mean a violation of the TCP protocol
>specification and therefore I'd definitely not like to enable it by
>default or to enable it for all traffic. So there should be a way to tell
>the system which connections (packets) to protect.
>  
>

I agree, these options shouldn't be enable by default, as I told you in 
my last email related to window-tracking stuff that we could set the 
default action (NF_*) applied to packet via sysctl, so a sysadmin could 
choose to perform an agressive window /secuence tracking, this way if we 
see out-of-window packets, we could log and drop them.

>We could introduce a new silly target for that purpose like NOTRACK or
>TRACE. However it's pure marking and we do have a interface to mark
>packets: the MARK target. So if we could tell the system which mark value
>has got the given special meaning, we wouldn't need a new target and we
>could even eliminate the NOTRACK/TRACE targets.
>  
>

yes, I think that's ok, we could implement a set of "security" matches 
which perform some action depending on the mark. For example, 
mark_rst_protection could use internal tcp conntrack information to see 
if an rst was retransmited too many times and block rst's during a 
timeout to reduce effects of an rst attack or whatsoever. So we should 
reserve a range of marks.

regards,
Pablo