Understanding TCP Reset Attacks, Part I 10
Jeremy Andrews writes "A vulnerability in TCP, the transmission control protocol, recently received some exposure in the media. Paul Watson released a white paper titled Slipping In The window: TCP Reset Attacks at the 2004 CanSecWest conference, providing a much better understanding of the real-world risks of TCP reset attacks. The resulting articles in the major media painted a doom and gloom picture of the threat. To better understand the reality of this threat and how it affects all operating systems, KernelTrap spoke with Theo de Raadt, the creator of OpenBSD, an operating system which among other goals proactively focuses on security. In this article, we aim to provide some background into the workings of TCP, and then to build upon this foundation to understand how resets attacks work. This is the first article in a two part series. The second article will look into how TCP stacks can be hardened to defend against such attacks. Toward this goal, we spoke with members of the OpenBSD team to learn what they have done so far, and what further plans they have to minimize the impact of reset attacks."
Re:IPX/SPX (Score:5, Informative)
IP4
TCP->IP->Ethernet->Wire->Ethernet->IP->TC P
IP6
TCP->IPv6->Ethernet->Wire->Ethernet->IPv6-
Hmmmm....
Re:IPX/SPX (Score:5, Interesting)
IPv6 provides other means to prevent IP spoofing (a prerequisite for TCP reset attacks).
Re:IPX/SPX (Score:5, Interesting)
Doesn't matter at all. For a reset attack, you need to match source IP address (known), destination IP address (known), source port (unknown, but guessable), destination port (known), and TCP sequence number (unknown, but guessable). All the unknowns are in the TCP layer.
Solutions. (Score:1)
All this trouble stems from two orthogonal problems.
One possibility would be to accept the RST packet with the very right sequence number (beginning of window) and thus making its probability fall back to 2^32 to 1. I guess it would need some serious reimplementation of TCP stack on all systems.
Another possibilty would be for ISPs to drop packet with inappropriate source address, to prevent spo
Re:Solutions. (Score:1)
?!!?!?
Re:Solutions. (Score:1)
Let's imagine an ISP providing the range 80.214.0.0
It has some routers providng connection to the rest of Internet. The filtering should take place on these routers for packets going from subnetwork to internet.
If this packet has source 80.214.1.56, it's probably a legit packet and the router must transfer it.
If this packet has source 12.34.56.78 -inappropriate- it's a bad packet and must drop it.
OSrry I didn't make it clear on first time
In window (Score:3, Interesting)
It mostly seem to be a problem for silly application protocols that expects to keep idle TCP-connections up all the time.
ipSec (Score:3, Interesting)
Random source port allocation from a large pool, combined with smaller window sizes should be sufficient for the rest. Why do you need more than a 1K window width? Because packet sizes are too small. TCP is from '91, so 1K packets were considered "big", transmission speeds were slow, and the network was presumed to be fairly unreliable. Now with higher speed and huge memory, a packet size of 64K would reduce overhead as well as the need for large packet windows.