Hacker News Reader

Comment by netsectoday | Hacker News Reader

This is very well written and practical. It's exactly how you think about security when you own a company. I'm guessing the author is/was holding a large amount of stock in Heroku/Salesforce.

Summary:

1. Don't publicly expose endpoints that are either slow or require a ton of resources.

2. If you can't get rid of a slow endpoint; put authentication in front of it so you have a lever to pull in the event of an attack.

3. Throttle / rate limit everything with high barriers so not to impede normal traffic patterns.

4. Don't make it easy for someone to DoS you; reduce or eliminate well-know attack vectors and vulnerabilities.

5. Scan your app for regex and zip bombs.

6. The bad guys will sniff-out your N+1 queries, so fix them.

7. If necessary: pay for DDoS mitigation from a cloud provider.

View on HN

8. Set timeouts for the maximum time a client can take to send a request.

For Example, the attacker will send a GET request using many small packets with a large time gap between them. They do this by first sending the “G” in its own packet, after a while they will send the “E” and after some more time the “T” and so on. While this is a legitimate behavior according to the HTTP and TCP protocols, this behavior is consuming a lot of resources from the server – it has to keep the connection open, waiting for the full request to arrive. Since the connection pool is limited, it is very easy to reach pool saturation, with very little traffic.

https://en.wikipedia.org/wiki/Slowloris_(computer_security)

"There are ways to mitigate or reduce the impact of such an attack. In general, these involve increasing the maximum number of clients the server will allow, limiting the number of connections a single IP address is allowed to make, imposing restrictions on the minimum transfer speed a connection is allowed to have, and restricting the length of time a client is allowed to stay connected."

Yup all great points for mitigation strategies. Sometimes admins think DDoS = Traffic overload and forget to consider that slow connections can be just as effective as flooding if the configuration allows.

In order to defend against slow-client (Slowloris) attacks, reasonable timeouts are necessary but not sufficient if your server has a limited pool of request handlers (or if it uses a separate resource-intensive process/thread per connection). You need a HTTP server (or proxy such as nginx) that buffers incoming requests using async IO syscalls (e.g., `epoll` or at least `select`) until a complete request is ready to be handled by the application.

Even with async IO buffering requests it's still possible for a slow-client DoS to exhaust other system resources (such as file descriptors), but with properly-tuned limits the required attack will need to be many orders of magnitude greater to succeed.

Reply on news.ycombinator.com