Comment by kelnos | Hacker News Reader

Comment by kelnos | Hacker News Reader

Parent Full thread

Not sure if I agree with you on the thread exhaustion issue. The client can still send a flood of correctly-formed requests; the reverse proxy will pass them all through. As I said above, yes, the fact that babble processes requests so quickly would make this harder, but you could still end up with (tens of?) thousands of concurrent requests if someone is really determined to mess with you.

A solution could be to limit concurrent requests in the reverse proxy, but personally I prefer to write software that doesn't require another piece of software, configured correctly, to keep it safe.

And regardless, even with ~25 years of C experience under my belt, I don't think I'd ever be wholly comfortable exposing my C code to the internet, even behind a reverse proxy. Not coming at you directly with this, but I'm frankly skeptical of anyone who is comfortable with that, especially for a one-off service that won't see a lot of use and won't get a lot of eyeballs on it. (And I'm especially uncomfortable with the idea of posting something like this on a website and encouraging others to use it, when readers may not understand the issues involved.)

> The client can still send a flood of correctly-formed requests

This is possible with any server. It's a known exploit and very difficult to fully mitigate: https://en.wikipedia.org/wiki/Denial-of-service_attack Whatever you do, they can always overwhelm your network connection.

And yes, there is inherent risk with exposing any service to the internet. That goes for any program, written in any language (remember Log4Shell?) doing any task.

I continuously encourage others to do exactly this. It is a great learning opportunity. If they are not aware that they will get DoS'd now they will know. It's not like they will get PTSD from having to wait for OOM killer or losing their vps. You learned it that way, I learned it that wat, why not others? At least this way they will have real experience under their belt, not some online diatribe.

Thread exhaustion attack

1. Start <thread_count> connections to a server

2. Hold connections open

3. Do nothing else

Server

1. Incoming connection. assign a thread.

2. Wait for request <--- Attack causes us to get stuck here

3. Serve request

4. Close connection and thread / return to threadpool

Solution: Use a reverse proxy to handle the incoming connections. Typical reverse proxies such as nginx use event-based polling not a per-connection thread so they are immune to this issue.

You didn't actually address the concerns I laid out. And I acknowledged that a reverse proxy, appropriately configured, could mitigate the issue.

The way you deal with this is that you write the server to be async I/O based with NPROC threads, not a thread-per-client design, and then you can use CPS for the business logic, but in this case it's so trivial... You can probably get by with just a handful of bytes of memory pressure per client in the app + whatever the per-client TCB is for the TCP connection for a total of less than 200 bytes per client.

Reply on news.ycombinator.com