A DDoS Attack Explained: TCP ACK

We’re continuing along with our explanations of types of DDoS attacks today, with emphasis on the TCP ACK flood. Much like we discussed on Tuesday, this form of attack is a part of making a TCP connection. When a client establishes a TCP connection to a server, the connection goes through a three step process.

1. SYN packet. During this stage, a client (such as a desktop computer, laptop, or smartphone) initiates an outgoing connection to a server (such as a web or gaming server).
2. SYN-ACK packet. The server responds with an acknowledgement of the initial request, signaling it is ready to finish initiating the connection.
3. ACK packet. The client sends a final acknowledgment, signifying that both the client and server are ready to send and receive data.
This process is known as a “three-way handshake”.

An ACK flood, as the name describes, involves sending a whole bunch of TCP packets with the ACK bit enabled on it. This kind of DDoS attack has its advantages and disadvantages when compared to the more common SYN flood.

First, let’s take a look at what an ACK flood looks like. This is a spoofed ACK flood against server IP address 10.100.101.102 on port 80.

20:02:48.983378 IP (tos 0x0, ttl 63, id 32488, offset 0, flags [none], proto TCP (6), length 40) 222.83.14.144.1040 > 10.100.101.102.80: Flags [.], cksum 0xb469 (correct), seq 751014783, ack 2048786021, win 512, length 0 0x0000: 4500 0028 7ee8 0000 3f06 40a3 4814 160e E..(~...?.@.H... 0x0010: 4814 160f 0410 0050 2cc3 937f 7a1d fe65 H......P,...z..e 0x0020: 5010 0200 b469 0000 0000 0000 0000 P....i........ 20:02:49.983439 IP (tos 0x0, ttl 63, id 43793, offset 0, flags [none], proto TCP (6), length 40) 114.80.136.184.1041 > 10.100.101.102.80: Flags [.], cksum 0x1c45 (correct), seq 135907827, ack 760402314, win 512, length 0 0x0000: 4500 0028 ab11 0000 3f06 147a 4814 160e E..(....?..zH... 0x0010: 4814 160f 0411 0050 0819 c9f3 2d52 d18a H......P....-R.. 0x0020: 5010 0200 1c45 0000 0000 0000 0000 P....E........ 20:02:50.983479 IP (tos 0x0, ttl 63, id 44213, offset 0, flags [none], proto TCP (6), length 40) 223.4.31.169.1042 > 10.100.101.102.80: Flags [.], cksum 0x3320 (correct), seq 227681609, ack 1655186570, win 512, length 0 0x0000: 4500 0028 acb5 0000 3f06 12d6 4814 160e E..(....?...H... 0x0010: 4814 160f 0412 0050 0d92 2549 62a8 248a H......P..%Ib.$. 0x0020: 5010 0200 3320 0000 0000 0000 0000 P...3......... 20:02:51.983525 IP (tos 0x0, ttl 63, id 52759, offset 0, flags [none], proto TCP (6), length 40) 202.116.160.1043 > 10.100.101.102.80: Flags [.], cksum 0x5f9f (correct), seq 379954490, ack 794534482, win 512, length 0 0x0000: 4500 0028 ce17 0000 3f06 f173 4814 160e E..(....?..sH... 0x0010: 4814 160f 0413 0050 16a5 a53a 2f5b a252 H......P...:/[.R 0x0020: 5010 0200 5f9f 0000 0000 0000 0000 P..._......... 20:02:52.983569 IP (tos 0x0, ttl 63, id 23290, offset 0, flags [none], proto TCP (6), length 40) 200.27.175.70.1044 > 10.100.101.102.80: Flags [.], cksum 0x8634 (correct), seq 242507686, ack 1779207888, win 512, length 0 0x0000: 4500 0028 5afa 0000 3f06 6491 4814 160e E..(Z...?.d.H... 0x0010: 4814 160f 0414 0050 0e74 5fa6 6a0c 8ed0 H......P.t_.j... 0x0020: 5010 0200 8634 0000 0000 0000 0000 P....4........ 20:02:53.983607 IP (tos 0x0, ttl 63, id 42657, offset 0, flags [none], proto TCP (6), length 40) 219.137.229.214.1045 > 10.100.101.102.80: Flags [.], cksum 0x03ae (correct), seq 984467710, ack 563135552, win 512, length 0 0x0000: 4500 0028 a6a1 0000 3f06 18ea 4814 160e E..(....?...H... 0x0010: 4814 160f 0415 0050 3aad c8fe 2190 c440 H......P:...!..@ 0x0020: 5010 0200 03ae 0000 0000 0000 0000 P.............

The [.] flag indicates that it is an ACK packet.

Where The ACK Flood Flows

When a server encounters any TCP packet, it will only accept the packet if there is an already established TCP connection between the source and destination.
There are two common scenarios where an ACK flood takes place:

1. The less common scenario: The attacker sends an initial SYN packet using a bunch of different spoofed IP addresses, calculates the sequence number, and then sends a bunch of properly constructed ACK packets from those same spoofed IP addresses. This keeps all of the connections in an open state, causing the server to run out of resources with seemingly legitimate connections that don’t close. This kind of attack is very difficult to pull off.
2. The more common scenario: The attacker just sends a whole bunch of TCP packets with the ACK bit enabled and the source IP spoofed. This kind of attack is very easy to execute.

Scenario 1’s advantage vs a SYN flood is that it actually opens a connection to the server, and can keep the connection open indefinitely. This is extremely effective when it comes to taking up server resources. A SYN flood on the other hand just opens up a half connection, which times out. It is also much simpler for a DDoS protection device or service to mitigate a SYN flood. The disadvantage is that it’s extremely difficult to execute this kind of attack.

In Scenario 2, the application receiving the packets will simply drop them because there are no active TCP connections between the source and the destination IP addresses. It doesn’t actually open any connections. The reason it’s effective is that the flood forces the server to drop the packets. This causes resource exhaustion as it has to process each packet. The server has to do the same kind of thing with a SYN flood, except it also opens a connection with the server, which is much more effective. The only advantage an ACK flood has is that DDoS protection devices and services are more tuned to handle SYN floods as they are significantly more common. An ACK flood is a clever way to potentially trick DDoS protection services into actually allowing the packets through the filter, which can end up overwhelming the server.