ACK Flood Attack Characteristics and Defense Strategies: Identification and Response

To analyze ACK Flood attack characteristics and defense strategies, the first step is to recognize this fingerprint: low inbound bandwidth, CPU and session table saturation first, and outbound RST spikes. It doesn't clog the line with massive traffic; instead, it overwhelms the receiver by sending forged ACK packets for non-existent connections, forcing repeated session table lookups and RST responses, draining computational power and outbound link. IETF RFC 4732 describes the mechanism, and AWS's DDoS elastic architecture guidance provides standard solutions.

Differentiate First: Low Bandwidth but Stalled – ACK Flood, SYN Flood, or Connection Pool Leak

When facing "server stalled but bandwidth low," don't jump to conclusions. Use three sets of phenomena to quickly differentiate:

• Inbound bandwidth: ACK Flood is usually flat or low; SYN Flood may also be low, but the half-open connection queue fills first.
• Half-open connection queue: SYN Flood shows obvious accumulation; ACK Flood doesn't occupy the half-open queue. For SYN Flood defense, refer to SYN Flood Defense.
• Business connection count curve: In connection pool leak, established connection count grows monotonically; during an attack, it's accompanied by RST responses from many unestablished packets.

Conclusion: The core characteristic of ACK Flood is not high bandwidth, but CPU and session table saturation first, along with abnormal outbound RST rates.

Attack Mechanism: Why Forged Unestablished ACKs Consume CPU and Outbound Bandwidth

According to RFC 4732, ACK Flood is a "state lookup exhaustion" attack. The receiver, upon receiving an ACK, must look up the packet in the connection tracking table to see if it belongs to an established connection; if not, it sends RST. Attackers send forged ACKs continuously, forcing the receiver to perform useless lookups, consuming CPU and outbound bandwidth, not inbound bandwidth. This explains why inbound bandwidth is low but the server is unresponsive.

Criterion 1: How to Capture Packets to Determine ACK Flood (Flags, Sequence Numbers, and Source IP Dispersion)

Packet capture is the most direct way to judge ACK Flood. Capture inbound packets at the server or firewall, focusing on three features:

1. Flags: Large number of pure ACK set without corresponding SYN preceding.
2. Sequence numbers: Sequence numbers don't correspond to local established sessions.
3. Source IP dispersion: Highly dispersed source IPs, each sending small volumes.

Note: Single indicators aren't conclusive; combine them. For example, normal business may have empty ACKs, but not simultaneously with "no SYN preceding" and "high source IP dispersion."

Criterion 2: How to Observe Session Table Growth and Lookup Overhead

Observe connection tracking table entry counts on both server and firewall sides. Under normal business, entries fluctuate naturally with connection creation/destruction. During an attack, new entries flood but most can't establish complete connections, so the table is filled with invalid entries, lookup hit rate drops, and kernel softirq usage rises.

Observation idea: Compare the baseline of "session table entries / lookup hit rate / softirq usage" before and after the attack. If entries climb rapidly while hit rate drops and softirq usage rises, it's likely ACK Flood consuming state lookup resources.

Criterion 3: Whether Outbound RST Rate and NIC PPS Hit Limits Before Bandwidth

ACK Flood triggers RST responses that form obvious pulses on the outbound side. Monitor "PPS" and "RST rate" instead of Mbps.

Set multiple-based alerts based on your own business baseline (e.g., significantly above historical peak and lasting minutes), not fixed absolute values. Absolute values are meaningless because NIC and CPU performance vary across servers.

Can Stateful Firewalls Defend Against ACK Flood? Why They Become the Bottleneck First

Back to the main line of ACK Flood characteristics and defense, the position of stateful firewalls needs reassessment. Stateful firewalls excel at tracking connection states but at the cost of doing state lookup for every packet. ACK Flood hits this most expensive path—the attack creates many missed lookups, exhausting firewall CPU before the business.

