On 9/27/25 03:08, Maxim Dounin wrote:
Hello!
Maxim, many thanks. Currently battling a DDoS including out of control
"AI". Front end nginx/1.18.0 (Ubuntu) easily handles volume (CPU usage
rarely above 1%) but proxied apache2 often runs up to 98% across 12
cores (complex cgi needs 20-40 ms per response.)
I'm attempting to mitigate. Your advice appreciated. I've "snipped"
below for readability:
[snip]
I am currently (a bit "hit and miss") using :
proxy_buffering on; # maybe helps proxied apache2 ?
Proxy buffering is on by default (see
http://freenginx.org/r/proxy_buffering), so there is no need to
switch it on unless you've switched it off at previous
configuration levels.
Understood, thanks -- I had two lines (rem'd in or out for testing
purposes) trying to respect genuine requests from regular users. Given
that nginx has a lot of spare capacity, could this be better tuned to
alleviate the load on the back end? I've read your doc, but in a
production environment, I'm unsure of the implications of "proxy_buffers
number size;" and "proxy_busy_buffers_size size;"
connection_pool_size 512;
client_header_buffer_size 512;
large_client_header_buffers 4 512;
Similarly, I would rather use the default values unless you
understand why you want to change these.
Maybe mistakenly, I was trying to eliminate stupidly artificial cgi
requests -- "GET /cgi-bin/....." that ran several kilobytes long. The
backend apache could "swallow" them (normally a 404) but I was trying to
eliminate the overhead.
location ~ \.php$ { return 444; }
You did not mention this, but it does not appear to work well.
access.log today gives hundreds of:
104.46.211.169 - - [27/Sep/2025:12:32:12 +0000] "GET /zhidagen.php
HTTP/1.1" 404 5013 "-" "-"
and the 5013 bytes is our "404-solr-try-again" page, not the 444 expected.
if ($http_user_agent = "") { return 444; }
/.../
Note the "-" which doesn't get a 444,
/.../
But if you really want to, there two basic options:/.../
Thanks. This was a previous suggestion on this list -- many/most
malicious actors don't give a $http_user_agent -- I'll play with it....
Also, depending on the traffic pattern you are seeing, it might be
a good idea to configure limit_req / limit_conn with appropriate
limits.
Again thanks, I had tried various 'location' lines such as
limit_req_zone $binary_remote_addr zone=mylimit:5m rate=1r/s;
limit_req zone=mylimit burst=5 nodelay;
without success... obviously haven't fully understood
Truly appreciate your assistance,
tnx and br
Paul
\\\||//
(@ @)
ooO_(_)_Ooo__________________________________
|______|_____|_____|_____|_____|_____|_____|_____|
|___|____|_____|_____|_____|_____|_____|_____|____|
|_____|_____| mailto:[email protected] _|____|____|
