4

Hi I'm a newbie in networking, still confused with the relationship between three-way handshake and Denial of Service attack.

As we know that if the client does not send an ACK to complete the third step of this 3-way handshake, eventually (often after a minute or more) the server will terminate the halfopen connection and reclaim the allocated resources.

so my questions are:

  1. why attackers just do the first step of 3-way handshake? why don't they just complete all three steps of 3-way handshake to be fully connected with the server just like normal users so it is going to take up the resource of the server

  2. The classic textbook: Computer Networking : a top-down approach describes TCP's approach to avoid Dos attacks:

The server creates an initial TCP sequence number that is a complicated function (hash function) of source and destination IP addresses and port numbers of the SYN segment, as well as a secret number only known to the server. if the client does not return an ACK segment, then the original SYN has done no harm at the server, since the server hasn’t yet allocated any resources in response to the original bogus SYN.

But if the original SYN has done no harm at the server, why the hash function is needed to create a 'cookie' for the server to identify the user's SYN segment in the first step of 3-way handshake to see whether it is valid?

7

why attackers just do the first step of 3-way handshake? why don't they just complete all three steps of 3-way handshake to be fully connected with the server just like normal users so it is going to take up the resource of the server

When just sending a SYN to allocate resources on the server the attacker can spoof the IP address and thus hide its real IP address. To create a full handshake the attacker cannot use IP spoofing because the final ACK must be in response to the servers SYN which the client does not get if the original SYN was IP spoofed.

But if the original SYN has done no harm at the server, why the hash function is needed to create a 'cookie' for the server to identify the user's SYN segment in the first step of 3-way handshake to see whether it is valid?

If only a simple predictable function is used to compute the servers ISN from the clients SYN then the attacker might create the final ACK without seeing the servers actual SYN. In this case the attacker could IP spoof not only the SYN but also the ACK and would thus cause the allocation of even more resources on the server.

  • Also, it should be noted that doing the full handshake is much slower. The attacker doesn't need to wait for anything, he just needs to keep flooding the target with SYNs; the spoofing makes this even more "fun", since it allows him to use the target machine as the source of another DOS attack :D This was an approach used to exploit public game servers a few years back - no need for a botnet. – Luaan May 9 '18 at 9:21
  • @Luaan: Doing a full handshake is only slower if you do it the naive way by using a blocking TCP socket and let the OS kernel do all the stuff. Then you have to wait for each connect to finish. But if you can use raw sockets (which you also need for IP spoofing) you could simply rapid-fire SYN and forget about it (i.e. no state needed at client) and whenever you receive a SYN just create a matching ACK since all information to do this are contained in the received SYN. – Steffen Ullrich May 9 '18 at 9:37
  • @SteffenUllrich Thank you for your answer! another question is, how does a server deny access to an user(not an attacker)? Does the server just do not reply with SYNACK segment and let the client waits or the server send a SYNACK segment setting a field to represent the denial? – amjad May 10 '18 at 2:10
  • 1
    @amjad Neither. The server replies with a valid SYNACK, but it doesn't create any per-connection local state (it doesn't record the remote side IP address and port in a lookup table of partially open connections), so the only resource wasted is bandwidth. If the original SYN was valid, the client will get the SYNACK and respond to it with an ACK. The server will validate the connection using the cookie, not by looking the connection up in the table of half-open connections. – Slartibartfast May 10 '18 at 3:18
1

The TCP SYN flood happens for two important reasons. First is the possibility of saturating the bandwidth available to a server with the volume of traffic, especially if distributed (DDoS). This doesn't have to eat up all of the bandwidth to cause major disruptions to customers.

Second important reason is that flooding a server with SYN packets with different SRC ports causes the server to open all these new connections. These eat up CPU, memory, and also prevent honest connections from customers on those occupied ports.

The University of Southern California has a nice paper on this topic of (essentially) port squatting.

Port Squatting

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.