TCP flag flood test

What a TCP flag flood does

A TCP flag flood sends a high rate of TCP segments carrying specific control flags — SYN, ACK, RST, FIN, or unusual combinations — that a target must inspect and classify. Stateful firewalls and connection-tracking tables spend work deciding whether each segment belongs to a known flow, and out-of-state control packets (a bare ACK or RST with no matching connection) can force extra lookups or table churn. At volume, that classification cost, rather than raw bandwidth, is what pressures the service.

Rotating the flag on every packet — rather than sending one flag steadily — is what distinguishes this technique: it stresses how a stateful device copes with constant flag changes and evades mitigation signatures that match a single flag. For a clean, isolated measurement of one vector, ddos-simulation.com also offers the single-flag floods individually — the ACK flood, plus dedicated RST and FIN floods, each sending one steady, named flag so a result maps to exactly one failure mode.

How ddos-simulation.com simulates it safely

ddos-simulation.com emits TCP control segments toward a single verified domain, pinned to a public address, from the worker's own source address — the flags are crafted, but the source is never forged. The packet rate stays inside the limits set for that domain, health checks watch the target throughout, and the run aborts itself the moment a threshold you set is crossed.

What the test exercises

• Stateful firewall and connection-tracking (conntrack) classification cost
• Evasion of mitigation signatures that key on a single flag
• Handling of out-of-state control packets (bare ACK, RST, FIN)
• TCP stack and CPU headroom under control-flag pressure
• Rate limiting and anti-flood policy on network middleboxes
• Time-to-degrade and recovery once the flood stops

When to run a TCP flag flood test

Run a TCP flag flood test when stateful middleboxes — firewalls, NAT, connection trackers — are the thing you need to stress.

• You want to see how stateful firewalls and connection-tracking tables handle out-of-state SYN, ACK, RST, and FIN segments.
• A NAT or load balancer keeps per-flow state and you need to confirm it doesn't exhaust under crafted control traffic.
• You're validating that anomaly-based mitigation flags and drops malformed or out-of-state segments.

How to run a TCP flag flood test

1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
2. Add the tcp_flag_flood command to a timeline in the portal and set the target port, flag mix, rate, and duration.
3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
5. Read the results. Review the recorded latency, reachability, and worker timeline to find where your service starts to bend.

Configure a TCP flag flood test in the portal →

Reading the results

Resilient: Out-of-state segments are dropped cheaply, connection-tracking stays within capacity, and legitimate sessions are untouched.

Under strain: The conntrack or firewall state table fills, CPU climbs handling control segments, or legitimate connections are evicted to make room.

Availability & limits

The TCP flag flood is a higher-impact network-layer technique, so it is reviewed and approved before it runs — beyond verifying you own the domain — and is priced per engagement — request a quote.

Frequently asked questions

Related simulations