{
	"id": "39576015-1d8a-4818-882b-9b548f085b28",
	"created_at": "2026-04-06T00:21:12.727078Z",
	"updated_at": "2026-04-10T03:20:37.037195Z",
	"deleted_at": null,
	"sha1_hash": "d2017a3a0fdf17f8b52579273cdd75bb4e26cd3d",
	"title": "SYN flood DDoS attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 344468,
	"plain_text": "SYN flood DDoS attack\r\nArchived: 2026-04-05 23:19:16 UTC\r\nWhat is a SYN flood attack?\r\nA SYN flood (half-open attack) is a type of denial-of-service (DDoS) attack which aims to make a server\r\nunavailable to legitimate traffic by consuming all available server resources. By repeatedly sending initial\r\nconnection request (SYN) packets, the attacker is able to overwhelm all available ports on a targeted server\r\nmachine, causing the targeted device to respond to legitimate traffic sluggishly or not at all.\r\nHow does a SYN flood attack work?\r\nSYN flood attacks work by exploiting the handshake process of a TCP connection. Under normal conditions, TCP\r\nconnection exhibits three distinct processes in order to make a connection.\r\n1. First, the client sends a SYN packet to the server in order to initiate the connection.\r\n2. The server then responds to that initial packet with a SYN/ACK packet, in order to acknowledge the\r\ncommunication.\r\n3. Finally, the client returns an ACK packet to acknowledge the receipt of the packet from the server. After\r\ncompleting this sequence of packet sending and receiving, the TCP connection is open and able to send and\r\nreceive data.\r\nhttps://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/\r\nPage 1 of 5\n\nTo create denial-of-service, an attacker exploits the fact that after an initial SYN packet has been received, the\r\nserver will respond back with one or more SYN/ACK packets and wait for the final step in the handshake. Here’s\r\nhow it works:\r\n1. The attacker sends a high volume of SYN packets to the targeted server, often with spoofed IP addresses.\r\n2. The server then responds to each one of the connection requests and leaves an open port ready to receive\r\nthe response.\r\n3. While the server waits for the final ACK packet, which never arrives, the attacker continues to send more\r\nSYN packets. The arrival of each new SYN packet causes the server to temporarily maintain a new open\r\nport connection for a certain length of time, and once all the available ports have been utilized the server is\r\nunable to function normally.\r\nhttps://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/\r\nPage 2 of 5\n\nIn networking, when a server is leaving a connection open but the machine on the other side of the connection is\r\nnot, the connection is considered half-open. In this type of DDoS attack, the targeted server is continuously\r\nleaving open connections and waiting for each connection to timeout before the ports become available again. The\r\nresult is that this type of attack can be considered a “half-open attack”.\r\nA SYN flood can occur in three different ways:\r\n1. Direct attack: A SYN flood where the IP address is not spoofed is known as a direct attack. In this attack,\r\nthe attacker does not mask their IP address at all. As a result of the attacker using a single source device\r\nwith a real IP address to create the attack, the attacker is highly vulnerable to discovery and mitigation. In\r\norder to create the half-open state on the targeted machine, the hacker prevents their machine from\r\nresponding to the server’s SYN-ACK packets. This is often achieved by firewall rules that stop outgoing\r\npackets other than SYN packets or by filtering out any incoming SYN-ACK packets before they reach the\r\nmalicious user's machine. In practice this method is used rarely (if ever), as mitigation is fairly\r\nstraightforward – just block the IP address of each malicious system. If the attacker is using a botnet such\r\nas the Mirai botnet they won’t care about masking the IP of the infected device.\r\n2. Spoofed Attack: A malicious user can also spoof the IP address on each SYN packet they send in order to\r\ninhibit mitigation efforts and make their identity more difficult to discover. While the packets may be\r\nspoofed, those packets can potentially be traced back to their source. It’s difficult to do this sort of\r\ndetective work but it’s not impossible, especially if Internet service providers (ISPs) are willing to help.\r\n3. Distributed attack (DDoS): If an attack is created using a botnet the likelihood of tracking the attack back\r\nto its source is low. For an added level of obfuscation, an attacker may have each distributed device also\r\nhttps://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/\r\nPage 3 of 5\n\nspoof the IP addresses from which it sends packets. If the attacker is using a botnet such as the Mirai\r\nbotnet, they generally won’t care about masking the IP of the infected device.\r\nBy using a SYN flood attack, a bad actor can attempt to create denial-of-service in a target device or service with\r\nsubstantially less traffic than other DDoS attacks. Instead of volumetric attacks, which aim to saturate the network\r\ninfrastructure surrounding the target, SYN attacks only need to be larger than the available backlog in the target’s\r\noperating system. If the attacker is able to determine the size of the backlog and how long each connection will be\r\nleft open before timing out, the attacker can target the exact parameters needed to disable the system, thereby\r\nreducing the total traffic to the minimum necessary amount to create denial-of-service.\r\nHow is a SYN flood attack mitigated?\r\nSYN flood vulnerability has been known for a long time and a number of mitigation pathways have been utilized.\r\nA few approaches include:\r\nIncreasing Backlog queue\r\nEach operating system on a targeted device has a certain number of half-open connections that it will allow. One\r\nresponse to high volumes of SYN packets is to increase the maximum number of possible half-open connections\r\nthe operating system will allow. In order to successfully increase the maximum backlog, the system must reserve\r\nadditional memory resources to deal with all the new requests. If the system does not have enough memory to be\r\nable to handle the increased backlog queue size, system performance will be negatively impacted, but that still\r\nmay be better than denial-of-service.\r\nRecycling the Oldest Half-Open TCP connection\r\nAnother mitigation strategy involves overwriting the oldest half-open connection once the backlog has been filled.\r\nThis strategy requires that the legitimate connections can be fully established in less time than the backlog can be\r\nfilled with malicious SYN packets. This particular defense fails when the attack volume is increased, or if the\r\nbacklog size is too small to be practical.\r\nSYN cookies\r\nThis strategy involves the creation of a cookie by the server. In order to avoid the risk of dropping connections\r\nwhen the backlog has been filled, the server responds to each connection request with a SYN-ACK packet but\r\nthen drops the SYN request from the backlog, removing the request from memory and leaving the port open and\r\nready to make a new connection. If the connection is a legitimate request, and a final ACK packet is sent from the\r\nclient machine back to the server, the server will then reconstruct (with some limitations) the SYN backlog queue\r\nentry. While this mitigation effort does lose some information about the TCP connection, it is better than allowing\r\ndenial-of-service to occur to legitimate users as a result of an attack.\r\nHow does Cloudflare mitigate SYN Flood attacks?\r\nhttps://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/\r\nPage 4 of 5\n\nCloudflare mitigates this type of attack in part by standing between the targeted server and the SYN flood. When\r\nthe initial SYN request is made, Cloudflare handles the handshake process in the cloud, withholding the\r\nconnection with the targeted server until the TCP handshake is complete. This strategy takes the resource cost of\r\nmaintaining the connections with the bogus SYN packets off the targeted server and places it on Cloudflare’s\r\nAnycast network. Learn more about how Cloudflare's DDoS Protection works.\r\nSource: https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/\r\nhttps://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.cloudflare.com/learning/ddos/syn-flood-ddos-attack/"
	],
	"report_names": [
		"syn-flood-ddos-attack"
	],
	"threat_actors": [],
	"ts_created_at": 1775434872,
	"ts_updated_at": 1775791237,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d2017a3a0fdf17f8b52579273cdd75bb4e26cd3d.pdf",
		"text": "https://archive.orkl.eu/d2017a3a0fdf17f8b52579273cdd75bb4e26cd3d.txt",
		"img": "https://archive.orkl.eu/d2017a3a0fdf17f8b52579273cdd75bb4e26cd3d.jpg"
	}
}