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.
A
will send aSYN
(chronize) packet toB
with 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.
B
receives a frame fromA
and will send aSYN + ACK
frame as a reply.SYN
is to start the conversation andACK
is just proof to the client that the ACK is specific to the SYN the client initiated.A <--SYN + ACK (seq = y, ack = x + 1)-- B
A
sends back anACK
frame toB
to acknowledge the request fromB
for synchronization.A --ACK (ack = y + 1)--> B
SYN Flood
- You send many
SYN
packets to the victim to seem to be establishing a connection with it. - But you never receive
SYN + ACK
packet back from the victim. The connection is therefore half-opened. - The victim (probably a server) will be loaded up with many
SYN
requests, unable to process innocentSYN
requests 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.