main

DDoS AttacksHTTP Flood AttacksSecurity

Rate Limiting-A Cure Worse Than the Disease?

September 5, 2018 — by Eyal Arazi0

rate_limiting_l7_ddos_security-960x540.jpg
Rate limiting is a commonly-used tool to defend against application-layer (L7) DDoS attacks. However, the shortcomings of this approach raises the question of whether the cure is worse than the disease?

As more applications transition to web and cloud-based environments, application-layer (L7) DDoS attacks are becoming increasingly common and potent.

In fact, Radware research found that application-layer attacks have taken over network-layer DDoS attacks, and HTTP floods are now the number one most common attack across all vectors. This is mirrored by new generations of attack tools such as the Mirai botnet, which makes application-layer floods even more accessible and easier to launch.

It is, therefore, no surprise that more security vendors claim to provide protection against such attacks. The problem, however, is that the chosen approach by many vendors is rate limiting.

A More Challenging Form of DDoS Attack

What is it that makes application-layer DDoS attacks so difficult to defend against?

Application-layer DDoS attacks such as HTTP GET or HTTP POST floods are particularly difficult to protect against because they require analysis of the application-layer traffic in order to determine whether or not it is behaving legitimately.

For example, when a shopping website sees a spike in incoming HTTP traffic, is that because a DDoS attack is taking place, or because there is a flash crowd of shoppers looking for the latest hot item?

Looking at network-layer traffic volumes alone will not help us. The only option would be to look at application data directly and try to discern whether or not it is legitimate based on its behavior.

However, several vendors who claim to offer protection against application-layer DDoS attacks don’t have the capabilities to actually analyze application traffic and work out whether an attack is taking place. This leads many of them to rely on brute-force mechanisms such as HTTP rate limiting.

[You might also like: 8 Questions to Ask in DDoS Protection]

A Remedy (Almost) as Bad as the Disease

Explaining rate limiting is simple enough: when traffic goes over a certain threshold, rate limits are applied to throttle the amount of traffic to a level that the hosting server (or network pipe) can handle.

While this sounds simple enough, it also creates several problems:

  • Rate limiting does not distinguish between good and bad traffic: It has no mechanism for determining whether a connection is legitimate or not. It is an equal-opportunity blocker of traffic.
  • Rate limiting does not actually clean traffic: An important point to emphasize regarding rate limiting is that it does not actually block any bad traffic. Bad traffic will reach the original server, albeit at a slower rate.
  • Rate limiting blocks legitimate users: It does not distinguish between good and malicious requests and does not actually block bad traffic so rate limiting results in a high degree of false positives. This will lead to legitimate users being blocked from reaching the application.

Some vendors have more granular rate limiting controls which allow limiting connections not just per application, but also per user. However, sophisticated attackers get around this by spreading attacks over a large number of attack hosts. Moreover, modern web applications (and browsers) frequently use multiple concurrent connections, so limiting concurrent connections per user will likely impact legitimate users.

Considering that the aim of a DDoS attack is usually to disrupt the availability of web applications and prevent legitimate users from reaching them, we can see that rate limiting does not actually mitigate the problem: bad traffic will still reach the application, and legitimate users will be blocked.

In other words – rate limiting administers the pains of the medication, without providing the benefit of a remedy.

This is not to say that rate limiting cannot be a useful discipline in mitigating application-layer attacks, but it should be used as a last line of defense, when all else fails, and not as a first response.

A better approach with behavioral detection

An alternative approach to rate limiting – which would deliver better results – is to use a positive security model based on behavioral analysis.

Most defense mechanisms – including rate limiting – subscribe to a ‘negative’ security model. In a nutshell, it means that all traffic will be allowed through, except what is explicitly known to be malicious. This is how the majority of signature-based and volume-based DDoS and WAF solutions work.

A ‘positive’ security model, on the other hand, works the other way around: it uses behavioral-based learning processes to learn what constitutes legitimate user behavior and establishes a baseline of legitimate traffic patterns. It will then block any request that does not conform to this traffic pattern.

Such an approach is particularly useful when it comes to application-layer DDoS attacks since it can look at application-layer behavior, and determine whether this behavior adheres to recognized legitimate patterns. One such example would be to determine whether a spike in traffic is legitimate behavior or the result of a DDoS attack.

[You might also like: 5 Must-Have DDoS Protection Technologies]

The advantages of behavioral-based detections are numerous:

  • Blocks bad traffic: Unlike rate limiting, behavioral-based detection actually ‘scrubs’ bad traffic out, leaving only legitimate traffic to reach the application.
  • Reduces false positives: One of the key problems of rate limiting is the high number of false positives. A positive security approach greatly reduces this problem.
  • Does not block legitimate users: Most importantly, behavioral traffic analysis results in fewer (or none at all) blocked users, meaning that you don’t lose on customers, reputation, and revenue.

That’s Great, but How Do I know If I Have It?

The best way to find out what protections you have is to be informed. Here are a few questions to ask your security vendor:

  1. Do you provide application-layer (L7) DDoS protection as part of your DDoS solution, or does it require an add-on WAF component?
  2. Do you use behavioral learning algorithms to establish ‘legitimate’ traffic patterns?
  3. How do you distinguish between good and bad traffic?
  4. Do you have application-layer DDoS protection that goes beyond rate limiting?

