Slowloris. Slow Post. HashDos. Dirt Jumper. Tor Hammer. Keep-Dead.
Sounds more like a list of names for Transformers than what they are: application-layer DDoS attacks and toolsets.
Attacks in general have been moving up the network stack to layer 7 for some time, but those we hear the most about tend to be those that result in data breaches such as SQL injection and XSS (Cross-Site Scripting). Lesser mentioned are the application-layer DDoS attacks, maybe because if they are difficult to defend against, they are even more difficult to simply detect.
It is their very modus operandi that makes them a needle in a haystack. There is nothing anomalous or odd about the packets that comprise the application requests, nor the application requests themselves. It isn’t that they are barraging a resource at a rate that’s abnormal. The problem is these attacks exploit the normal, expected behavior of applications in such a way as to rapidly consume resources and ultimately render the application (or intermediate infrastructure in the data path) unresponsive.
What attacks have learned is that the infrastructure often in place to support security and delivery of applications is not intelligent enough to detect when a client is behaving oddly. For example, one class of application DDoS attacks mimics a DNS attack in that it uses the disparity between request and response size to overwhelm servers. But it does this not by sending a noticeably larger or faster number of requests (that would likely be noticed by security infrastructure), rather it simply pretends that it is connected to the Internet with speeds akin to a 28.8 baud modem, which forces the server to send responses more slowly. Ultimately a single attacker with very few clients can fill up the send queues on a server and cause it to become unresponsive to other requests.
Other attacks do attempt to overwhelm through sheer force – but at the application layer, not the network. What the network and security infrastructure often see is simply a sudden spike in application requests. These floods are not seen as dangerous by most infrastructure services because they are all legitimate. The infrastructure cannot distinguish between application layer attacks such as simple HTTP or GET Flood and a legitimate sudden surge in traffic. Applications themselves are inherently unable to detect such attacks as well. Each request is isolated from the other; there’s no way for a developer to ask how many other requests are being serviced. And even if there were a way, it would provide no better insight into whether the requests were legitimate or part of a larger attack.
Infrastructure must therefore provide a solution that can adequately mitigate the impact of such attacks. It isn’t a matter of stopping them – that’s not possible. What is possible is to put into the data path solutions capable of buffering the more sensitive application infrastructure from the impact of such attacks.
Such solutions able to serve as a buffer between potential attackers and application infrastructure must be capable of managing hundreds of thousands if not millions of application connections without negatively impacting other applications that may be sensitive to jitter and latency, such as voice and video. To assist in achieving that, such infrastructure should be topologically near the edge of the network, to provide buffering and filtering of attacks in such a way as to prevent the natural congestion arising out of amplified, application attacks from impacting business critical voice and data operations.
Application layer DDoS attacks are real and on the rise. Mitigating their impact is key to ensuring that applications and critical business services are not impacted by these increasingly stealthy attack patterns.
Lori MacVittie is senior technical marketing manager at F5 Networks (News - Alert) (www.f5.com).
Edited by Stefania Viscusi