When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
A level of acceptable risk is evident when any business launches a website and puts it on the internet, opening its doors for all visitors. What some businesses may not realize is that some risks are insurmountable, even for massive corporations and government agencies. During the mid- to late ’90s one type of attack’s destructive side effects were considered all but insoluble – and it continues to be a problem to this day.
It’s known as a SYN flood attack. With a staggering 65,535 TCP ports being made available on a single IP address, all of which could leave any software listening behind those ports vulnerable, it’s easy to see why there are so many security exploits on the internet. SYN floods rely on the fact that web servers will respond to apparently legitimate requests for web pages, no matter how many requests are made. However, should an attacker make lots of requests, which then leave the web server tied up and unable to continue serving truly legitimate requests, disaster will strike and the web server will fail. On a basic level, this is how SYN floods work. Here we’ll take a look at some of the most common types of SYN attacks and what network and system administrators can do to mitigate them.
TCP Protocol Basics: How a SYN Flood Works
Thanks to the apparent lack of any obvious mitigation techniques, SYN attacks were quite rightly feared by online businesses when they were first identified in the wild.
Landing firmly under the denial of service variety of attacks, what made SYN floods most frustrating to systems and network administrators was that, ostensibly at least, the attack traffic presented itself as legitimate traffic.
To appreciate the simplicity – some might say beauty – of this flavor of attack, we need to briefly look a little closer at the protocol responsible for a significant part of the internet’s traffic, Transmission Control Protocol (TCP).
The aim of such an attack is to readily soak up all of a web server’s available resources by convincing the server it’s serving data to legitimate visitors. As a result, service is denied to the server’s legitimate users.
TCP connections, which are used to send email, view websites and send tweets, among millions of other online functions, are initiated with what’s called a three-way handshake. The premise for the handshake is simple and once both sides are connected, this sophisticated protocol allows for functionality such as rate-limiting how much data a server will send to a recipient based on how much bandwidth the recipient has available.
Beginning with a SYN packet (which stands for synchronize) sent from the visitor or client, the server then responds efficiently with a SYN-ACK packet (or synchronize-acknowledge), which is then confirmed by the visitor, which sends an ACK packet of its own in response. At that point, a connection has been established and traffic can flow freely.
A SYN flood attack circumvents this smooth exchange by not sending the ACK to the server after its initial SYN-ACK has been sent. Either that packet is completely omitted or the response might contain misleading information such as a spoofed IP address, thus forcing the server to try and then connect to another machine entirely. This is simple but deadly for any host that respects TCP.
Slowloris
One variant of this method of attack, which made the headlines a few years back, was called Slowloris. The Slowloris site describes itself as “the low bandwidth, yet greedy and poisonous HTTP client!” The site certainly makes for worrying reading and describes how a single machine may “take down another machine’s web server with minimal bandwidth and side effects on unrelated services and ports.”
It goes on to explain that such an attack is not actually a TCP denial of service attack. This is apparently because a full TCP connection is created but, rather importantly, only a partial HTTP request is made to pull down a web page from the server. One side effect is that the web server can return to its normal operating state very quickly relative to other attacks.
Along the same sinister vein of the attack’s design, this feature might allow an attacker to deploy some other short-lived attack in a short space of time as the server struggles with a SYN flood and then returns the server to as it was before, without being noticed.
Response Tactics Against SYN Flood Attacks
With some high-profile sites being targeted, it became clear that a mitigation technique was needed and promptly. The problem is that making a server completely impenetrable to such attacks is difficult. Consider, for example, that even what’s known as tearing down connections consumes server resources and can cause other headaches.
Linux and FreeBSD developers responded with a kernel addition called SYN cookies, which has been part of the stock kernel for a long time. (Although, surprisingly, not all kernels enable them by default.) SYN cookies work with what are known as TCP sequence numbers. They have a way of using preferred sequence numbers when a connection is initially established and also mitigate floods by dropping SYN packets sitting in their queue. This means they can handle many more connections if they have to. As a result, the queue should never become overwhelmed – at least in theory.
Some opponents speak openly against SYN cookies because of the changes they make to TCP connections. As a result, TCP cookie transactions (TCPCT) have been introduced to overcome any of SYN cookies’ shortcomings.
Remain Vigilant, Protect Against Attacks
With the ever-increasing number of attack vectors being discovered and then exploited on the internet, it’s important to remain vigilant at all times. Certain types of attacks force both those with good intentions and those with malicious intent to explore new methods to protect and attack systems. One thing for certain is that the lessons learned from simple yet sophisticated attacks, such as SYN floods, keep security researchers even more attuned to how protocols and firewalling software should evolve in the future. We can only hope it is of benefit to the internet at large.
