Mitigating Low-and-Slow Attacks On Applications and APIs
This post is also available in:
French 
German 
Italian 
Portuguese (Brazil) 
Spanish 
Russian
“Low-and-slow” may sound like an outdated topic, but it is still very, relevant and timely. 65% of organizations suffered low-and-slow attacks in 2020, 30% of them monthly. So let’s give this the five minutes it deserves!
When an attacker wants to bring an application down, the easiest way is to launch a massive amount of traffic to the application and take down the application server (Distributed Denial of Service, or DDoS). However, there are many technologies today that can detect and block such attempts, either by IP or signature-based blocking, quota management or dedicated DDoS mitigation solutions.
In the last month, other than floods, we have seen another, old yet very effective technique coming back: the low-and-slow attack. By the end of February, Radware has already acknowledged a 20% increase in Low-and-Slow attacks against our customers compared to the fourth quarter of 2020.
A Refresher on Low-and-Slow
Instead of generating a sudden burst in traffic volume, low-and-slow (aka low-rate) attacks fly under the radar. They are aimed at bringing a target down quietly by leaving connections open on the target by creating a relatively low number of connections over a period of time and leaving those sessions open for as long as possible.
Common methods include sending partial HTTP requests and sending small data packets or “keep alive” messages to keep the session from going idle or time-out. These attack vectors are not only hard to block, but also to detect.
[You may also like: How to Keep APIs Secure in an Interconnected World]
There are several known tools that are available for perpetrators to launch such attacks including SlowLoris, SlowPost, SlowHTTPTest, Tor’sHammer, R.U.Dead.Yet and LOIC.
Low-and-slow attacks, which used to be very effective against applications, are taking advantage of overlooked APIs that aren’t as guarded as applications are, making their way to the target. Due to the low volume — and what might appear as a legitimate attempt to connect to the application or server resources — a different mitigation technology is required. The source should be blocked on a behavioral basis rather than reputation.
Behavioral Blocking
The synchronization between the detection and mitigation components is one reason why Radware is a recognized industry leader in DDoS protection: Behavioral learning algorithms monitor and measure the TCP connection response times of both client and server and make sure the source is indeed interacting with the application as expected.
This method involves no interaction with the application and introduces no risk to it, as the mitigation is done at the session level. Then, using a unique signaling mechanism and automated workflows, next attempts will be blocked at the network perimeter making no impact on the application.
