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, defences have adapted to protect against such volumetric attacks, to the point where even most ISPs and public cloud vendors provide basic protection against network-layer floods.

But instead of sitting idle, attackers are constantly devising new ways to challenge DDoS protections. As more services are migrating online, DDoS attacks are increasingly shifting away from the network layer, and into the application layer.

Application-layer (L7) DDoS attacks pose a unique challenge for DDoS defences, as they require insight into application behaviour, and it is difficult to tell whether a request is legitimate or malicious simply by looking at the network-layer traffic.

As more web traffic is encrypted by SSL and HTTPS, DDoS defences are frequently unable to look at the contents of the packet itself. As a result, many DDoS defences 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 six types of application-layer (L7) DDoS attacks to watch out for:
  HTTP/S floods

These work by directing large numbers of HTTP requests to a web page in order to overload target servers with requests. This attack is similar to other types of network-level flooding attacks, except that it operates at the application layer, using high volumes of HTTP/S GET or HTTP/S POST requests.

In fact, as the vast majority of internet traffic nowadays is encrypted, most HTTP flood attacks today are HTTPS floods. These encrypted floods are much more potent because of the high amount of server resources required to handle them, and they also add a layer of complexity to mitigating such attacks, since DDoS defences usually cannot inspect the contents of the HTTPS requests without fully decrypting all traffic.

Negotiation attack - AKA '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 up to 15 times more computing resources from the incoming server than from the client making the request. 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 to overwhelm the server's resources and ability to accept new connections.

Although HTTPS floods take advantage of this mechanism, there are other variations such as encrypted SYN floods or SSL renegotiation 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 volume bursts of traffic.

Instead, they take the opposite approach by sending a small number of connections but keeping them open as long as possible until they exhaust the target server's resources.

This approach allows low-and-slow attacks to ‘fly under the radar' of traditional DDoS defences based on volume thresholds, since they do not cause large spikes 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 RUDY (‘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 at a very slow rate) – drawing out the connection and limiting the server's ability to accept new connections.

HTTP/S bomb – AKA ‘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 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 a high number of server resources with a limited number of connections.

Large file download – AKA ‘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 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 defences look only at incoming traffic, not outgoing traffic.

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 brute force 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 brute force attempts include server scanning, password cracking, credential stuffing, and more. The challenge with dealing with such 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 application-layer attack is not a DDoS attack per se, but it achieves the same objectives by denying an organisation's ability to serve its customers. Denial of inventory attacks use automated bots to go into organisations' 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 customers trying to purchase the same inventory.

Although this attack does not target the traffic pipe or server resources, it achieves the same result of denying service from legitimate customers.

This is a particularly difficult form of attack to mitigate, since it is difficult to discern an actual paying customer from a bot.