SYN Flood Attack: The What, Impact, and Prevention Methods

What is a SYN Flood Attack?

A SYN flood attack is a denial-of-service (DoS) attack that sends a high volume of TCP SYN (synchronize) requests to a server and never completes the connection. The server holds each half-open connection in memory while it waits for a reply. Once its connection queue fills, it cannot accept requests from real users.

SYN floods target Layer 4 (the transport layer) of the OSI model. They abuse the TCP three-way handshake, the process every TCP connection uses to start. Any device that tracks connection state can be a target. This includes web servers, firewalls, load balancers and session management systems.

SYN stands for “synchronize.” It is the first packet a client sends to open a TCP connection. Because the attack leaves connections incomplete, it is also called a half-open attack.

How Does a SYN Flood Attack Work?

A SYN flood works by starting thousands of TCP handshakes and abandoning each one before the final step. To see why that hurts, start with a normal handshake.

The normal TCP three-way handshake

1. SYN: The client sends a SYN packet to the server to request a connection.
2. SYN-ACK: The server replies with a SYN-ACK. It also reserves memory for the connection and places it in a queue, called the SYN backlog.
3. ACK: The client sends an ACK. The connection opens and data can flow.

What changes during an attack

1. The attacker sends a flood of SYN packets, often from fake source IP addresses.
2. The server answers each one with a SYN-ACK and adds an entry to its backlog.
3. The final ACK never arrives. The server keeps each entry open and resends the SYN-ACK several times before it gives up.
4. New SYN packets arrive faster than old entries expire. The backlog fills.
5. The server drops new connection requests, including those from legitimate users.

The attacker does not need much bandwidth to cause this. The damage comes from exhausting the connection table, a fixed resource on the target.

Types of SYN Flood Attacks

Attackers run SYN floods in three ways. They differ in where the packets come from and how hard they are to trace.

1. Direct SYN flood attack

The attacker sends SYN packets from their own IP address. They block their own system from answering the server’s SYN-ACK, usually with a firewall rule. Without that rule, their operating system would send a reset (RST) and free the server’s resources.

This method exposes the attacker’s IP. A single blocking rule can stop it, so attackers rarely use it.

2. Spoofed SYN flood attack

The attacker forges the source IP address on every SYN packet. The server sends its SYN-ACK to the forged address. That address either does not exist or never sent a request, so no ACK comes back.

Spoofing hides the attacker and makes IP blocking useless. Each packet can carry a different fake address.

3. Distributed (DDoS) SYN flood attack

A botnet of compromised devices sends SYN packets to the target at the same time. Each device may send a modest amount of traffic. Together, they overwhelm the target.

The traffic comes from real, varied IP addresses across many networks. This makes it hard to separate attack traffic from real users. Botnet operators can also combine distribution with spoofing.

SYN Flood vs SYN-ACK Flood vs ACK Flood

All three are TCP floods that abuse the handshake. Each one targets a different step, so each needs a slightly different defense.

A SYN-ACK flood can also be a reflection attack. The attacker sends spoofed SYN packets to many third-party servers using the victim’s IP address. Those servers all send their SYN-ACK replies to the victim.

Other TCP floods include RST floods and PSH floods. They follow the same pattern: send packets the target must process, at a rate it cannot sustain.

What is the Impact of a SYN Flood Attack?

A successful SYN flood takes a service offline for legitimate users. The effects spread to the network, the business and its reputation.

The Mirai botnet shows the scale these attacks can reach. Mirai infected IoT devices such as cameras and routers by logging in with default passwords. At its peak in 2016, it controlled about 600,000 devices (USENIX Security 2017). TCP SYN floods were one of its built-in attack modes, along with ACK, UDP, GRE and HTTP floods.

Mirai attacks hit KrebsOnSecurity, the hosting provider OVH and the DNS provider Dyn. The Dyn attack in October 2016 disrupted access to major sites, including GitHub, Netflix, PayPal, Reddit and Twitter.

The main consequences of a SYN flood are:

• Resource exhaustion: Half-open connections consume the connection table, memory and CPU on the target.
• Service outage: New connection requests are dropped. Real users cannot reach the site or application.
• Collateral damage: Firewalls and load balancers in front of the target can fail first, taking down other services behind them.
• Higher latency: Even before a full outage, users see slow page loads and timeouts.
• Operational cost: Teams spend hours on emergency response, and cloud bills can spike from the extra traffic.
• Revenue and reputation loss: Downtime stops transactions and erodes customer trust.
• Cover for other attacks: Attackers sometimes use a flood to distract security teams while they attempt an intrusion elsewhere.

For broader guidance, see our DDoS protection best practices.

How to Detect SYN Flood Attacks?

The clearest sign of a SYN flood is a large, sudden rise in half-open connections that never complete. Traffic spikes alone do not confirm an attack. A product launch or a sale can cause one too. Compare these signals against your normal baseline:

• Rising SYN_RECV count: Many connections stuck in the SYN_RECV state, with few moving to ESTABLISHED.
• High SYN-to-ACK ratio: Far more inbound SYN packets than completed handshakes.
• Dropped or overflowing SYN backlog: The kernel reports dropped SYNs or full listen queues.
• Many source IPs with one packet each: A sign of spoofed traffic.
• Slow or unresponsive services: Timeouts on new connections while existing sessions still work.

