| Message ID | 4F761E8E.9000708@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
31.03.2012 01:19, Eric Dumazet написал:
> FYI current linux kernel just drops this kind of message (SYN+FIN)
OK, thanks for clarification, I should have missed this commit.
On Sat, 2012-03-31 at 01:40 +0400, Artyom Gavrichenkov wrote: > 31.03.2012 01:19, Eric Dumazet написал: > > FYI current linux kernel just drops this kind of message (SYN+FIN) > > OK, thanks for clarification, I should have missed this commit. > You're welcome. I just realize I made a typo in the Changelog... Dont call conn_request() if the TCP flags includes SYN flag -> Dont call conn_request() if the TCP flags includes FIN flag -- 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
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
On Sun, 2012-04-01 at 19:42 +0200, Pablo Neira Ayuso wrote: > 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. Agreed. With TCP Fast Open, it might be possible to send a SYN+FIN+cookies+DATA in a single frame. -- 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/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
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. 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.