[PATCH 28/43] Unifies libipt_tcp.c into libxt_tcp.c.
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://email@example.com/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 ?
/* 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