Types of DDoS attacks
Each year their frequency becomes higher and higher. That’s why we decided to write this article explaining many of the DDoS attacks which you surely might never encounter, but still, need to know that they do exist. Let’s start!
Zero Day DDoS
The acronym for it was invented when describing the new DDoS attacks that exploit certain vulnerabilities people never heard of before. Usually, they might be fixed with certain patches here and there.
UDP types
DNS Flood
Oh, that one is probably the most notorious and popular DDoS attack you might’ve encountered on the net. It is a UDP flood attack that targets the DNS servers. The fact that it is so frequently used is that it is hard to detect, not to mention prevent. How is it being executed? The hacker sends a vast amount of spoofed DNS requests that are hard to distinguish from the real ones. Now multiply it by thousands of IPs and here you have it.
Your server cannot understand which ones are legitimate and which are not thus resulting in a server running out of resources to process those requests and crashing.
UDP Flood
Self-explanatory. It targets a server by using UDP packets (duh). While the DNS flood is exhausting the hardware, the UDP flood is exhausting the bandwidth. UDP traffic is very convenient for attackers because it doesn’t need to be checked by the server and client like TCP one. Basically, a large number of spoofed or masked UPD packets is constantly being sent to the server. The reason why they are masked is to make sure that the return ICMP packets don’t reach their host, and to anonymize the attack.
Direct UDP Flood
Direct UDP Flood has a different approach. When usual UDP flood is usually spoofed the direct one is not. It has certain advantages for attackers because the traffic running through the botnet might be marked as legitimate which complicates its detection by the affected party. As with UDP flood, the main target is to drain the resources of the server dry.
UDP Fragmentation Flood
Quite interesting variation of the UDP flood is a fragmented version of it. Similar to direct UDP flood it mimics the work of legitimate traffic which is being kept within limits. So it is very hard to detect it because the packets are quite large but fragmented at the same time. It exhausts the bandwidth even more. Imagine that you have different parts to the three types of puzzles and you receive different parts for each, but you cannot understand which piece is from what puzzle. Now multiply it by thousand puzzles, and you will understand how your server feels when being under attack by UDP Fragmentation Flood. Nasty thing.
VoIP Flood
We’ve decided to put it under UDP because it uses UDP packets to flood VoIP servers. Spoofed requests which are usually sent from a huge pool of IPs overload the server severely. The problem with VoIP is that it is very hard to understand what kind of traffic is real and what is not. It takes serious damage to server performance thus resulting either in poor performance or server reboot.
ICMP Flood and its types
ICMP Flood
ICMP utilizes the same method as UDP does. It doesn’t have end to end process for data exchange, which makes it a potential alternative to UDP Flood. Similar to UDP attacker sends a large amount of ICMP packets from numerous bots with different IPs. This results in the system being unable to process all those requests which results in a server reboot or significantly cripple its performance.
ICMP Fragmentation Flood
Another variation of the former flood is a fragmented variation of it. Similar to UDP one the attacker just splits ICMP packets into small pieces and overloads the server by sending unrelated parts of different packets without any connection to each other. In the usual case scenario server can handle it but only in a certain amount. If this amount is exceeded the server goes down.
Ping Flood
ICMP flood version 2.0 is called Ping Flood. Same spoofed requests which targets the application. Imagine that you’re pinging any server you like. You ask the server: “What is the latency between us?” and the server responds by doing so from 5 to 10 times usually. But imagine that 100000 people ask the same. If the hardware is resourceful enough it can handle it but if not the server goes down. The traffic from ping flood is very hard to distinguish because it also might be considered legitimate.
Protocol level
NTP Flood
NTP or Network time protocol was originally designed to synchronize the time between clocks and computers. Basically, the computer will ask what time it is right now from the main server and sync it with its own clock by using the packet system. It is yet another form of how the attacker might target your server if it runs the NTP protocol, which basically each server uses. Eventually, these spoofed requests are used to send UDP floods to the target. When server tries to understand what is what he eventually goes down from overflown data.
CharGEN Flood
Oh, that one is an old-timer. We’ll post it just for the sake of history. Back in 1984 this protocol was developed as Character Generator Protocol and was used as a source of a byte stream for debugging TCP network code. Right now it is blocked by default in modern systems, so if you happen to find a certain system that runs it, then congrats! You have found a relic of the past. It was quite popular on internet printers, xerox, and other machines back in the day but right now this security breach was eradicated. Initially, the attacker just targeted port 19 of it and send a UDP flood through it.
SNMP Flood
SNMP or Simple Network Management Protocol is a protocol for managing, collecting, and changing information about the devices located on IP networks. It is another type of flood that can be amplificated, meaning that the attacker can do more harm with fewer resources. It is a more favorable choice because the result of amplification is far bigger than DNS or CharGEN Floods. Basically, the attack targets the devices running this protocol and sends a flood using this protocol.
SSDP Flood
Simple Service Discovery Protocol or SSDP protocol is used for the advertisement and discovery of network services and presence information but without using DHCP or DNS. Usually used in small offices where hardware has an access to UPnP (Universal Plug n’ Play) protocol in 2014 it resulted in a DDoS attack that targeted such devices by sending packets carrying a spoofed IP of the target to devices which resulted in server crashes.
HTTP level
HTTP Flood
The attackers who use HTTP Flood overload the server with GET and POST requests. While GET requests do not take too many resources from the server. It might be the request to show certain pictures or any other static content. POST requests are the other thing, as they usually ask the server to process something from them like finding a specific value in the database or doing some kind of manipulation with information. HTTP Flood does not require IP spoofing thus resulting in lower requirements in order to initiate an attack.
Fragmented HTTP Flood
HTTP Flood is always done with bots with valid IPs, because they were being hijacked by Trojan viruses. So before the attack, they were asleep and didn’t even know that their resources would be used in a DDoS attack. Fragmentation allows the attacker to stretch the attack to the verge of timeout. This allows for prolonging the connection for a considerable amount of time before any defense might be activated. For example, if you use Apache, it doesn’t have any specific timeout mechanisms which can help you, so hackers actively exploit it.
Single Request HTTP Flood
Eventually, programmers and DDoS protection systems understood how to mitigate attack from multiple incoming packets so hackers have decided to find a workaround. This resulted in another loophole which we will explain shortly.
It all comes to packet manipulation. What if you can create several GET/POST requests within one HTTP session? Well, you can but it may be counted as several packets. The attackers have found a way to combine it in one packet. It masks the attacker as a legitimate person so it is very hard to trace him down.
Single Session HTTP Flood
Quite an old method that can be achieved in HTTP 1.1 by sending requests from a single HTTP session. It helps attackers to bypass the limitations imposed by DDoS defense mechanisms on the number of sessions allowed.
Recursive HTTP GET Flood
Quite an interesting attack that utilizes a GET request. The hacker requests a few web pages, and receives information about them. After that, he starts to analyze each object on the page and send recursive requests for each object on the website. Very hard to trace because those requests seem like legitimate ones.
Random Recursive GET Flood
A variation of the previous attack targets mostly blogs, websites that have pages in sequence, or blogs. Similarly to HTTP GET Flood, it sweeps through pages and then starts sending random requests. The thing is, to look like a legitimate user the attacker needs to choose random pages and then choose random numbers from the page to send a new GET request each time. Eventually, this results in poor server performance up to server reboot or crash.
ACK & SYN
ACK & PUSH Flood
First of all, let’s understand what is ACK. ACK is a flag that shows either the server or the client that the data has been received successfully. For example, the client asks if the server has received the form submission and the server gives out an ACK answer telling the client that everything is OK, I’ve got it. Now how does this attack works?
The attacker may send various info to the server and set an ACK flag for the server to say that he has received the information.
PUSH flag is doing the opposite. It asks the server by using packets to process some kind of information for him.
Those kinds of requests are more resource-consuming than previous attacks and have more priority over others due to the fact that they are not a part of any session on the server’s connection list. This results in the server processing those requests first and the on the connection list last thus resulting in a server crash.
ACK Fragmentation Flood
This variation of ACK flood uses a small number of maximum-size packets, approximately around 1500 bytes. The initial objective here is to exhaust the network bandwidth of the target. This flood is quite cunning as it may easily pass through your network equipment such as a router or firewall if no application-level filters were applied because they can look legitimate to them. Those packets usually contain rubbish data, because there is no reason for the attacker to input there any information, as his objective is to simply exhaust the bandwidth.
SYN Flood
SYN is a name for a connection request via TCP. When a client tries to connect to a server using TCP (for example, when establishing an HTTP or HTTPS connection), it must immediately go through a three-way handshake before data exchange between the client and the server is possible. Since the initiator of the TCP three-way handshake is always the client, he first sends a packet with the SYN flag to the server.
In a TCP SYN Flood attack, attackers intensively send a large number of SYN packets with spoofed IP addresses to the server. This forces the server to react by sending a SYN-ACK packet in response to each such false request, allocating some resources and leaving its ports "half-open", waiting for numerous responses (packets with the flag set to ACK) from hosts that do not actually exist, and they will not send confirmations, respectively.
SYN-ACK Flood
We have talked about the three-way handshake. This type of attack targets the host. When the attacker sends SYN packet, a relevant ACK packet is generated by the host. The server cannot understand why is he receiving such packets out of order from the legitimate traffic and trying to understand and process them, all of this eventually leads to a server being too busy to handle the traffic it should resulting in a server reboot or a crash.
RST/FIN Flood
We have talked about SYN-type floods and how they work. After each TCP-SYN session closed there should be an interchange of the RST or FIN packets. When RST or FIN Flood starts the server starts receiving spoofed and fake packets which are not connected to any type of session the server currently has. Similar to SYN-ACK flood the server cannot understand where they come from and spends a lot of time processing them and eventually failing to do so.
IP Level
Fake Session Attack
This type of attack does not use spoofed IPs, but rather uses the real IP addresses of the bots performing the attack. The TCP-SYN session is created between the server and the bot. The attack is done in such a way that it becomes timed out thanks to delaying the ACK packets. Empty sessions start to exhaust the server and it goes eventually down or works rather poorly.
IP Null Attack
Each header in IPv4 according to RFC terms should contain information about the transport protocol being used. The null attack comes from the “zero” attackers put in this field. This means that these packets will bypass the routers or firewalls because they are undefined or uncategorized. Today this value is reserved for IPv6 Hop-by-Hop Option but that doesn’t mean that every server today can really process this type of packet. Now multiply it by thousands and the server goes down.
Application Level Attacks
Application Level Attacks are such kinds of attacks that target certain vulnerabilities. One of the most popular targets is the servers running different CMS like WordPress, Drupal, or Joomla. Of course, those companies always close security breaches, but hackers tend to find certain vulnerabilities from time to time. The other option is to target the victim’s databases with SQL injections. Eventually, the server cannot handle fake requests and goes down. Make sure that you are running the latest versions of CMS and that your data base is being administered by professionals.
Application Misuse attack
This kind of attack cannot be executed on every business. The victim must host something that generates a lot of traffic and has another server where all of this traffic might go to. It resembles the few river courses which you manually redirect to the victim’s target server in order to crash the server. The method of crashing the server remains the same - overloading it with excessive traffic. The main problem with it is that the traffic is indeed legitimate because the servers are trying to establish a legit connection.
Conclusion
We’ve tried to cover the majority of the DDoS attacks you might encounter, there are certainly a few ones we might miss, but we think you’ve got a general understanding of what kind of DDoS attacks there are. If you wish to protect your server from such attacks feel free to ask our team via LiveChat about the servers with DDoS protection. Thank you for your time!