Commands to check a Linux server

Count connections waiting in the SYN_RECV state:

ss -n state syn-recv | wc -l

Check whether the kernel is dropping SYNs or sending SYN cookies:

netstat -s | grep -i -E "SYNs to LISTEN|listen queue"
nstat -az TcpExtSyncookiesSent TcpExtListenDrops

A few hundred SYN_RECV entries on a busy server can be normal. Thousands that keep growing are not.

What does “Possible SYN flooding on port” mean?

Linux writes this message to the kernel log when a listening port’s SYN backlog fills up:

TCP: request_sock_TCP: Possible SYN flooding on port 8291. Sending cookies. Check SNMP counters.

It means the server switched to SYN cookies to keep accepting connections. The port number tells you which service is under pressure. Port 8291, for example, is MikroTik’s Winbox management port, a frequent target of internet scans.

The message does not always mean an attack. A legitimate traffic burst or a backlog set too small can trigger it. Check the SYN_RECV count and source IPs. If the port is a management interface, restrict it to trusted IP addresses.

How to Protect Against SYN Flood Attacks?

The most effective way to prevent SYN flood attacks is to layer defenses at three levels: the server, the network edge and the cloud. Server settings help a host survive small floods. Edge devices filter traffic before it reaches the host. Cloud scrubbing absorbs floods too large for your own links.

Server-level protection

1. Enable SYN cookies

SYN cookies let a server answer SYN requests without storing any state. The server encodes the connection details into the sequence number of its SYN-ACK. If a real client replies with an ACK, the server decodes that number and opens the connection. Spoofed requests never reply, so they cost the server nothing.

On Linux, SYN cookies activate only when the backlog overflows. Normal traffic keeps full TCP features.

2. Increase the SYN backlog

A larger backlog queue holds more half-open connections before the server starts dropping requests. This buys time during short floods. It also uses more memory, so size it to your hardware.

3. Reduce SYN-ACK retries

By default, Linux resends an unanswered SYN-ACK five times over about a minute. Lowering retries to two frees each stale entry in a few seconds. The backlog then drains faster.

4. Recycle the oldest half-open connections

When the backlog is full, some TCP stacks and firewalls can overwrite the oldest half-open entry with a new request. Real clients usually complete the handshake quickly. Old entries are most likely attack traffic.

A starting point for Linux hardening (test before production use):

# /etc/sysctl.d/99-syn-flood.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.core.somaxconn = 4096
net.ipv4.tcp_synack_retries = 2

Apply the settings with sysctl --system. Your application’s own listen backlog must also be large enough to use the new limit.

Network-level protection

5. Rate-limit SYN packets

Rate limiting sets a ceiling on how many new connections a source, subnet or port can open per second. Excess SYNs are dropped or delayed. Per-source limits work well against direct floods. Spoofed floods need global limits, since each packet can carry a new address.

6. Filter malicious and spoofed traffic

Block traffic from known malicious IP addresses and from address ranges that should never appear on the internet. Ask your ISP to apply ingress filtering (BCP 38), which drops packets with forged source addresses close to where they enter the network.

7. Use a SYN proxy

A firewall, load balancer or reverse proxy can complete the handshake on the server’s behalf. It forwards only connections that finish with a valid ACK. The backend server never sees half-open connections. Linux supports this through the iptables and nftables SYNPROXY target.

8. Distribute load with load balancers

Load balancers spread connection requests across many servers so no single host takes the full flood. Most also include SYN flood protection. Check that the load balancer itself has enough connection capacity, since it becomes the first target.

Cloud-level protection

9. Use cloud-based DDoS protection

Large distributed SYN floods can exceed your internet bandwidth before any on-premise device can act. Cloud DDoS protection routes traffic through a global network that absorbs the flood and forwards only clean traffic to your origin. This is the only practical defense against multi-gigabit attacks.

10. Monitor continuously and set alerts

Track SYN rates, SYN_RECV counts and backlog drops against a normal baseline. Alert on deviations so your team can respond in minutes. Attacks often change vectors mid-incident, so monitoring should continue until traffic returns to baseline.

11. Combine methods into a layered defense

No single technique stops every SYN flood. SYN cookies protect the host. Edge filtering and SYN proxies stop medium floods. Cloud scrubbing handles the largest attacks. Together, they keep services online if one layer is overwhelmed.

For a comparison of tools, see our guide to the top DDoS protection software.

Stop SYN Floods Before They Reach Your Servers

Server tuning and edge devices help, but large floods need capacity and expertise most teams cannot staff around the clock. That is the gap AppTrana closes.

AppTrana’s DDoS protection inspects traffic at an autoscaling edge before it reaches your origin. Behavioral models learn your normal traffic and adjust thresholds in real time, so floods are blocked while real users get through. 24×7 expert monitoring is built in. When an attack shifts vectors, a named expert tunes the response with you.

• Unmetered DDoS protection: You pay for clean traffic that reaches your origin. Attack traffic does not show up on the bill.
• 100% uptime SLA across web applications, APIs and AI applications.
• Protection for AI applications: The same edge shields AI endpoints from request floods and denial-of-wallet abuse. Abusive inference traffic is throttled before token-burning calls reach expensive backend services.

Start a free trial to see how AppTrana handles SYN floods and other DDoS attacks.

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.