Nikhil Taneja Managing Director-India, SAARC & Middle East
The nature of DDoS attacks is changing. Not too long ago, large-scale network-layer floods were attackers’ tools of choice, using malformed TCP and UDP packets to take down targets with high volumes of network traffic. Over time, however, defense have adapted to protect against such volumetric attacks, to the point where even most ISPs and public cloud vendors are able to provide basic protection against network-layer floods.
Attackers, however, are not sitting idle; they are constantly devising new ways to challenge DDoS protections. As more and more services are migrating online, DDoS attacks are increasingly shifting away from the network layer, and into the application layer.
L7 DDoS Poses A Unique Challenge
Application-layer (L7) DDoS attacks pose a unique challenge for DDoS defense, as they require insight into application behavior, and it is difficult to tell whether a request is legitimate or malicious by looking just at the network-layer traffic.
Moreover, as more and more web traffic is encrypted by SSL and HTTPS, DDoS defense are frequently unable to look at the contents of the packet itself. As a result, many types of DDoS defense are unable to tell the difference between a legitimate spike in customer traffic (for example, during a flash crowd or a holiday peak) and an actual attack.
Here are seven types of application-layer (L7) DDoS attacks to watch out for:
•HTTP/S Flood
HTTP floods work by directing large amounts of HTTP requests at a web page in order to overload target servers with requests. In this regard, this type of attack is similar to other types of network-level flooding attacks, except that this one operates at the application layer, using high volumes of HTTP/S GET or HTTP/S POST requests.
However, as the vast majority of internet traffic nowadays is encrypted, most HTTP flood attacks today are, in fact, HTTPS floods. Not only are encrypted floods much more potent because of the high amount of server resources required to handle them (see below), but they also add a layer of complexity to mitigating such attacks, since DDoS defense usually cannot inspect the contents of the HTTPS requests without fully decrypting all traffic.
•SSL Negotiation Attack (a.k.a. “SSL Garbage Flood”)
An SSL negotiation attack targets specifically the SSL handshake mechanism of web applications in order to overload server resources. The SSL/TLS handshake mechanism is a highly asymmetric process, which requires as many as 15 times more computing resources from the incoming server than from the client making the request. This means that attackers can launch devastating DDoS attacks using only a small number of requests.
SSL negotiation attacks work by sending large numbers of “garbage” SSL/TLS connection initiation requests in order to overwhelm the server’s resources and ability to accept new connections. Although the HTTPS floods mentioned above are one type of attack which takes advantage of this mechanism, there are also other variations such as encrypted SYN floods or SSL re-negotiation attacks (which continuously create, drop, then re-create SSL handshakes).
•Low-and-Slow Attack
Like flood attacks, low-and-slow attacks aim to take down target servers by overwhelming server resources. However, unlike flood attacks, low-and-slow attacks do so not by sending high volumes bursts of traffic, but rather by taking the opposite approach of sending a small number of connections, but keeping them open as long as possible until they exhaust the target server’s resources.
Using this approach allows low-and-slow attacks to ‘fly under the radar’ of traditional DDoS defense based on volume thresholds, since they do not cause large spike in traffic which can be ‘capped off’ by rate limits.
There are numerous variations of this approach, usually named after the hacking tools which use them. One common attack variation is Slowloris, which keeps HTTP requests open by continually sending partial HTTP headers, but never completing the request. Another well-known variation is R.U.D.Y. (“R U Dead Yet?”) which creates HTTP POST connections with the server, but avoids sending any POST data for as long as possible (and then sending the data in a very slow rate), thereby drawing-out the connection and limiting the server’s ability to accept new connections.
•HTTP/S Bomb (a.k.a. “Large Payload Attack”)
An ‘HTTP bomb’ uses the HTTP POST method to send large, complex POST requests (usually scripted as an XML data structure), which the target server will then attempt to parse. However, due to the size and complexity of the POST request (i.e., the “bomb”), the server will end up using high amounts of computing resources, ultimately depleting them and bringing the server down.
This can be a particularly difficult attack to mitigate, since it can use high number of server resources with a limited number of connections.
•Large File Download (a.k.a. “Outbound Pipe Saturation Attack”)
Unlike most DDoS attacks, this attack vector does not target the server’s incoming traffic pipe, but rather aims at saturating the outbound traffic connection.
Many web-based services allow downloads of large files such as software updates, OS images, databases, application data, etc. Even modern web pages can be very large in size, if they include heavy graphics and other objects. Large file download attacks aim at exhausting the server’s ability to communicate externally by saturating the outbound connection with large amounts of outbound data.
This can be a very effective type of asymmetric attack, since the request can be only a few bytes, whereas the reply can be gigabytes in size. Moreover, outbound pipe saturation attacks can be very difficult to detect and mitigate since most DDoS defense look only at incoming traffic, not outgoing traffic.
•Application Bruteforce Attack
Although not specifically designated as such, many types of web application attacks also bear the hallmarks of a DDoS flood. This is because like DDoS floods, application bruteforce attacks frequently come in at a high rate and generate high-volumes of application-layer error messages, which need to be processed and handled by the server.
Examples of such bruteforce attempts include server scanning, password cracking, credential stuffing, and more. The challenge with dealing with such types of bruteforce attacks is that without processing the request first, it is usually very difficult to know which request is legitimate and which is not.
•Denial of Inventory
This type of application-layer attack is not a DDoS attack per se, but it achieves the same objectives by denying the organization’s ability to serve its customers. Denial of inventory attacks use automated bots to go into organizations’ applications and initiate purchase requests, without actually completing the purchase. As a result, the inventory relating to the purchase request – such as airline tickets, event tickets, stock inventory, etc. – is temporarily locked, and unavailable to actual customers who would like to purchase the same inventory.
Although this type of attack does not target the traffic pipe or server resources themselves, it achieves the same result of denying service from legitimate customers. Again, this is a particularly difficult form of attack to mitigate, since it is difficult to discern an actual paying customer from a bot.
Watch out for these Seven L7 DDoS attacks
