Re: `iptables -m tcp --syn` doesn't do what the man says

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Sat, Mar 31, 2012 at 12:58:54AM +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.
> 
> 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:
> 
> # 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.

I understand your concern, but the info in the manpage is correct:
basically, it can be extracted from it that --syn will not match
SYN+FIN packets.

As you point in your patch, you have to use:

--tcp-flags  SYN,RST,ACK  SYN

in your rule-set for the situation that you describe.

Changing the default behaviour of --syn to catch this case is
delicate, I don't want to break backward compatibility.
--
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