Three-way handshake in TCP & ACK and SYN flood attack
May 12, 2018
⏳ 2 min read
Sources
Three-way handshake: how does it work
When is it used
TCP three-way handshake occurs between a client and server when initiating or terminating a TCP connection.
Expalined in detail
- So let’s say client A and B are trying to make a connection over TCP.
Awill send aSYN(chronize) packet toBwith a sequence number that tells where the segment will begin from.A --SYN (seq = x)--> B note: x is n + 1 where n is previous sequence number it just had.Breceives a frame fromAand will send aSYN + ACKframe as a reply.SYNis to start the conversation andACKis just proof to the client that the ACK is specific to the SYN the client initiated.A <--SYN + ACK (seq = y, ack = x + 1)-- BAsends back anACKframe toBto acknowledge the request fromBfor synchronization.A --ACK (ack = y + 1)--> B
SYN Flood
- You send many
SYNpackets to the victim to seem to be establishing a connection with it. - But you never receive
SYN + ACKpacket back from the victim. The connection is therefore half-opened. - The victim (probably a server) will be loaded up with many
SYNrequests, unable to process innocentSYNrequests because of overload.
ACK Flood
“An ACK flood is designed to disrupt network activity by saturating bandwidth and resources on stateful devices in its path.”
- You will send thousands of fake ACK packets that do not belong to any of the sessions on the server’s list of transmissions.
You -- Many random ACK's --> victim - The victim will send
RST(reset) packet because it never saw corresponding sequence of three-way handshake.You <-- RST -- victim - “Generally what is seen is a high rate of ACK packets (not preceded by a TCP handshake) and a slightly lesser rate of RST packets coming from the targeted server.”
- As a result, system resources are depleted to evaluate incoming packets and consequently reduce performance or cause a complete crash.
On wireshark
tcp.flags.ack == 1 to see ack packets.