You can't really "fix" this issue. A DDOS is just a lot of requests coming in very rapidly. You can try to mitigate the problem, but at its core, any system that is expected to respond to arbitrary web requests is vulnerable to getting lots of them--whether from being Slashdotted (or HN'd) or from an automated DDOS.
DDOS has nothing to do with HTTP, its a network layer (routing protocols) issue. Put another way, if frames are making
it all the way to your stack and up to a webserver in user space before a decision is made, you're already toasted.
There are different types of DDoS -- layer 3 and 4 attacks are not HTTP-specific, but there are layer 7 attacks which are DoS, and if distributed (botnet, etc.), are a DDoS.
Anonymous's LOIC is a great example of this kind of attack. Essentially, you go for a different kind of amplification than you do with 3/4 attacks -- it's "time amplification", where a small http request can hit a URL and cost huge amounts of time on the server. e.g. an unindexed search. It's actually possible to kill some webapps with a single web browser just by hitting "expensive" URLs repeatedly -- can even be done manually in some cases.
There are a lot of ways to protect against this -- rather than pure pipe capacity, you generally want something like a Web Application Firewall (WAF). You also generally want to tune your web app to expose only "safe" urls, or to put captchas or logins in front of "expensive" URLs.
It's not "stuff you can fix in the protocol itself" so much as "things a really smart proxy can do" -- with different levels, basically "a stateless proxy with no real specific information about your client or server other than what is well-known", "a slightly-stateful proxy which can learn", "a fully stateful proxy", "a logging proxy which just has to identify threats retrospectively and alarm, rather than block".
I hear what you're saying but layer7 DDOS attacks are a mouth breather variety. Need to burn them with fire, network level. Because it's not just HTTP it's the whole network stack you'll be chasing around with wacky-wavy hands (just incase).
Sorry for the flippancy, what I meant was it's just 1 application layer protocol (HTTP) amongst the multitude you could potentially be serving. Trying to fix for that one service means nothing, big picture, to people who know how to suppress a network, broad spectrum. Think ICMP, UDP, TCP, routing protocols (BGP if they're feeling sassy), everything that happens on the wire and in the kernel and through upstream ISP's before it even reaches your web server - HTTP protocol handling is literally the last bastion of hope in a DDOS scenario.
10 comments
[ 4.9 ms ] story [ 37.3 ms ] threadhttps://tools.ietf.org/html/rfc3514
Anonymous's LOIC is a great example of this kind of attack. Essentially, you go for a different kind of amplification than you do with 3/4 attacks -- it's "time amplification", where a small http request can hit a URL and cost huge amounts of time on the server. e.g. an unindexed search. It's actually possible to kill some webapps with a single web browser just by hitting "expensive" URLs repeatedly -- can even be done manually in some cases.
There are a lot of ways to protect against this -- rather than pure pipe capacity, you generally want something like a Web Application Firewall (WAF). You also generally want to tune your web app to expose only "safe" urls, or to put captchas or logins in front of "expensive" URLs.
One could exploit algorithmic complexity attacks, like a bad regexp, but that's usually specific to your own code.