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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html