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.
How ddos-sim.com simulates it safely
ddos-sim.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.
Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.
What the test exercises
- Stateful firewall and connection-tracking (conntrack) classification cost
- 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
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
tcp_flag_floodcommand to a timeline in the portal and set the target port, flag mix, rate, and duration. - Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
- Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
- Read the results. Review the recorded latency, reachability, and worker timeline to find where your service starts to bend.
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
Does the TCP flag flood spoof source addresses?
No. Every segment is emitted from the worker's own public address. The TCP control flags are crafted, but the source is never forged.
How is this different from a SYN flood?
A SYN flood pressures the half-open backlog with SYN segments alone. A TCP flag flood sends a mix of control flags — SYN, ACK, RST, and FIN — to exercise stateful firewalls and connection-tracking logic that treats each flag differently.
Rehearse a TCP flag flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan