On Sun, Jun 12, 2005 at 03:47:25PM +0200, Willy Tarreau wrote:
Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
so the connection will survive.
Sorry I wasn't thinking straight.
quoted
My point is that there are many ways to kill TCP connections in ways
similar to what you proposed initially so it isn't that special.
No, there are plenty of ways to kill TCP connections when you can guess
the window (which is more and more easy thanks to window scaling). But
I have yet found no way to kill a TCP session without this info, except
by exploiting the simultaneous connect feature.
I still stand by this point though. The most obvious thing I can think
of right now is to change your attack to simply connect to kernel.org's
webserver first from source port 10000. That will cause the real SYN
packet to fail the sequence number check.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Sun, Jun 12, 2005 at 11:50:18PM +1000, Herbert Xu wrote:
On Sun, Jun 12, 2005 at 03:47:25PM +0200, Willy Tarreau wrote:
quoted
Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
so the connection will survive.
Sorry I wasn't thinking straight.
quoted
quoted
My point is that there are many ways to kill TCP connections in ways
similar to what you proposed initially so it isn't that special.
No, there are plenty of ways to kill TCP connections when you can guess
the window (which is more and more easy thanks to window scaling). But
I have yet found no way to kill a TCP session without this info, except
by exploiting the simultaneous connect feature.
I still stand by this point though. The most obvious thing I can think
of right now is to change your attack to simply connect to kernel.org's
webserver first from source port 10000. That will cause the real SYN
packet to fail the sequence number check.
This case is interesting, but it will be resolved in two possible ways :
1) no firewall in front of A
- C spoofs A and sends a fake SYN to B
- B responds to A with a SYN-ACK
- A sends an RST to B, which clears the session
- A wants to connect and sends its SYN to B which accepts it.
2) A behind a firewall
- C spoofs A and sends a fake SYN to B
- B responds to A with a SYN-ACK, which does not reach A (firewall, etc...)
- A tries to connect to B and sends its SYN with a different SEQ
- B responds to A with only an ACK (no SYN) indicating the expected SEQ.
- A responds to B's ACK with an RST and B flushes its session too.
- A resends its SYN to B which accepts it.
Cheers,
Willy