Ask HN: What's being done with the HTTP protocol to fix DDOS attacks? | Hacker News Reader

Ask HN: What's being done with the HTTP protocol to fix DDOS attacks?

6 pointsjoslin0110 comments

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.

I don't see how a protocol would help. This is very application specific.

One could exploit algorithmic complexity attacks, like a bad regexp, but that's usually specific to your own code.

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).

You used enough unknown-to-me idiom in that that I actually have no idea what you meant. ("wacky-wave hands"? "mouth breather variety"?)

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.

I'll bet we could add a header to fix the problem, similar to the way RFC3514 fixes DDOS problems at the TCP layer.

https://tools.ietf.org/html/rfc3514

Problem source is not at the HTTP protocol layer, so probably not much.

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.

Reply on news.ycombinator.com