A TCP SYN flood is a denial-of-service (DoS) attack that exploits the resources required to establish TCP connections. By sending large volumes of connection requests without completing the TCP handshake, an attacker can exhaust server connection queues, state-tracking resources, or other network capacity. Effective detection combines packet-level analysis, connection-state monitoring, traffic baselining, and infrastructure-level mitigation.
A web server receives thousands of connection requests every second. Normally, this is expected behaviour: users open websites, applications establish API connections, and services communicate across networks.
But what happens when a large proportion of those requests never progress into established connections?
The server may continue allocating resources to connection attempts that do not complete. As incomplete connections accumulate, the system can struggle to process legitimate requests. Users may experience slow responses, connection timeouts, or complete service unavailability.
This is the principle behind a TCP SYN flood.
Unlike an attack that overwhelms a service purely through application requests, a SYN flood targets the connection-establishment process itself. Its impact depends on the victim's TCP implementation, backlog configuration, network capacity, firewall behaviour, and the volume and characteristics of the incoming traffic.
For SOC analysts and network defenders, understanding this attack requires more than counting packets. The investigation must determine whether the TCP handshake is completing normally, where connection state is being maintained, and which resource is becoming exhausted.
TCP uses a three-way handshake to establish a reliable connection between two endpoints.
<box border radius="lg" padding={4} gap={3}> <box background="surface-secondary" radius="md" padding={3} align="center" gap={1}> **Client**
<text color="secondary" size="sm">Initiates the connection</text></box> <box align="center" gap={1}> <icon name="arrow-down" size="xl" /> <title size="md">SYN</title> <text color="secondary" size="sm">Requests a TCP connection</text> </box> <box background="surface" border radius="md" padding={3} align="center" gap={1}> **Server**
<text color="secondary" size="sm">Processes the request and responds</text></box> <box align="center" gap={1}> <icon name="arrow-up-down" size="xl" /> <title size="md">SYN-ACK</title> <text color="secondary" size="sm">Acknowledges the request and waits for the final acknowledgement</text> </box> <box background="surface-secondary" radius="md" padding={3} align="center" gap={1}> **Client sends ACK**
<text color="secondary" size="sm">The handshake completes and the connection can proceed</text></box> </box>
The three steps are:
SYN: The client requests a connection and sends an initial sequence number.
SYN-ACK: The server acknowledges the request and supplies its own sequence number.
ACK: The client acknowledges the server's response, completing the handshake.
The server must handle the initial request and retain or otherwise manage enough state to continue the connection-establishment process. The precise implementation depends on the TCP stack and its configuration.
A SYN flood abuses the difference between the cost of generating connection requests and the resources required to process them.
A TCP SYN flood is a denial-of-service attack in which a target receives a high volume of TCP SYN packets that initiate connections but do not result in a corresponding volume of completed handshakes.
The attack can leave the server or an intermediary device managing a large number of incomplete connection attempts.
Under normal conditions, these attempts eventually complete or expire. During a flood, new requests may arrive faster than the infrastructure can process or clear them.
Potential consequences include:
Exhaustion of pending connection-queue capacity.
Increased memory or processing pressure.
Delays in establishing legitimate connections.
Dropped connection requests.
Reduced availability of the affected service.
A SYN flood does not necessarily require the attacker to complete TCP connections or transmit large volumes of application data.
TCP is a stateful protocol. Endpoints maintain information about connections so that data can be delivered reliably and in the correct order.
During connection establishment, servers and network devices may allocate resources or track pending requests. If too many incomplete requests accumulate, the system can reach a resource limit.
This is why SYN floods are often described as attacks against connection-state management.
However, not every SYN flood causes the same failure. Some target server-side connection queues, while others overwhelm a firewall, load balancer, or network link. The correct diagnosis depends on where the resource bottleneck occurs.
A typical attack can be understood as a sequence of events.
The target receives an unusually high rate of TCP connection requests, often directed at a specific service such as HTTPS on TCP port 443.
The source addresses may be diverse, and the traffic may originate from compromised devices or distributed infrastructure.
The server or an upstream device processes the connection requests and sends responses to the apparent source addresses.
If the final ACK does not arrive, the connection-establishment process remains incomplete until the relevant state expires or is otherwise cleared.
When the arrival rate exceeds the system's ability to complete or clear connection attempts, the number of pending connections may increase.
The actual effect depends on queue sizes, retransmission behaviour, timeout settings, SYN-cookie support, and other implementation details.
If resources become constrained, legitimate clients may be unable to establish new connections reliably.
An application may appear unavailable even when its underlying processes remain running.
This distinction is important: a SYN flood can affect the connection layer without requiring the application itself to be compromised.
Some SYN floods use forged source IP addresses. The attacker sends connection requests that appear to originate from addresses that did not actually initiate them.
If the apparent source does not respond to the server's SYN-ACK, the handshake remains incomplete.
Spoofing can complicate investigation because the source IP addresses observed in server logs may not identify the real attacker.
However, not every SYN flood uses spoofed traffic. Attacks can also originate from real systems, botnets, or distributed sources with valid source addresses.
Analysts should avoid attributing the attack solely from the source-address list.
Instead, examine traffic volume, packet characteristics, upstream telemetry, source distribution, routing information, and the network provider's observations.
Where spoofing is suspected, upstream network evidence and anti-spoofing controls can help establish the likely traffic path.
Detection should focus on the relationship between connection attempts and successful handshakes, not simply the total number of SYN packets.
No single indicator proves that a SYN flood is occurring. For example, a sudden rise in SYN traffic can result from a legitimate launch, a traffic surge, or a network fault.
The strongest assessment combines packet-level evidence with the condition of the affected service.
Identify the target IP address, TCP port, affected network segment, and time window.
Determine whether the reported outage affects one service, several services on the same host, or multiple systems behind a shared network device.
Use an authorised packet capture or network monitoring platform to examine TCP flags and handshake progression.
A basic packet capture for traffic involving TCP port 443 can be performed in an approved investigation environment with a tool such as Wireshark or tcpdump.
Example command for a Linux-based monitoring system:
sudo tcpdump -nn -i eth0 'tcp port 443'Replace eth0 with the appropriate interface and adjust the port to match the affected service. Use a capture filter and retention period appropriate to the investigation.
This command displays matching packets; it does not independently identify a SYN flood. Analysts should examine SYN, SYN-ACK, and ACK patterns and correlate them with system metrics.
Where the available telemetry supports it, compare:
Incoming SYN packets.
Outgoing SYN-ACK packets.
Incoming final ACK packets.
Established connection counts.
Retransmissions and incomplete handshakes.
Interpret these measurements carefully. Packet loss, asymmetric routing, capture-point placement, and missing telemetry can make the handshake appear incomplete even when some connections are healthy.
Review the server's pending connection queues, established connection counts, CPU and memory utilisation, and network-stack metrics.
Also examine firewalls, load balancers, and intrusion-prevention systems. An intermediary device may exhaust its own connection-tracking resources before the server reaches its limits.
Compare the event against historical baselines.
Investigate source distribution, packet rates, destination ports, timing, and any changes in legitimate client demand.
Do not assume that many source IPs indicate a distributed attack or that one source address identifies the responsible attacker.
Correlate network observations with availability checks, application logs, load-balancer metrics, and user reports.
Determine whether the issue is caused by pending TCP connections, network-link saturation, intermediary-device exhaustion, or another failure.
Coordinate with network engineering, hosting providers, or the upstream ISP as appropriate.
Apply mitigations at the layer where the bottleneck exists. Preserve relevant telemetry and timestamps so that the attack's duration, impact, and response can be reconstructed.
No single mitigation is suitable for every SYN flood. Effective response depends on whether the bottleneck is the server, an intermediary device, or the network link itself.
SYN cookies allow a server to reduce the need to retain conventional pending-connection state before the client completes the handshake.
Instead of relying solely on stored state for each incoming request, the server encodes relevant connection information into its SYN-ACK sequence number. When the final ACK arrives, the server can validate it and reconstruct the necessary state.
This can reduce pressure on pending connection queues.
SYN cookies do not prevent every form of denial of service. They cannot, by themselves, solve upstream bandwidth saturation or all resource-exhaustion attacks.
Appropriate backlog sizes and connection-establishment timeouts can improve resilience.
However, increasing queue sizes without addressing the underlying traffic can merely postpone resource exhaustion or increase resource consumption. Changes should be based on the operating system, workload, and measured bottleneck.
Firewalls and network devices may apply rate limits or filtering to suspicious traffic.
Care is required because overly aggressive limits can block legitimate users, particularly during traffic surges or when many clients share an address.
Some load balancers and security devices can handle initial TCP handshakes on behalf of backend servers. This can reduce the burden on application servers by delaying the creation of backend connections until a client has demonstrated that it can complete a handshake.
Such mechanisms introduce their own capacity requirements and should be configured and monitored accordingly.
When an attack saturates the internet connection or exceeds the local network's capacity, mitigation may need to occur upstream.
DDoS protection services, ISP filtering, and specialised traffic-scrubbing infrastructure can help absorb or filter traffic before it reaches the target network.
Treating every incomplete handshake as an attack. Normal network loss, scanning, client failures, and asymmetric routing can produce incomplete connections.
Focusing only on source IP addresses. Source addresses may be spoofed, distributed, or associated with legitimate shared infrastructure.
Ignoring upstream devices. A firewall or load balancer may be the component experiencing state exhaustion.
Increasing backlog limits without investigating the bottleneck. This can delay failure without resolving the cause.
Assuming SYN cookies solve every SYN flood. They primarily help with connection-state pressure and do not eliminate bandwidth saturation or all other resource constraints.
Failing to establish service impact. High packet rates alone do not demonstrate that the target service is unavailable.
A TCP SYN flood is a network denial-of-service technique. Its relevance to MITRE ATT&CK depends on the context and observed behaviour.
TechniqueIDRelevanceNetwork Denial of ServiceT1498Relevant when an attack overwhelms network resources or availability through network trafficDirect Network FloodT1498.001Relevant when the attack directly floods the target with network trafficEndpoint Denial of ServiceT1499May apply if the incident specifically exhausts endpoint resources, depending on the observed behaviourATT&CK mapping should reflect the actual attack and its impact. A SYN flood should not automatically be classified as endpoint resource exhaustion if the primary bottleneck is an upstream network link or intermediary device.
TCP SYN floods exploit the resources required to establish and track TCP connections. By generating connection attempts that do not complete, an attacker may overwhelm pending-connection queues or other state-management resources, disrupting legitimate access to a service.
Effective investigation requires correlating packet-level handshake behaviour with server metrics, firewall and load-balancer state, network capacity, and application availability. Mitigation may involve SYN cookies, carefully tuned connection handling, filtering, SYN proxies, or upstream DDoS protection.
For SOC analysts, the key is to identify exactly where connection establishment is failing and why. That distinction determines whether the correct response is a server configuration change, a network-device adjustment, or coordinated upstream mitigation.
The key lesson: A SYN flood is not simply a large volume of traffic. It is an attack on the resources and state required to turn connection requests into usable TCP sessions.
Continue reading
DDoS Attacks
HTTP flood attacks are application-layer Distributed Denial-of-Service (DDoS) attacks that overwhelm web servers, APIs, or backend services with excessive HTTP requests. Unlike vol...
DDoS Attacks
DNS amplification is a reflection-based DDoS technique in which attackers send DNS queries with a spoofed victim IP address, causing DNS resolvers to send responses to the victim....
DDoS Attacks
Distributed Denial-of-Service (DDoS) attacks can overwhelm network bandwidth, exhaust connection-handling resources, or disrupt application availability. Firewall logs reveal permi...
3 entries, most recent posts.
Cybersecurity researchers have uncovered an AI-assisted cybercrime operation attributed to CyberXero, a financially motivated initial access broker th...
Senior Hosting Security Engineer
The convergence of Operational Technology (OT), the Internet of Things (IoT), and traditional enterprise IT networks is transforming how organisations...
