4 ms·
Thread exhaustion attack 1. Start <thread_count> connections to a server 2. Hold connections open 3. Do nothing else Server 1. Incoming connection. assign
by gridspy 11mo ago
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.
- kelnos 11mo agoYou didn't actually address the concerns I laid out. And I acknowledged that a reverse proxy, appropriately configured, could mitigate the issue.
- deleted 11mo ago[deleted]
- cryptonector 11mo agoThe 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.