Minimize Slow-Loris Style DoS Risk with Adaptive Bandwidth-Limited Timeouts

[SergioBenitez]

Note: Rocket (> 0.4) is not particularly susceptible to the kinds of attacks described below. This issue tracks being able to do better than the status quo, not merely meeting it. There are no known bugs or deficiencies, security or otherwise, related to the topics described in this issue.

A data limit (#1325) is not a sufficient...limit...to prevent DoS attacks. While it helps mitigates memory-exhaustion based attacks, it does nothing to prevent slow-loris style attacks. On async, this translates to a bunch of idling futures, which in-turn means consuming memory, which takes us to memory-exhaustion.

What we'd really like to do is expose an API that requires limits to be set on several properties, with a hard, indelible limit provided by Rocket. In particular:

• read timeouts - how long we we're willing to wait between byte reads
• data limits - how many bytes we're willing to read in all, irrespective of time
• connection timeouts - how long we're willing to keep the connection open, irrespective of whether data is being received or not.

My take is that an adaptive bandwidth-minimum approach to the connection timeout might actually make a bit more sense, especially when we consider very purposefully long-lived connections. That is, after a chosen period of time, assuming the other timeouts/limits haven't been exceeded, require that the bandwidth over a sliding window of time exceeds some value. Otherwise, kill the connection, ideally in a graceful manner.

This approach seems fairly easy to implement in async. Combined with the API I proposed above, this should significantly decrease the opportunity for DoS based attacks on Rocket applications, and in the common case, make them impossible.

This was largely ported over from #990 and #1325.

[igalic]

does hyper have a bug tracking this that i can follow?

[SergioBenitez]

@igalic We can implement the majority of this feature in Rocket itself, but https://github.com/hyperium/hyper/issues/1628 is a pre-requisite for it to meaningfully contribute to Rocket's security and stability.

[luisvonmuller]

I've mitigated some of the slow-loris attacks with this tutorial (we're running reverse proxies from NGINX) https://hexadix.com/slowloris-dos-attack-mitigation-nginx-web-server/

But I'm waiting for a native implementation too, would love to help to fix it out.

[SergioBenitez]

@luisvonmuller The fix should either be upsteam, in hyper itself, or as an adapter of some sort, like https://github.com/hjr3/hyper-timeout but for servers. Unfortunately, other issues in hyper may prevent the latter kind of solution from working at all (https://github.com/hjr3/hyper-timeout/issues/12).