More critically, when attack packet counts max out NIC PPS or uplink, single-machine and single-point devices can't prevent upstream congestion. So, stateful firewalls in some scenarios not only fail to defend but become the first node to fall.

Three Things the Origin Server Can Do and Their Limits

At the origin server, some temporary mitigation measures:

These measures only buy time, not immunity. The real solution is to offload state lookup pressure from the origin.

Division of Labor: Move TCP Termination and State Maintenance to the Edge

The architecture recommended by AWS's white paper: Anycast edge handles TCP handshake and TLS termination, uses stateless validation like SYN Proxy/Cookies to intercept unestablished packets, and origin security groups only allow edge source IP whitelist. This way, ACK Flood is identified and dropped at the edge, and origin CPU isn't forced to do invalid lookups. Also, source whitelist convergence hides the origin—this is crucial: if the origin IP is leaked, attackers can bypass defenses and attack the origin directly. How to prevent origin real IP exposure should be addressed as a prerequisite.

The essence of this division is moving TCP termination and state maintenance from the origin to the edge closer to the attacker, letting state lookups happen on the cheap "stateless validation" path.

RockCloud's Role in Edge Termination and Origin Whitelist Convergence

In the above architecture, RockCloud's high-defense CDN with Anycast global network takes on the role of edge TCP connection handling and state maintenance. The origin only needs to open the source IP whitelist and not expose its public IP. This division follows the same architectural thinking as AWS's white paper; specific capability boundaries are per official documentation.

ACK Flood Troubleshooting Checklist (Ready to Use)

Here's a compressed, actionable checklist from the previous analysis. Follow these steps in order to quickly pinpoint the issue:

1. [ ] Compare inbound bandwidth and PPS: If bandwidth is normal but PPS is near NIC limit, suspect ACK Flood first.
2. [ ] Capture packets to check flags and sequence numbers: Pure ACK set without SYN preceding, highly dispersed source IPs.
3. [ ] Check session table entries and hit rate: Entries spike but hit rate drops.
4. [ ] Check outbound RST rate: Is it abnormally high?
5. [ ] Confirm if origin IP is leaked: If leaked, hide it first.
6. [ ] Verify source whitelist closure: Does the security group only allow edge source IPs?

If you confirm ACK Flood and the origin IP is leaked, refer to DDoS Emergency Response for immediate mitigation, then evaluate moving TCP termination to the edge.

FAQ

What's the difference between ACK Flood and SYN Flood?

SYN Flood exploits the half-open connection queue by sending many SYNs without completing the handshake, exhausting half-open resources. ACK Flood sends forged ACKs, forcing the receiver to traverse session tables and send RSTs, consuming CPU and outbound bandwidth. The former occupies memory and half-open connections; the latter consumes lookup computation and outbound link. For further reading, see SYN Flood Defense.

Is the server under attack if CPU is high but bandwidth is low?

Not necessarily, but it's a high priority. High CPU with low bandwidth could also be due to application-layer CC attacks, database slow queries, or business logic infinite loops. Use packet capture, session table, and outbound RST rate to judge, not just CPU alone.

What to do when firewall session table is full?

Temporarily increase connection tracking table capacity and timeout, and enable unused port drop policy. But the fundamental solution is to move TCP termination to the edge, so the origin and stateful firewalls don't bear the lookup pressure of unestablished packets. Otherwise, local tuning is just a stopgap.

Can stateful firewalls defend against ACK Flood?

Not fully. Stateful firewalls do state lookup for every packet to maintain connection states, and ACK Flood exploits this most expensive path. When attack packet counts max out NIC PPS or uplink, single-machine devices can't prevent upstream congestion. Use edge stateless validation plus source whitelist architecture.

Why are many RST packets sent out?

The most common reason is that the receiver receives TCP packets for non-existent connections (like ACK Flood) and replies with RST per protocol. It could also be due to local connection tracking table overflow, causing legitimate packets to be judged as misses. If RST rate is abnormally high with high CPU and low inbound bandwidth, it's likely ACK Flood.