What a SYN test validates
A SYN flood pressures the connection setup path. It can consume backlog capacity, connection-tracking resources, firewall lookups, provider mitigation, and CPU before the application receives a normal request.
A legal SYN test validates whether your own TCP services can keep accepting legitimate connections while half-open connection pressure rises.
Before the test
Confirm written authorization, the target port, maximum packet rate, duration, provider notification, and abort thresholds. Baseline normal connection rate, latency, CPU, backlog usage, firewall counters, and mitigation state before the run.
Make sure the service owner and network operator both understand the window. SYN tests often trigger real incident workflows.
During the test
Increase pressure in stages. Watch SYN-RECV counts, backlog saturation, firewall state-table use, dropped packets, clean connection success, and provider events. A good test measures whether real users can still complete handshakes.
If legitimate connections fail while bandwidth is still available, the bottleneck is likely state or connection handling rather than raw capacity.
Mitigation checklist
Common defenses include SYN cookies, SYN proxying, aggressive half-open timeouts, per-source connection limits, provider scrubbing, and enough backlog headroom. The right mix depends on where the test found the first failure.
- Enable and verify SYN cookies where appropriate.
- Use a SYN proxy or scrubbing provider for exposed services.
- Tune backlog and timeout values.
- Retest after each mitigation change.