The DDoS world keeps hitting new records, where the highest reported attacks in recent memory include the attacks on KrebsOnSecurity.com and on OVH and Dyn (from 2016), which reached a bandwidth of more than 1 Terabyte of traffic.
While the bandwidth numbers are impressive indeed, the numbers themselves were expected and this 1T throughput record will probably be broken again.
So what is the amazing part of the above mentioned attacks? They were not reflective attacks (which leverage large internet servers amplifying the attacker requests) that the DDoS world was used to. In these instances, the attacks consisted of many semi-legit HTTP get requests.
Such layer 7 attacks, which are aimed at the internet pipe as well as the application server behind it, are much harder to block than a layer 3 and layer 4 attack. Such attacks are also much harder to conduct.
Why is it so hard to protect against these layer 7 attacks?
A Look at Mitigation Techniques
A good mitigation technology has to distinguish between legitimate traffic and a malicious attack. The mitigator needs to allow the legitimate traffic to pass through, while dropping the attack traffic and not letting it hit the application server.
There are several techniques to block attacks automatically, such as responding to the request to verify correct network behavior from the source, or identifying repeating patterns in the traffic headers or a rate limit based on traffic parameters.
To demonstrate the application layer mitigation and to show the difference in mitigation complexity between layer 3 and layer 4 network attacks and layer 7 HTTP application attacks, let’s look at these techniques one by one.
The request response technique, also known as challenges, is often used to block attacks. On the network layer, when a “syn” packet is received from a source IP, the mitigator can respond with a quick “syn-ack” response, and verify the “ack” response back. Only once a valid “ack” response is received is the session allowed through.
However, on the application-based attack, the attacker device will answer such “syn-ack” challenge with a valid “ack” packet. If the mitigator wants to continue with this technique, it will need more CPU power, this time to create a valid HTTP packet with a valid HTTP response that will result in session continuation (usually a redirect-to-self request).
This layer 7 challenge can indeed be used to block attacks, but as described above, it requires a lot more complexity in code and more CPU cycles. Having said that, it’s important to know that such techniques can usually block application attacks, and a proper DDoS mitigator needs to have it in its mitigation arsenal, not relying on only application level challenges.
Pattern identification is often used in the DDoS world to block attacks. After all, the attack traffic is generated using some sort of a software that is sending it from multiple locations. This one software usually has something in common which distinguishes it from legit scattered users.
In a network-based attack, the mitigator should create a signature of repeating patterns. Good mitigators can even create such patterns automatically without manual intervention – such automation also saves time for fast mitigation.
On network layer mitigation, the pattern will match the layer 3 or layer 4 headers. These headers are easy to parse using software, and the options to search are limited – the headers are well formed and each field has a limited value range.
Going into the HTTP layer is much more complicated – the HTTP headers are more loosely defined, and the values (in most cases, text) have variable ranges and length. Finding a pattern in the HTTP is possible, but as before, much more complex. The application first needs to parse the packet to get to the layer 7 part, then parse the various parts of the HTTP headers and data and then find the repeated pattern.
Even once the pattern is found, it’s much harder to block – the mitigation action should parse each packet’s layer 3, layer 4 and layer 7 data to get to the right place where the pattern is hiding. Again, more code and CPU cycles are needed to block the attack.
Rate limiting, while a valid mitigation technique, is one that should be considered a last resort in the DDoS world. The main problem with rate limiting is the lack of ability to distinguish between legitimate and attack traffic. When the rate limit is in action, it does not know which packets come from a human being or a bot, as it’s blindly blocking based on rate alone.
However, in some cases, rate limit is the only way to block the attack and protect the service infrastructure from going down. Even though rate limit is harder in the application layer – rate limiting packets is not enough since you do want to allow legitimate users to pass though – you should rate limit the HTTP request.
Here again, the mitigator needs to parse and understand if this is indeed an HTTP packet. The data is seen only after the TCP 3-way handshake is done, and in many cases the session is already opened to the server.
To summarize, we see that any known mitigation technology has to perform harder in order to block an application-based attack. Since application-based attacks are already part of our life, and will continue to grow and get more sophisticated, it is important to find a good mitigator that can actually block them, and will keep up with the attackers constantly developing methods.
This post was updated on September 12, 2019.
Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.
Lior Rozen is the Director of Technologies for Radware. With over a decade of experience, he is a cyber-security expert, architecting innovative cyber security solutions and deployments tailored for Radware’s customers’ needs. Before taking his current position, Lior was the director of R&D for Radware’s DefensePro, managing all R&D aspects of this DDoS-protection market-leader technology. Lior led the shift to virtualized-ready software architecture, while promoting partnerships with leading security companies. Lior writes about network security and technology.