From patchwork Fri Mar 30 21:19:25 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Eric Dumazet X-Patchwork-Id: 149760 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 0D725B6EF3 for ; Sat, 31 Mar 2012 08:53:38 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965807Ab2C3VTd (ORCPT ); Fri, 30 Mar 2012 17:19:33 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:48688 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965679Ab2C3VTa (ORCPT ); Fri, 30 Mar 2012 17:19:30 -0400 Received: by wibhr17 with SMTP id hr17so1007085wib.1 for ; Fri, 30 Mar 2012 14:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=zd4etHCbW2VZMC1ILZ2mn1wc1PcMxlflzZMyYdYRETE=; b=sL4iOhpswOJP1R4M3OIIIRuwJvJQZcNsVGj2lfFlxJ4zf8S9MQI6yeJ3r/oKhjXW1g vqPi/xyLUP1e3x2oY58OOZhy+HX8bg3B+WW0yTe8vgjExkTaRlmvCN4X2ZlNxIPXXThB lJuMamVk8nPJvsJX2IkF2eKHXd0BailkBLATFkUzguaj7I7aD5v2ge77upfrP2/Ir+6T ASRhqcMTizRHbfm4wMGJSvWaesUSHi21ZGyX/PsuXBnhQIor8rQLUQRhzAEZVPghnO2g a7vfHShhfSoEb/Kr0WcRcZTmemcNVMIjX3jgtfX8tiLVKD19kQt511fmxNvr8CX9LSKh rmdQ== Received: by 10.180.107.101 with SMTP id hb5mr86287wib.7.1333142368982; Fri, 30 Mar 2012 14:19:28 -0700 (PDT) Received: from [172.28.131.28] ([74.125.122.49]) by mx.google.com with ESMTPS id ea6sm9612137wib.5.2012.03.30.14.19.26 (version=SSLv3 cipher=OTHER); Fri, 30 Mar 2012 14:19:27 -0700 (PDT) Subject: Re: `iptables -m tcp --syn` doesn't do what the man says From: Eric Dumazet To: Artyom Gavrichenkov Cc: netfilter-devel@vger.kernel.org In-Reply-To: <4F761E8E.9000708@gmail.com> References: <4F761E8E.9000708@gmail.com> Date: Fri, 30 Mar 2012 23:19:25 +0200 Message-ID: <1333142365.2325.2579.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Sender: netfilter-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netfilter-devel@vger.kernel.org On Sat, 2012-03-31 at 00:58 +0400, Artyom Gavrichenkov wrote: > Hi all, > > The iptables(8) manpage says: > > --- [cut here] --- > tcp > These extensions can be used if `--protocol tcp' is specified. It provides the following options: > [!] --syn > Only match TCP packets with the SYN bit set and the ACK,RST and FIN bits cleared. Such packets are used to request TCP connection initia‐ > tion; for example, blocking such packets coming in an interface will prevent incoming TCP connections, but outgoing TCP connections will be > unaffected. It is equivalent to --tcp-flags SYN,RST,ACK,FIN SYN. If the "!" flag precedes the "--syn", the sense of the option is > inverted. > --- [cut here] --- > > Unfortunately, with current stable Linux kernel release (as well as > with most of the previous versions) blocking TCP packets with the SYN > bit set and the ACK,RST and FIN bits cleared won't prevent incoming > TCP connections. > > Currently Linux TCP stack considers an incoming TCP segment to be a > connection initiation request if the segment only has SYN flag set and > ACK and RST flags cleared. You can easily check it yourself with your > nearest Linux box, as well as on the netfilter.org (213.95.27.115): > > # hping3 -c 2 -n -FS -p 80 netfilter.org > HPING netfilter.org (wlan0 213.95.27.115): SF set, 40 headers + 0 data bytes > len=44 ip=213.95.27.115 ttl=52 DF id=0 sport=80 flags=SA seq=0 win=5840 rtt=58.8 ms > len=44 ip=213.95.27.115 ttl=52 DF id=0 sport=80 flags=SA seq=1 win=5840 rtt=51.1 ms > > --- netfilter.org hping statistic --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max = 51.1/55.0/58.8 ms > # > > As you see, the netfilter.org server sends SYN/ACK in response to an > incoming SYN/FIN, indicating that a connection is being established. > It is only a matter of a few checks to make sure that the indication > is correct and the connection is indeed initialized. > > This might be a Linux bug as well to accept SYN/FIN as a connection > initiation attempt. However, there could as well be a reason for kernel > developers to do this, because such thing as T/TCP (RFC 1644) allows a > TCP server to act like this, and though this RFC is experimental and > obsolete, as far as I know, it is still implemented somewhere, for > example, in FreeBSD. > FYI current linux kernel just drops this kind of message (SYN+FIN) git describe --contains fdf5af0daf8019cec2396cdef8fb042d80fe71fa v3.3-rc1~182^2~365 commit fdf5af0daf8019cec2396cdef8fb042d80fe71fa Author: Eric Dumazet Date: Fri Dec 2 23:41:42 2011 +0000 tcp: drop SYN+FIN messages Denys Fedoryshchenko reported that SYN+FIN attacks were bringing his linux machines to their limits. Dont call conn_request() if the TCP flags includes SYN flag Reported-by: Denys Fedoryshchenko Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller > I guess that most iptables setups probably are not affected by this > behaviour, because `iptables -m tcp --syn' is often used for something > in lines of this: > > iptables -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT > iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT > iptables -A INPUT -j DROP > > In this case, SYN/FIN segments will be dropped, because they are not > considered plain SYN and they are not associated with an established > connection. My guess is that, for example, kernel.org is set up like that: > Or it runs linux 3.3 > # hping3 -c 2 -n -FS -p 80 kernel.org > HPING kernel.org (wlan0 149.20.4.69): SF set, 40 headers + 0 data bytes > > --- kernel.org hping statistic --- > 2 packets transmitted, 0 packets received, 100% packet loss > round-trip min/avg/max = 0.0/0.0/0.0 ms > # > > However, there are cases when this behaviour produces clear security > breach, for example, when one is trying to prevent incoming TCP > connections from a certain IP (as manpage suggests) or when one is > trying to limit the rate of connection establishment attempts. In > this case attacker can send SYN/FIN packets which would pass all the > rules containing --syn and would establish a connection. > > The patch to fix this is trivial (it is attached below), however, it > might be a good idea to discuss reasons first and find the best > solution possible. > > P. S. Sorry for being so verbose, I'm new to this mailing list and I'm > trying to explain everything as clear as I can. > Thats perfect, thanks ! > -- > | Artyom Gavrichenkov > | gpg: fa1c670e > | mailto: ximaera@gmail.com > | xmpp: ximaera@gmail.com > | skype: xima_era > | tel. no: +7 916 515 49 58 > > -- Signed-off-by: Artyom Gavrichenkov > > diff --git a/extensions/libxt_tcp.c b/extensions/libxt_tcp.c > index e849fa2..3af03c4 100644 > --- a/extensions/libxt_tcp.c > +++ b/extensions/libxt_tcp.c > @@ -169,7 +169,7 @@ tcp_parse(int c, char **argv, int invert, unsigned int *flags, > xtables_error(PARAMETER_PROBLEM, > "Only one of `--syn' or `--tcp-flags' " > " allowed"); > - parse_tcp_flags(tcpinfo, "SYN,RST,ACK,FIN", "SYN", invert); > + parse_tcp_flags(tcpinfo, "SYN,RST,ACK", "SYN", invert); > *flags |= TCP_FLAGS; > break; > > diff --git a/extensions/libxt_tcp.man b/extensions/libxt_tcp.man > index 7a16118..e1698df 100644 > --- a/extensions/libxt_tcp.man > +++ b/extensions/libxt_tcp.man > @@ -31,12 +31,12 @@ will only match packets with the SYN flag set, and the ACK, FIN and > RST flags unset. > .TP > [\fB!\fP] \fB\-\-syn\fP > -Only match TCP packets with the SYN bit set and the ACK,RST and FIN bits > +Only match TCP packets with the SYN bit set and the ACK and RST bits > cleared. Such packets are used to request TCP connection initiation; > for example, blocking such packets coming in an interface will prevent > incoming TCP connections, but outgoing TCP connections will be > unaffected. > -It is equivalent to \fB\-\-tcp\-flags SYN,RST,ACK,FIN SYN\fP. > +It is equivalent to \fB\-\-tcp\-flags SYN,RST,ACK SYN\fP. > If the "!" flag precedes the "\-\-syn", the sense of the > option is inverted. > .TP > --- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 78dd38c..0cbb440 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5811,6 +5811,8 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb, goto discard; if (th->syn) { + if (th->fin) + goto discard; if (icsk->icsk_af_ops->conn_request(sk, skb) < 0) return 1;