Most external security checks are passive — they observe what is visible and report it. But some weaknesses only reveal themselves under load. The intrusive TCP SYN check actively sends a controlled burst of TCP SYN packets to a known-open port and measures how the host responds during the flood. This case shows what that test found on a live host, and why even a mild result matters beyond the targeted port.
What is a TCP SYN flood and why does it affect the whole host?
When a TCP connection is established, the initiating side sends a SYN packet. The server allocates a small data structure — a half-open connection entry — and replies with SYN-ACK, waiting for the final ACK to complete the handshake. Under normal traffic this takes milliseconds. Under a SYN flood, thousands of SYNs arrive per second with no ACK completing them, filling the half-open connection table until it is exhausted.
The critical detail is that this table is shared kernel infrastructure, not per-service. Once it fills, the operating system drops incoming SYNs to every listening port simultaneously — not just the one being flooded.
On Windows Server
The Windows TCP/IP stack is implemented in tcpip.sys, a kernel-mode driver. It maintains a global half-open connection table governed by two registry parameters under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:
- TcpMaxHalfOpen — maximum half-open connections before the stack enters SYN attack protection mode (default 100–500 depending on edition)
- TcpMaxHalfOpenRetried — threshold for connections that have been SYN-ACKed but not yet completed
Once these limits are breached, Windows begins discarding incoming SYN packets indiscriminately. RDP on port 3389, SMB on port 445, WinRM on ports 5985–5986, IIS on port 80 or 443 — all stop accepting new connections. The Windows Defender Firewall does not help here; the drop occurs at the TCP layer inside tcpip.sys, before firewall rules are evaluated. Existing established sessions may survive, but no new connection to any service can be opened until the flood subsides and the half-open table drains.
On Linux production systems
Linux governs the SYN backlog through two kernel parameters: net.ipv4.tcp_max_syn_backlog (the per-socket SYN queue depth, default 128–256) and net.core.somaxconn (the global accept queue ceiling). Under a SYN flood the kernel allocates a request socket for every incoming SYN. When the queue fills, subsequent SYNs are silently dropped for all services.
Linux has SYN cookie support (net.ipv4.tcp_syncookies=1), which encodes connection state into the sequence number instead of allocating a queue entry. This helps, but under high packet rates it introduces its own costs: the ksoftirqd and kworker kernel threads consume CPU cycles verifying cookies for every arriving SYN, reducing scheduling headroom for all userspace processes — databases, web servers, SSH daemons — running on the same machine. When SYN cookies activate, TCP options such as window scaling and selective acknowledgement are also silently disabled for new connections, reducing throughput for legitimate traffic that does connect.
What the intrusive test checks
The check sends a controlled stream of TCP SYN packets at a fixed packets-per-second rate to a port confirmed open on the target. Throughout the burst it measures:
- Response ratio — the percentage of SYNs that received a SYN-ACK, indicating the stack is still processing handshakes
- RTT and RTT spread — round-trip time for responses during the flood; a rising spread indicates the kernel is queuing and delaying replies under load
- Packet loss — SYNs sent versus responses received over the test window
The result is an interpretation: RESILIENT (no measurable degradation), SLIGHTLY DEGRADED (mild but detectable impact), DEGRADED (significant drop in response ratio or RTT instability), or INCONCLUSIVE (upstream filtering absorbed the packets before reaching the host).
What the test found
A 5-second burst of 500 SYN packets per second (PPS) was directed at port 22 (SSH) on the target host — a port confirmed open before the test. The burst delivered approximately 712 Kbps of traffic, a very modest load by attack standards.
- Packets transmitted: 2,500
- Packets received: 2,478 (response ratio: 99.1%)
- Packet loss: 1.0%
- RTT min / avg / max: 29.0 ms / 36.1 ms / 121.9 ms
- RTT spread: 92.9 ms
Verdict: SLIGHTLY DEGRADED. The host continued responding throughout the burst, but the RTT spread of 92.9 ms tells a more revealing story. The minimum round-trip was 29 ms — the baseline latency to this host. The maximum reached 121.9 ms, nearly four times baseline, during a burst of just 500 PPS. This latency spike indicates the kernel was queuing SYN processing under a load that would be considered negligible in a real attack scenario.
Real-world SYN floods are commonly measured in tens of thousands to millions of PPS. At 500 PPS the host already showed queuing delays; at 50,000 PPS the half-open connection table would almost certainly exhaust, bringing every listening service — not just SSH — to a halt. The 1% packet loss at low rate also suggests that some SYNs were already being dropped or delayed before the handshake completed, consistent with a host that has limited SYN backlog headroom and no upstream SYN-proxy protection.
What this means in practice
A host that degrades under a 500 PPS burst is exposed to a denial-of-service risk that requires no vulnerability in any application, no credentials, and no CVE. Any attacker who can reach an open port can attempt this. The impact is not limited to the flooded service — once the TCP stack is saturated, RDP, HTTP, database connections, and monitoring agents all stop accepting new sessions simultaneously.
The robust mitigation is SYN flood protection at a network device upstream of the host — a firewall, load balancer, or DDoS scrubbing service that can issue SYN proxies or SYN cookies on behalf of the host before traffic ever reaches the server's kernel. On the host itself, tuning tcp_max_syn_backlog on Linux or TcpMaxHalfOpen on Windows raises the threshold but does not eliminate it. For any host running services that must remain available under adversarial conditions, the only reliable defence is absorbing or filtering the flood before it reaches the kernel's connection table.