slowhttptest | Application Layer DoS attack simulator | HTTP library

Assuming the following setup:

• Apache server 2.4
• mpm_prefork with default settings (256 workers?)
• Default Timeout (300s)
• High KeepAliveTimeout (100s)
• reqtimeout_mod enabled with the following config: RequestReadTimeout header=62,MinRate=500 body=62,MinRate=500
• Outdated mod_wsgi 3.5 using Daemon mode with 15 threads and 1 process
• AWS ElasticBeanstalk's load balancer acting as a reverse proxy to apache with 60s idle connection timeout
• Python/Django being the wsgi application

A simple slowloris attack like the one described here, using a "slow" request body: https://www.blackmoreops.com/2015/06/07/attack-website-using-slowhttptest-in-kali-linux/

The above attack, with just 15 requests (same as mod_wsgi threads) can easily lock the server until a timeout happens, either due to:

• Load balancer timeout (60s) happens due to no data sent, this kills the apache connection and mod_wsgi can once again serve requests
• Apache RequestReadTimeout happens due to data being sent, but not enough, again mod_wsgi is able to serve requests after this

However, with just 15 concurrent "slow" requests, I was able to lock the server up to 60 seconds.

Repeating the same but with a more bizarre number, like 4096 requests, pretty much locks the server permanently since there will be always a new request that needs to be served by mod_wsgi once the previous times out.

I would expect that the load balancer should handle/detect this before even sending requests to apache, which it already does for similar attacks (partial headers, or tcp syn flood attacks never hit apache which is nice)

What options are available to help against this? I know there's no failproof option since these kind of attacks are difficult to detect and protect, but it's quite silly that the server can be locked that easily.

Also, if the wsgi application never reads request body, I would expect for the issue to not happen as well since the request should return immediately, but I'm not sure about this or the internals of mod_wsgi, for example, this is true when using a local dev wsgi server (the attack files since the request body is never read) but the attack succeeds when using mod_wsgi, which leads me to think it tries to read the body even before sending it to the wsgi code.