SYN flood protection: mitigate TCP DDoS attacks without blocking real connections

Definition of the problem: what a SYN flood really tries to exhaust

A SYN flood targets the TCP connection opening mechanism. Under normal conditions, a client sends SYN, the server replies with SYN-ACK, and the client confirms with ACK. During an attack, the target receives an abnormal amount of SYN packets, often from spoofed, distributed or unstable sources. The server or an intermediate device may then keep state for connections that will never complete.

The effect is not just more traffic. It is pressure on connection resources: state tables, TCP backlog, firewall CPU, queues, memory, NAT systems, load balancers, reverse proxies or web servers. Even if the bandwidth in Gbps is below the advertised capacity, packets per second and incomplete states can make the service unavailable.

Modern SYN floods can also be mixed with other vectors. An UDP wave may saturate the link while SYN traffic exhausts stateful components. A defense based only on average bitrate or broad port blocking will not be enough. You need to know where saturation appears and which layer must be relieved first.

Backlog exhaustion

Too many incomplete handshakes prevent real clients from taking a place in the TCP queue.

Stateful device pressure

Firewalls, NAT and load balancers can fail before the origin server does.

Spoofed or distributed sources

Packets can come from many IPs, sometimes forged, making source-only blocking unreliable.

Why it matters for an infrastructure that sells online

For the end user, a SYN flood does not look like a network attack. It looks like a page that does not load, a panel that rejects connections, an API timeout, a game service becoming unstable or a professional service appearing offline. If the service drives leads, customers or revenue, a few minutes of unavailability can be enough to lose sales and trust.

The difficulty is that TCP is everywhere: websites, APIs, SSH, customer panels, proxies, load balancers, tunnels and business services. Over-aggressive mitigation can therefore create major false positives. Blocking an exposed TCP port may stop the attack graph, but it also cuts the service. The right design must maintain enough capacity and precision for legitimate clients to keep establishing sessions.

This matters even more for companies growing through online visibility, LinkedIn or X. A hard-earned prospect must land on infrastructure that is reachable. DDoS protection becomes a commercial topic as much as a technical one: it protects conversion, credibility and continuity.

Possible solutions against SYN floods

The first known response is to enable TCP protections at system level, such as SYN cookies, backlog tuning and kernel thresholds. These mechanisms are useful, but they are not a full answer. They help the server avoid reserving resources too early, but they do not protect the link, router, firewall or load balancer when the attack already reaches too far into the architecture.

Rate limiting can also reduce obvious noise. It becomes risky when legitimate traffic actually grows or when the attack imitates normal openings. A threshold that is too low blocks real users; a threshold that is too high does not protect enough. Rate limiting must be contextualized by service, port, expected behavior and real capacity.

ACLs, stateless filtering, packet-size checks, TCP flag logic and network characteristics can be very effective when applied early. But they must be precise. A broad rule can cut users, disturb network paths or break specific services. This is why upstream filtering, scrubbing and clean delivery become necessary once exposure becomes serious.

SYN cookies and kernel tuning

Useful to harden the origin, insufficient against upstream saturation.

Contextual rate limiting

Effective when thresholds match the real service, not a copied generic profile.

Early stateless filtering

Reduces pressure before devices that would otherwise keep state on noise.

Protected transit or scrubbing

Cleans traffic before production and delivers only usable flows.

TCP filtering adapted to the real service, not a generic rule

Traffic can enter through Anti-DDoS protected IP transit with BGP, protected IPs, GRE/IPIP/VXLAN tunnels or cross-connect depending on the architecture. The value is to place mitigation before the attack reaches the customer’s most fragile equipment. Clean traffic is then delivered back in a readable handoff model that respects network constraints.

For highly volumetric or high-PPS waves, filtering can also be combined with upstream relief when the goal is to reduce noise before it consumes port or processing capacity. The use must remain precise, temporary and proportionate: the goal is not to blackhole the customer, but to shave the attack enough for fine mitigation to remain in control.

Depending on the customer, the same logic can protect BGP-enabled IP transit, an exposed dedicated server, a web panel, an API or a game service that depends on stable TCP connections such as Minecraft. The key is to choose the right filtering point and clean delivery model instead of applying one generic rule to the whole infrastructure.

• identify where pressure appears: link, firewall, load balancer, kernel or application
• filter clearly illegitimate traffic as early as possible
• avoid expensive stateful logic on the hot path
• keep clean delivery readable: cross-connect, GRE, IPIP, VXLAN or router VM
• adapt the profile to the service instead of applying one model to every customer

A web service and customer panel under SYN flood

Imagine a hosting provider or SaaS platform with a commercial website, a customer panel and several exposed TCP services. The attack begins with moderate Gbps, but a very large number of SYN packets per second. The link may not be full, yet customers see timeouts. The stateful firewall starts consuming CPU and the load balancer keeps too many incomplete states.

The expected result is not magic; it depends on the service, volume, network path and legitimate behavior. But the design becomes much cleaner. The customer is no longer trying to save a drowning server alone; they receive reduced, more readable traffic closer to what the application can actually process.

1. Baseline

   Understand normal TCP traffic: ports, opening rate, expected peaks and user profile.

2. Detection

   Identify SYN flood signals: SYN/ACK imbalance, unstable sources, abnormal PPS or backlog pressure.

3. Filtering

   Drop inconsistent traffic early and avoid making stateful layers process noise.

4. Delivery

   Return clean traffic to the customer through the best integration model.

Frequent mistakes to avoid

A SYN flood looks simple, so many teams handle it with one rule. That is often not enough. The real question is which resource is failing and where in the path the decision must happen.

A second mistake is to confuse server hardening with network protection. Hardening Linux, Nginx or HAProxy helps, but it does not protect a saturated port or an already overloaded firewall. The server cannot filter packets that no longer reach it, or that have already broken an intermediate layer.

• watching only Gbps and ignoring packets per second
• enabling a global rate limit without knowing legitimate traffic
• placing the first real defense behind a fragile stateful firewall
• blocking all new connections and calling it mitigation
• forgetting to test clean traffic delivery before a real attack

FAQ