Jozsef Kadlecsik wrote:
On Wed, 20 May 2009, Jozsef Kadlecsik wrote:
Because connlimit/connbytes rely on conntrack, the latter should be
"fixed". However I do not see any way to make it resistant against such
attacks: if we shrink the window (by which alogrithm?) we may block valid
RST segments and thus cause connections to hang instead of termination.
OK, here is a patch. Could you test it with your script and in your
environment?
The patch below introduces a new flag for TCP conntrack to mark that RST
segment was seen. If retransmitted packets detected from the other
direction after the RST segment detected, the timeout of the conntrack
entry is linearly increased up to a hardcoded value. Thus we can both
catch the retransmitted packets and preserve the effectiveness of
connlimit/connbytes.
Perhaps I'm misunderstanding, but I don't think this will fix it.
Although the original example I gave involved TCP retransmits that
"reanimated" the connection, the problem is unfortunately not limited to
that case, and there don't need to be any TCP retransmits involved. (The
subject of this thread is now a little misleading and overly-specific,
unfortunately.)
Here's the opening of a telnet connection that I injected a bogus RST
packet into (the packet has sequence 522209353 instead of the correct
522209354):
client.52665 > server.23: S 522209223:522209223(0) win 5840 <mss
1460,sackOK,nop,wscale 7>
server.23 > client.52665: S 3233007698:3233007698(0) ack 522209224 win
5792 <mss 1460,sackOK,nop,wscale 6>
client.52665 > server.23: . ack 3233007699 win 46 <nop,nop>
server.23 > client.52665: P 3233007699:3233007711(12) ack 522209224 win
91 <nop,nop>
client.52665 > server.23: . ack 3233007711 win 46 <nop,nop>
client.52665 > server.23: P 522209224:522209236(12) ack 3233007711 win
46 <nop,nop>
server.23 > client.52665: . ack 522209236 win 91 <nop,nop>
server.23 > client.52665: P 3233007711:3233007735(24) ack 522209236 win
91 <nop,nop>
client.52665 > server.23: . ack 3233007735 win 46 <nop,nop>
client.52665 > server.23: P 522209236:522209327(91) ack 3233007735 win
46 <nop,nop>
server.23 > client.52665: P 3233007735:3233007750(15) ack 522209327 win
91 <nop,nop>
client.52665 > server.23: P 522209327:522209351(24) ack 3233007750 win
46 <nop,nop>
server.23 > client.52665: P 3233007750:3233007753(3) ack 522209351 win
91 <nop,nop>
client.52665 > server.23: P 522209351:522209354(3) ack 3233007753 win 46
<nop,nop>
server.23 > client.52665: P 3233007753:3233007947(194) ack 522209354 win
91 <nop,nop>
client.52665 > server.23: R 522209353:522209353(0) win 65535
client.52665 > server.23: . ack 3233007947 win 54 <nop,nop>
At this point, the telnet connection with the server is fully
established and waiting for me to type something (because the server
ignored the bogus RST). But conntrack incorrectly considers it CLOSEd
(because conntrack didn't ignore the RST). No retransmits were involved,
though.
Even if nf_conntrack_tcp_loose is true, and conntrack treats subsequent
packets as a new connection when I type something in telnet, I can make
it forget about the connection again by sending another bogus RST. If I
send a bogus RST after every legitimate packet, conntrack will almost
always think the open connection is actually closed.
Since no retransmits are necessary, I don't think a solution that looks
for retransmits will help, unfortunately.
--
Robert L Mathews, Tiger Technologies http://www.tigertech.net/
--
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
