Don’t Get Swept Away: The Most Common DDoS Attacks are SYN and UDP Floods
The calm week of Adrian Newby, CTO, was about to change. His company provides internet-based software-as-a-service to its clients. One of those clients was now in trouble. Their servers have started acting up. They were receiving huge amounts of internet traffic they just could not cope with. The symptoms were there. Newby knew that this were the beginning of a DDoS attack. A synchronized distributed effort trying to deny clients access to their services. How did he face the challenge?
- 15. 02. 2016
- 11 min read
He immediately started to fight the attackers. The whole bout took over 39 hours. The defenders got off relatively lightly – their expenses were only about 1500 US dollars.
Newby and his team fought hard and averted the disaster. They were mightily helped by their cloud’s elasticity – by repeatedly scaling the cloud up they eventually outgunned the attackers.
The affair could have ended much more nefariously though. If Newby’s servers were hit by a different type of DDoS attack, not even the cloud and its scaling abilities could save them. There are many varieties of DDoS attacks and they all need a different defensive strategy.
Attackers use some of those varieties more often than the others. Which are their weapons of choice and how do we protect our servers against them? Read on.
How does DDoS attack work? Like lots of phone calls at once
Most people in IT know how DDoS attacks generally work. For those who don’t: imagine a thousand people trying to reach you on your cell phone at the same time. They don’t need anything important, they’re just sitting on the line so that no one else can reach you. People outside the group of attackers can’t get you on the phone for dear life. The comparison is in many ways inaccurate but it’s enough to get an idea.
The actual way DDoS work is much more complicated. First, there is not just one type of attack. There are many different varieties that differ a lot.
Experts separate DDoS varieties into several general categories, usually by the denial method. For example, Radware details DDoS attacks targeting network resources, those targeting server resources or attacks through the SSL layer.
Terminology differs from expert to expert
Other professionals seem to favour different categories. Imperva’s experts, for example, talk about protocol attacks, application layer attacks and volume based attacks. This distinction is a bit unfortunate, as protocols and their specifics are used even in methods that Imperva classifies as volume based or application layer attacks. On the other hand, Cisco differentiates between volumetric, application and low-rate attacks. The terminology differs slightly from one expert to another, but seeing as these categories are simplifying and abstract by nature, they’re only used to provide a very basic idea anyway.
As the names of the categories suggest, some methods try to gobble up server’s resources, other use weaknesses in applications or security. Worthy of note are the attacks targeting network resources. Those are trying to “clog the pipes” by depleting the connectivity of a particular server. That makes it inaccessible to regular users.
Threats are mounting: DDoS attacks happen more often
As I wrote in one of the posts on this blog, lately there have been more and more DDoS attacks. And most of those attacks actually consisted of more than one type of DDoS. According to an investigation, the evildoers most often choose two vectors of attack – a SYN flood and UDP flood.
DDoS attack types in the second quarter of 2015
The most common types of attack according to Global DDoS Threat Landscape by Imperva were UDP and SYN floods. The total doesn’t add up to 100 %, because most attacks use more than one vector at once.
How do they work?
The most common method: UDP packets flood the server
The most common DDoS method by far is the UDP flood – the acronym UDP meaning User Datagram Protocol. Normally, it forms a part of the internet communication similar to the more commonly known TCP. It differs from TCP in that UDP doesn’t check the establishing, progress or time-out of the communication – what is known as handshaking. It allows UDP to be much faster but also opens it to malicious abuse.
A UDP flood, for example.
It works on a quite basic principle. The attackers send a big bunch of UDP packets to random ports of their target server. The server has to respond to all of them, those are the rules. First, it needs to check if any of its applications are listening for communication at these ports. When it finds none, the server needs to send back an information about the destination being unavailable. It does so through the internet protocol called ICMP which is used for sending out error messages.
Every packet sent to the targeted server needs to be replied to. This eats through server’s connectivity and sometimes other resources. This huge amount of traffic – that is in part generated by the server itself – makes a regular connection to the server impossible.
This type of attack could be classified as an attack targeting network resources or as a volume based one. Its popularity might be in part caused by how difficult it can be to defend against. Server owners can’t do much more than limit the number of ICMP packets processed at one time. However, this doesn’t help the communication coming to the server as those pipes have already been clogged by the incoming UDP packets.
The only ones with power to do anything against UDP flood are internet providers, who can for example filter UDP packets and re-route them to so-called black hole servers. Those are destinations that receive the offending packets but don’t send out any sort of confirmation to the attacker.
Its popularity might also stem from the relative ease of UDP flood deployment. There are several apps available that make attacking anyone this way frightfully simple. One such is the Low-Orbit Ion Cannon that simplifies the process of UDP flood attack to few mouse-clicks.
SYN floods: Servers wait for answer, but none is coming
The second most common type of attack is a flood of SYN packets. It abuses one characteristic of the TCP. Where the faster but less secure UDP doesn’t check the start, progress or termination of communication, it’s relatively slower but more reliable big brother TCP does. And it does so through a series of signals that both sides of the communication must send to each other, before their connection is officially established.
Let’s look at the process in detail. (Or skip to the blue box if you’re in a rush.)
The first participant of the communication sends a SYN packet to its target server. The acronym means synchronize and tells the target server that a connection is desired.
A second part of the communication occurs when the target server responds with another message, this time with a SYN-ACK (synchronization acknowledged) packet. This tells the first participant that the server received the SYN packet and is ready to start the communication.
The third and last step of the process happens when the first participant receives the SYN-ACK response from the server. It’s supposed to send one more ACK packet back, to acknowledge the servers’ SYN-ACK. The handshake is now complete and the TCP connection has been successfully established.
The SYN-ACK handshake for dummies
Too long, didn’t read? It basically boils down to:
A: Hi, B, listen, I’ve got something to tell you. (SYN)
B: What? Go on, I’m listening. (SYN-ACK)
A: Okay. Now… (ACK)
Because the process consists of three phases (first SYN, then SYN-ACK, and then ACK), it’s usually called the three-way handshake.
When a SYN flood occurs, this process gets derailed. And right when it’s about to conclude.
The target server receives SYN and responds with SYN-ACK (so far so good), but then is left hanging. The desired ACK message coming from the first participant of the communication is not coming. The server is not sure what’s going on with this communication and keeps waiting for the last packet. It could have been just delayed on its way through the network, after all.
However, this means the server needs to leave this connection half open, and assign some of its resources to watch for that lost ACK packet.
And that packet never comes, because the attacker engineered it so. Instead the server receives other SYN requests that he again tries to respond to but gets no ACK message back. When it’s flooded with these requests, it can deplete all its resources, behave incorrectly or outright crash.
There are many ways to fool a server
The poor server from our example can be left hanging, forever waiting for the ACK message. This can be due to two reasons. Either the attacker has set up his resources not to send out ACK message at all. Or he might have “forged the credentials” that arrived with to the server with his first SYN packet. For example, he might have claimed to come from a different IP address – this is called IP spoofing. The server is oblivious to the trick, so tries to communicate with the real owner of the spoofed IP address. As this computer is oblivious to the whole communication and receives SYN-ACK message seemingly out of the blue, it doesn’t send back the acknowledgment and leaves the server hanging.
Build a dam out of cookies
Fortunately, server owners can defend against SYN floods. Their servers can be configured to add a value to the start of packets used in TCP communication – these values are called SYN cookies.
This allows the server to essentially forget about the communication until it receives the final ACK packet. It doesn’t need to “hold the line half open” and deplete its resources. Instead it rebuilds all the information needed from the value of the SYN cookie in the packet.
It’s somewhat similar to answering your phone only when people in your contact list call and ignoring all the other calls.
This method has been first discussed back in 1996. Its formulation has been attributed to a cryptologist Daniel J. Bernstein.
However, the attackers have been lately trying out new techniques that outsmart even this clever system of cookies. The experts from Radware have witnessed a new form of attack they consequently dubbed the Tsunami SYN flood. Similarly to a real-world tsunami, the SYN flood is huge.
The evildoers behind tsunami SYN flood engineered SYN packets to grow in size from their usual length of 40 to 60 bytes up to a thousand bytes. Packets of this size are – according to the protocols – still acceptable, but according to Radware they complicate or confound many defensive algorithms. Including SYN cookies.
But tsunami SYN floods were huge in another aspect as well. The amount of SYN requests incoming to the target server was enormous. Volume based attacks usually use the UDP protocol mentioned above. But when the attackers use SYN floods in a similar fashion, they can’t be defended against through the same mechanisms one would employ against UDP floods.
Flood attacks are a huge threat. Be ready for them
Both types of DDoS attacks – whether UDP or SYN – spell trouble for the servers they target.
However, it all comes down to their strength. Some attacks can be defended against with a little effort, others can bring a server down no matter what. The strongest recently reported attack reached 253 gigabits per second. To give you an idea – Newby’s team had their hands full dealing with an attack that was thirteen times lower in intensity.
Reflected attacks can make normal servers their accomplices
The so-called reflected DDoS attacks can bring down even well-provisioned servers that would have no trouble dealing with other threat. These attacks don’t use just their own botnet, but other normal servers as well. By sending forged information to these third-party servers, they can force them to add their packets to the huge amount reaching the victim. This makes the attack up to several times stronger and confounds the defensive efforts even more.
For admins, all this means that they need to focus on prevention. Only with preparation, testing and searching for weaknesses can admins fight these strong threats.
What about your experiences? Have you ever stood toe to toe with a DDoS attack? Which methods did you have to defend against? And did you pass? Let us know in the comments below.
