Hacker News Reader

Comment by nodata | Hacker News Reader

(This has been known about for ages.)

I agree. I've been killing servers with it since the '90s. The current interest comes from it (possibly) arriving as an attack tool in botnets and not being mitigated by current anti-DDOS methods.

It is time to cope with it.

Yeah, because existing anti-DDoS methods are so effective at "conventional" DDoS attacks. Uh-huh.

Yep, and this is why evented io is pretty much mandatory for a modern webserver (like nginx). If you need Apache you can always proxy nginx in front of it.

file descriptors aren't free, even for evented webservers. you've only moved the limit higher, not removed it.

This is true but not really responsive to the parent comment's point; the nginx architecture is better suited to handling this kind of attack; contexts are much more expensive than file descriptors.

File descriptors are themselves an artificial construct that can be coded around. In the unlikely event that this attack ever became super relevant, a relatively simple kernel module could drastically amp up the number of connections a host could absorb --- although a RED queue would probably keep you from having to go even that far.

I'm not sure what you mean by context. Clearly nginx also has some context, such as the data read so far, associated with each handle. I guess you mean thread stack?

Apache has an entire execution context associated with it (either a thread or a process).

Yep .. one example of a similar attack here - http://ha.ckers.org/slowloris/ - with references to others.

And it would be easy enough to defend against if it really became a problem -- just time out. Most web sites don't need have a need to receive gigantic POST data.

It's difficult to distinguish between a persistent user trying to upload a large image over a spotty satellite link and a hacker.

You're right, but I still don't believe this creates an impossible situation:

* most webapps don't allow giant user uploads of any kind

* if you have a persistent user with a net connection that's that slow then you have no choice but to time him out

A sufficiently-slow connection will make even a reasonable amount of data take a long time. I'm sure Flickr has users that upload large photos over satellite links...

There's also no reason why you need to time this person out. If you configure kernel and application for small (or auto-sizing) buffers and use an event-based structure for the application, you should be just fine.

It's really a matter of one's approach and level of paranoia. Me? If I wasn't running Flickr (say I was running getfreckle.com), I'd probably opt for more conservative settings. I may not need to time that guy out, but I'd probably do it so I wouldn't have to worry later.

* If you configure kernel and application for small (or auto-sizing) buffers and use an event-based structure for the application*

This would be all the better.

True. Though it's a safe assumption that if you suddenly have a large number of spotty satellite users and they're DOSing your site it's probably something malicious.

Reply on news.ycombinator.com