[PATCH 28/43] Unifies libipt_tcp.c into libxt_tcp.c.
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
I suppose you mean RFC973 ? Well, it says that SYN is handled before FIN.
> But I've found
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