Attack MitigationDDoSSecurity

DDoS Protection Requires Looking Both Ways

March 26, 2019 — by Eyal Arazi1


Service availability is a key component of the user experience. Customers expect services to be constantly available and fast-responding, and any downtime can result in disappointed users, abandoned shopping carts, and lost customers.

Consequently, DDoS attacks are increasing in complexity, size and duration. Radware’s 2018 Global Application and Network Security Report found that over the course of a year, sophisticated DDoS attacks, such as burst attacks, increased by 15%, HTTPS floods grew by 20%, and over 64% of customers were hit by application-layer (L7) DDoS attacks.

Some Attacks are a Two-Way Street

As DDoS attacks become more complex, organizations require more elaborate protections to mitigate such attacks. However, in order to guarantee complete protection, many types of attacks – particularly the more sophisticated ones – require visibility into both inbound and outbound channels.

Some examples of such attacks include:

Out of State Protocol Attacks: Some DDoS attacks exploit weaknesses in protocol communication processes, such as TCP’s three-way handshake sequence, to create ‘out-of-state’ connection requests, thereby drawing-out connection requests in order to exhaust server resources. While some attacks of this type, such as a SYN flood, can be stopped by examining the inbound channel only, others require visibility into the outbound channel, as well.

An example of this is an ACK flood, whereby attackers continuously send forged TCP ACK packets towards the victim host. The target host then tries to associate the ACK reply to an existing TCP connection, and if none such exists, it will drop the packet. However, this process consumes server resources, and large numbers of such requests can deplete system resources. In order to correctly identify and mitigate such attacks, defenses need visibility to both inbound SYN and outbound SYN/ACK replies, so that they can verify whether the ACK packet is associated with any legitimate connection request.

[You may also like: An Overview of the TCP Optimization Process]

Reflection/Amplification Attacks: Such attacks exploit asymmetric responses between the connection requests and replies of certain protocols or applications. Again, some types of such attacks require visibility into both the inbound and outbound traffic channels.

An example of such attack is a large-file outbound pipe saturation attack. In such attacks, the attackers identify a very large file on the target network, and send a connection request to fetch it. The connection request itself can be only a few bytes in size, but the ensuing reply could be extremely large. Large amounts of such requests can clog-up the outbound pipe.

Another example are memcached amplification attacks. Although such attacks are most frequently used to overwhelm a third-party target via reflection, they can also be used to saturate the outbound channel of the targeted network.

[You may also like: 2018 In Review: Memcache and Drupalgeddon]

Scanning Attacks: Large-scale network scanning attempts are not just a security risk, but also frequently bear the hallmark of a DDoS attack, flooding the network with malicious traffic. Such scan attempts are based on sending large numbers of connection requests to host ports, and seeing which ports answer back (thereby indicating that they are open). However, this also leads to high volumes of error responses by closed ports. Mitigation of such attacks requires visibility into return traffic in order to identify the error response rate relative to actual traffic, in order for defenses to conclude that an attack is taking place.

Server Cracking: Similar to scanning attacks, server cracking attacks involve sending large amounts of requests in order to brute-force system passwords. Similarly, this leads to a high error reply rate, which requires visibility into both the inbound and outbound channels in order to identify the attack.

Stateful Application-Layer DDoS Attacks: Certain types of application-layer (L7) DDoS attacks exploit known protocol weaknesses or order to create large amounts of spoofed requests which exhaust server resources. Mitigating such attacks requires state-aware bi-directional visibility in order to identify attack patterns, so that the relevant attack signature can be applied to block it. Examples of such attacks are low-and-slow and application-layer (L7) SYN floods, which draw-out HTTP and TCP connections in order to continuously consume server resources.

[You may also like: Layer 7 Attack Mitigation]

Two-Way Attacks Require Bi-Directional Defenses

As online service availability becomes ever-more important, hackers are coming up with more sophisticated attacks than ever in order to overwhelm defenses. Many such attack vectors – frequently the more sophisticated and potent ones – either target or take advantages of the outbound communication channel.

Therefore, in order for organizations to fully protect themselves, they must deploy protections that allow bi-directional inspection of traffic in order to identify and neutralize such threats.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

Attack Types & VectorsDDoSSecurity

Layer 7 Attack Mitigation

November 8, 2016 — by Lior Rozen4


The DDoS world keeps hitting new records, where the highest reported attacks in recent memory include the attacks on and on OVH and Dyn (from 2016), which reached a bandwidth of more than 1 Terabyte of traffic.

Digital background of Internet Security

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.

[You may also like: 5 Steps to Prepare for a DDoS Attack]

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.

[You may also like: The Normalization of DDoS Attacks]

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.

Request Response

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.

[You may also like: Why You Still Need That DDoS Appliance]

Pattern Identification

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.

[You may also like: Botnets: DDoS and Beyond]

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

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.

[You may also like: 5 Key Considerations in Choosing a DDoS Mitigation Network]

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.

Download Now