[PATCH 28/43] Unifies libip[6]t_tcp.c into libxt_tcp.c.

Pascal Hambourg pascal.mail at plouf.fr.eu.org
Tue Jul 17 08:45:55 CEST 2007


Yasuyuki KOZAKAI a écrit :
> From: Pascal Hambourg <pascal.mail at plouf.fr.eu.org>
>>>
>>>Since SYN+FIN does not make much sense (unless the ipv6-tcp protocol _really_
>>>allowed that), libipt_tcp's definition should be used.
>>
>>IMHO it does not 
>>matter whether SYN+FIN makes sense or not but whether it is a valid 
>>combination or not per the RFCs. I have always believed that there is 
>>some precedence among TCP flags, e.g. :
>>- RST has precedence over SYN and FIN ; if RST set, ignore SYN and FIN
>>- SYN has precedence over FIN ; if SYN set, ignore FIN
>>
>>Have I been wrong all this time ?
> 
> IIRC RFC797 says nothing about the behavior when receiving such TCP
> flags.

I suppose you mean RFC973 ? Well, it says that SYN is handled before FIN.

> But I've found
> 
> http://www.mail-archive.com/nanog@merit.edu/msg06112.html

I came across multiple similar discussions worrying about the so-called 
SYN-FIN port scans. They all acknowledge that popular TCP/IP stack 
implementations are "liberal" because they handle SYN+FIN as plain SYN. 
But I do not agreed with them when they claim that packet filters which 
unconditionally allow SYN+FIN through are "liberal" too. IMHO they are 
not liberal but actually broken because they fail to identify SYN+FIN 
either as plain SYN (which they should handle as such) or as an invalid 
combination (which they should drop).

One of my concerns is that with the new conservative definition of 
--syn, you cannot use it any more to drop SYN packets (e.g. to reject 
incoming TCP connection attempts on a stateless packet filter) because 
SYN+FIN won't match. Old rulesets which rely on --syn to detect and drop 
packets become more permissive with the new definition.

However I agree that nowadays any decent packet filter should use TCP 
connection tracking and not rely only on TCP flags. By the way, how does 
the TCP connection tracking in ip_conntrack and nf_conntrack handle 
"odd" flag combinations, i.e. more than one flag in RST, SYN and FIN set 
at the same time ?



More information about the netfilter-devel mailing list