If your vendor has these capabilities, make sure they’re turned-on and enabled. If not, the increase in application-layer DDoS attacks means that it might be time to look for other alternatives.

Read “2017-2018 Global Application & Network Security Report” to learn more.

Download Now

DDoS AttacksHTTP Flood AttacksSecurity

Much more than Outage: 2013 DDoS Market Review

January 27, 2014 — by Motty Alon1

What comes to mind when the term “Denial of Service” is mentioned? Probably website outage.

This image has been crafted over the last couple of years with media, analysts and bloggers all talking about Denial of Service attacks, but mostly when the result of the DoS attack caused a site outage. Our latest report, the Radware Global Application and Network Security Report addresses this and other misconceptions about DDoS.

Attack MitigationDDoS AttacksHTTP Flood AttacksSecurity

A Look Back at Black Hat: Staying True to its Roots, But Never the Same without Barnaby Jack

August 9, 2013 — by Jon Garside0

Black Hat has come and gone again, the swag has been dispersed, the livers are recovering and delegates are returning to their normal lives with new ideas and newfound fears. My colleagues will be reporting on their findings, but I wanted to just touch on a few highlights of the conference, some sadness and talk about the value of research.

Application SecurityAttack MitigationDDoS AttacksHTTP Flood AttacksSecurity

Stock Exchanges in the Line of Fire

March 6, 2013 — by Ziv Gadot0

During last week’s RSA conference in San Francisco, I gave a lecture titled "Stock Exchanges in the Line of Fire – Morphology of Cyber Attacks." Based predominantly on my experience as part of Radware’s Emergency Response Team (ERT) that provides 24/7 DDoS attack mitigation support, I focused on three specific topics:

Application SecurityAttack MitigationBotnetsBrute Force AttacksDDoS AttacksHTTP Flood AttacksPhishingSecuritySecurity VirtualizationSEIMWeb Application Firewall

eCrime Congress in Germany: Restoring the Equilibrium of Attackers Vs. Defenders

February 8, 2013 — by Ron Meyran0

Last week, I attended eCrime Congress in Frankfurt, Germany. Held on January 30,Radware was one of the sponsors of the event, which featured a lecture track that ran throughout the day and included breaks for the sponsors’ pavilion.

Application SecurityAttack MitigationBotnetsBrute Force AttacksDDoS AttacksHTTP Flood AttacksSecurity

Shooting From Behind the Fence

February 8, 2013 — by Eyal Benishti0

Can You Stay Anonymous While Participating in a DDoS Attack?
Taking part in a Hacktivist group is completely different than being part of a Botnet. In a Botnet, case participants are unknowingly “recruited” to an attack. In the Hacktivist group, case members take part in attack activities on their own accord.
Just this past month, Anonymous hackers in London were jailed for a series of DDoS attacks on PayPal and other payment services such as Visa and MasterCard.

Application SecurityAttack MitigationBotnetsBrute Force AttacksDDoS AttacksHTTP Flood AttacksPhishingSecuritySecurity VirtualizationSEIMWeb Application Firewall

New Attack Trends – Are You Bringing a Knife to the Gunfight?

January 22, 2013 — by Ziv Gadot0

Today, we launched our 2012 Global Application and Network Security report. It was prepared by our security experts – the Emergency Response Team (ERT) – who’ve seen their fair share of cyber attacks while actively monitoring and mitigating attacks in real-time. In this year’s annual report, our experts have uncovered several new trends in cyber-security worthy of a closer look.

Attack MitigationDDoS AttacksHTTP Flood AttacksSecurity

ERT Threat Alert: Olympic Security Update

July 30, 2012 — by Matan Atad0

Radware’s Emergency Response Team (ERT) releases a new threat alert regarding an upcoming DDoS attack targeting websites linked to the 2012 Summer Olympics.

Attacker Background

An event with the magnitude of the Summer Olympics is a likely target for many threats, including IT security attacks.  Radware Security researchers have found that the Olympic Games website is on the radar of hackers who published an HOIC booster script on pastebin. The time or sizes of potential attacks are unknown. Additionally, we’ve identified two companies’ URLs that were found on HOIC booster scripts in the last 24 hrs. Presumably, this means that two companies could be targeted for future attacks. Others may be targeted as well.

Application SecurityAttack MitigationBotnetsBrute Force AttacksDDoS AttacksHTTP Flood AttacksPhishingSecurity VirtualizationSEIMWeb Application Firewall

Last Week to Participate! Attack Mitigation Black Belt Final Round Begins Today.

July 16, 2012 — by Carl Herberger0

If you’ve been waiting, now’s the time to participate – the last week of Radware’s Attack Mitigation Black Belt Challenge begins today and ends this week. And what a challenge it is! More and more people are participating each week and the leader board has changed hands a number of times – with the standing after the Red Belt challenge resulting in a tie for first place!

Application SecurityAttack MitigationBotnetsBrute Force AttacksDDoS AttacksHTTP Flood AttacksPhishingSecurity VirtualizationSEIMWeb Application Firewall

Calling All Attack Mitigation Experts – Red Belt Round Begins Today!

July 9, 2012 — by Carl Herberger0

Two more weeks left in the Attack Mitigation Black Belt Challenge and congratulations to all who have earned a green belt. As we head into the next round of progressively difficult questions, we have a fierce competition for the Champion. “Brewer” is giving “dh” a run for the money, with only one second separating these first and second place contenders. Check out the Leader Board for the rankings.