Every TCP connection on the internet begins with a handshake. Your browser does it hundreds of times a day — connecting to websites, APIs, email servers, and cloud platforms. It’s a three-step process that takes milliseconds and happens invisibly.
A SYN flood turns that handshake into a weapon.
How TCP Connections Normally Work
Before any data can flow between two machines, TCP requires them to agree on a connection. This is the three-way handshake, and it works like this:
Step 1 — SYN. The client sends a packet with the SYN flag set, telling the server “I want to connect.” This packet contains the client’s initial sequence number — a random value that will be used to track data throughout the connection.
Step 2 — SYN-ACK. The server receives the SYN, allocates memory for the new connection (creating a Transmission Control Block, or TCB), and responds with a SYN-ACK packet. This says “I acknowledge your request and I’m ready.” The server then enters a state called SYN_RECEIVED and starts a timer, waiting for the client to complete the handshake.
Step 3 — ACK. The client responds with a final ACK packet. The connection is now ESTABLISHED, and both sides can exchange data.
This process is elegant and reliable. It’s also extraordinarily vulnerable to abuse.
Anatomy of a SYN Flood
In a SYN flood attack, the attacker sends thousands — or millions — of SYN packets to the target server but never sends the final ACK. Each SYN packet forces the server to allocate memory for a new connection, add it to the connection table, and start a timeout timer. The server sits in SYN_RECEIVED state, waiting for an ACK that will never arrive.
The math is devastating. A typical Linux server can hold between 128 and 1,024 half-open connections in its SYN backlog (depending on configuration). An attacker generating 100,000 SYN packets per second fills that backlog instantly. Once the table is full, the server cannot accept any new connections — not from attackers, and not from your actual customers.
The truly insidious part: each individual SYN packet looks exactly like a legitimate connection attempt. There’s no payload, no malformed header, no obvious indicator of malice. It’s a perfectly valid TCP packet doing exactly what TCP packets are supposed to do.
Why Source IP Spoofing Makes It Worse
Because the attacker never needs to complete the handshake, they don’t need to receive the server’s SYN-ACK response. This means they can forge (spoof) the source IP address in every packet. Each SYN appears to come from a different IP address around the world.
This has two consequences. First, the server sends its SYN-ACK responses to random IP addresses that never initiated a connection — wasting even more resources. Second, simple IP-based blocking is useless. You can’t block the source because every packet has a different, fabricated source address.
SYN Flood Variants
Not all SYN floods look the same. Attackers have developed several variants, each targeting a slightly different weakness:
| Variant | Technique | Why It’s Dangerous |
|---|---|---|
| Standard SYN Flood | High volume of SYN packets with spoofed sources | Fills connection table rapidly |
| SYN-ACK Reflection | Sends spoofed SYN packets to legitimate servers, which then flood the victim with SYN-ACK responses | The victim receives traffic from real, reputable servers — making filtering extremely difficult |
| Slow SYN Flood | Sends SYN packets at a low, steady rate — just enough to keep the connection table full without triggering volume-based alerts | Evades threshold-based detection systems |
| Distributed SYN Flood | Uses a botnet of thousands of real devices, each sending a small number of SYN packets | Each source looks legitimate; only the aggregate is an attack |
| SYN + Payload | Includes small data payloads in SYN packets, consuming additional server memory per connection | Accelerates resource exhaustion |
Why Traditional Defenses Fall Short
Over the years, the internet has developed several mechanisms to counter SYN floods. Each helps — but none is sufficient on its own.
SYN Cookies
Most modern operating systems implement SYN cookies — a technique where the server doesn’t allocate memory when it receives a SYN. Instead, it encodes the connection state into the initial sequence number of the SYN-ACK response. If the client completes the handshake with a valid ACK, the server reconstructs the connection from the cookie.
SYN cookies solve the memory exhaustion problem, but they introduce trade-offs. The server loses the ability to store TCP options during the handshake, which means features like window scaling and selective acknowledgment may be degraded. Under heavy attack, the server still spends CPU cycles generating and validating cookies for millions of fake connections. And SYN cookies provide zero visibility — you can’t distinguish attack traffic from legitimate traffic.
Firewall Rate Limiting
Traditional firewalls can rate-limit incoming SYN packets — say, no more than 1,000 SYN packets per second per destination IP. But this approach is indiscriminate. During an attack, the rate limiter drops packets randomly, and some of those dropped packets belong to your real users. You’re reducing the attack volume at the cost of degrading service for everyone.
Increasing the Backlog
You can raise the SYN backlog limit and reduce the SYN-ACK retransmission timeout. This buys time — a larger backlog takes longer to fill, and shorter timeouts reclaim stale connections faster. But it’s a tuning exercise, not a solution. A sufficiently large attack overwhelms any backlog size.
How Modern Mitigation Actually Stops SYN Floods
Effective SYN flood mitigation requires solving three problems simultaneously: identifying which SYN packets are malicious, dropping them before they consume server resources, and doing all of this without impacting legitimate connections.
Stateful Connection Validation
The most effective approach is intercepting the TCP handshake before it reaches your server. A mitigation engine positioned in front of your infrastructure acts as a proxy for the three-way handshake. When a SYN arrives, the engine responds with a SYN-ACK on behalf of your server. Only if the client completes the handshake with a valid ACK — proving it’s a real client with a real, un-spoofed IP address — does the engine establish a connection to your actual server and relay the traffic.
Spoofed SYN packets never generate a valid ACK, because the SYN-ACK response is sent to a fabricated address. The connection attempt dies silently. Your server never sees it, never allocates memory for it, and never knows it happened.
This is how CoreEdge™ handles SYN floods. The stateful engine tracks every TCP flow passing through the filtering layer, maintaining a connection table that operates independently from your server’s resources. The engine distinguishes between SYN packets that belong to real handshakes and SYN packets that are part of an attack — not by examining individual packets, but by observing whether the complete handshake sequence occurs.
CoreEdge™ exposes this through the MATCH_CONNECTION action in the firewall configuration. When applied to a prefix, every incoming TCP packet is evaluated against the tracked connection state. Packets that don’t belong to a verified flow — half-open connections that never completed, ACK packets referencing nonexistent sessions, RST packets for connections that were never established — are eliminated at the XDP layer before they consume a single CPU cycle on your server.
Per-Source Intelligence
Not every SYN flood uses spoofed sources. Botnets — networks of compromised devices — send SYN floods from real IP addresses. Each individual device might send only 50 SYN packets per second, which looks like normal browsing behavior. But when 50,000 devices do it simultaneously, your server receives 2.5 million SYN packets per second.
Per-source rate limiting solves this. Instead of a global SYN rate limit that punishes all traffic equally, CoreEdge™ applies limits on a per-source-IP basis. Each source IP address gets its own counter. A legitimate user sending 10 SYN packets per second passes through without interference. A bot sending 500 SYN packets per second gets throttled to whatever threshold you define — while every other user remains completely unaffected.
This is CoreEdge™‘s RATE_LIMIT_SRC action. You define the maximum packets per second any single source may send, and the filtering engine tracks each source independently. During a botnet-driven SYN flood, aggressive sources are throttled while legitimate sources never experience any impact.
TCP Flag Validation
Legitimate TCP traffic follows well-defined rules about which flag combinations are valid. A SYN packet should only have the SYN flag set. A SYN-ACK has both SYN and ACK. A packet with both SYN and FIN set simultaneously violates the TCP specification and is almost certainly malicious — no real operating system generates such packets.
CoreEdge™ inspects all six TCP flags — SYN, ACK, FIN, RST, PSH, and URG — on every packet. You can write rules that match specific flag combinations, dropping illegal combinations at wire speed. Flag validation catches not only SYN floods but also Christmas tree attacks (all flags set), null scans (no flags set), and other reconnaissance techniques that exploit non-standard TCP packets.
Granular TCP Controls
For networks that need precise control over TCP behavior, CoreEdge™ offers over a dozen TCP-specific parameters:
| Parameter | What It Controls |
|---|---|
| SYN rate limit | Maximum SYN packets per second allowed through the filter |
| Non-SYN rate limit | Separate limit for all other TCP packets — prevents ACK and RST floods |
| Allow established | Lets packets belonging to verified connections bypass deep inspection |
| Out-of-state action | Controls what happens to packets that don’t match any tracked connection |
| Flag validation | Enables automatic rejection of invalid TCP flag combinations |
| Max concurrent flows | Limits the total number of tracked connections — preventing state table exhaustion in the filter itself |
| Per-source flow limit | Caps how many simultaneous connections a single source IP can maintain |
| SYN timeout | How long to wait for a handshake to complete before discarding the half-open connection |
| Established timeout | How long an idle established connection is kept in state before cleanup |
| FIN timeout | How long to track connections in the closing phase |
These parameters aren’t theoretical. They’re accessible through the CoreTech Client Portal, where customers configure them directly on their assigned CoreEdge™ clusters. Every parameter takes effect within seconds of being saved.
Detecting a SYN Flood in Progress
If you suspect your network is under a SYN flood, here’s what to look for:
On your server, run netstat -s | grep -i syn or ss -s and watch the SYN_RECV counter. During normal operations, this number stays in the single digits or low hundreds. During a SYN flood, it spikes to thousands and stays there.
On your monitoring, look for a sharp divergence between inbound SYN packets and completed connections. If your server receives 100,000 SYN packets per second but only establishes 200 new connections, the remaining 99,800 are attack traffic.
On your bandwidth graphs, SYN floods are often smaller than volumetric UDP floods — sometimes only a few hundred megabits per second. Don’t let the low bandwidth fool you. A SYN flood doesn’t need to saturate your pipe; it only needs to exhaust your connection table.
On your applications, users report that the site is “slow” or “not loading” — but existing logged-in sessions continue working fine. This is the hallmark of connection table exhaustion: established connections are unaffected, but new connections cannot be created.
Why Speed of Mitigation Matters
SYN floods cause damage in seconds. From the moment the first spoofed SYN packet arrives, your connection table starts filling. Within 10 to 30 seconds, a high-volume SYN flood exhausts a default Linux backlog. Within a minute, even tuned servers with enlarged backlogs and aggressive timeouts begin rejecting legitimate connections.
This is why CoreDetection™ operates in real time. The behavioral engine monitors TCP connection patterns continuously — tracking the ratio of SYN to SYN-ACK to ACK across your traffic. When the ratio deviates from established baselines, CoreDetection™ classifies the anomaly, generates filtering rules, and deploys them to CoreEdge™ automatically. The entire sequence — detection, classification, rule generation, deployment — completes in under sixty seconds.
During those sixty seconds, CoreEdge™‘s pre-configured stateful filtering continues operating. If you’ve already configured MATCH_CONNECTION rules through the portal, attack packets are being dropped before CoreDetection™ even finishes its analysis. The automated rules serve as an additional layer — tightening rate limits, adjusting SYN timeouts, and adding per-source thresholds based on the observed attack pattern.
SYN Floods in the Wild: Real Numbers
SYN floods aren’t just a theoretical concern. They represent a significant and growing portion of DDoS attacks globally:
| Metric | Value |
|---|---|
| Percentage of all DDoS attacks | ~35-40% of all attacks include a SYN flood component |
| Average attack duration | 15-45 minutes |
| Typical volume | 1-50 million packets per second |
| Record SYN floods | 500+ million PPS in multi-vector campaigns |
| Cost per hour of downtime | $100,000 - $500,000+ for enterprise services |
| Time to exhaust default backlog | 10-30 seconds |
The financial impact extends beyond direct downtime. Payment processors facing SYN floods lose transactions. SaaS platforms lose customer trust. Gaming services lose players permanently. The reputational damage often outlasts the technical impact.
How CoreTech Handles SYN Floods
CoreEdge™ mitigates SYN floods at the XDP layer — the lowest point in the Linux networking stack where software can intercept packets. This means filtering happens at the network interface card, before the packet ever reaches the kernel’s TCP/IP stack.
The architecture works in three coordinated layers:
Layer 1 — Pre-configured rules. Customers define TCP filtering policies through the Client Portal: per-source SYN rate limits, flag validation, connection state tracking, and timeout parameters. These rules are always active, providing immediate baseline mitigation the moment attack traffic arrives.
Layer 2 — Autonomous detection. CoreDetection™ continuously analyzes traffic patterns. When a SYN flood signature emerges — abnormal SYN-to-ACK ratios, connection completion rates dropping below threshold, SYN backlog pressure indicators — it generates targeted mitigation rules and deploys them to CoreEdge™ within seconds.
Layer 3 — Adaptive response. As the attack evolves — sources change, rates fluctuate, vectors shift — CoreDetection™ adapts the filtering rules in real time. If an attacker switches from spoofed SYN to a botnet-driven SYN flood, the system shifts from stateful validation to per-source rate limiting automatically.
Your legitimate users experience nothing. Established connections continue uninterrupted. New connection attempts from real clients complete their handshake normally. Only attack traffic is eliminated — at wire speed, with zero added latency.
Start Your Free Trial
SYN floods can take your services offline in seconds. CoreEdge™ stops them in nanoseconds.
10-day free trial — full CoreEdge™ mitigation capacity, full CoreDetection™ behavioral analysis, full Client Portal access with self-service firewall management.
Want to see this in action?
Get a live demonstration of CoreTech's DDoS mitigation platform.
