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

Yasuyuki KOZAKAI yasuyuki.kozakai at toshiba.co.jp
Tue Jul 17 09:48:33 CEST 2007

From: Pascal Hambourg <pascal.mail at plouf.fr.eu.org>

> 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.

No, RFC793 :) Sorry.

> > 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.

Yes, so I think we'd better to add some texts about this change in
the announcement of next version.

And if users want to handle match SYN+FIN, they can use '--tcp-flags'.

> 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 ?

From nf_conntrack_proto_tcp.c, 

/* table of valid flag combinations - PUSH, ECE and CWR are always valid */
static u8 tcp_valid_flags[(TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG) + 1] =
        [TH_SYN]                        = 1,
        [TH_SYN|TH_URG]                 = 1,
        [TH_SYN|TH_ACK]                 = 1,
        [TH_RST]                        = 1,
        [TH_RST|TH_ACK]                 = 1,
        [TH_FIN|TH_ACK]                 = 1,
        [TH_FIN|TH_ACK|TH_URG]          = 1,
        [TH_ACK]                        = 1,
        [TH_ACK|TH_URG]                 = 1,

-- Yasuyuki Kozakai

More information about the netfilter-devel mailing list