Re: Как лучше всего сделать защиту от denial of service при исчерпании свободного места на диске большими по объему лог-файлами nginx?

Gena Makhomed gmm на csdoc.com
Вт Фев 13 04:43:53 UTC 2024


On 13.02.2024 4:21, Gena Makhomed wrote:

> Когда свободного места на диске нет - то nginx туда, естественно,
> ничего и не пишет, когда свободное место появляется - процесс записи
> логов автоматически продолжается, тут ничего настраивать не нужно.
> 
> Единственная проблема которая есть в такой сиутации - перестают работать 
> POST-запросы, если в каталоге client_body_temp_path ноль байт свободного
> места, но все остальные типы запросов в такой ситуации nginx продолжает
> нормально обрабатывать. И теряется возможность записи информации в логи.
> 
> Все остальное - вроде бы работает нормально, когда 0 байт
> свободного места на диске - но я очень детально это не проверял.

Не знаю, насколько часто встречается такая проблема в дикой природе,
но если возникает ошибка записи во время записи client_body в файл
в client_body_temp_path - теоретически - можно было бы прочитать,
то что успели уже записать в файл, отправить на backend
и на какое-то время - переключить режим работы директив

fastcgi_request_buffering
proxy_request_buffering
scgi_request_buffering
uwsgi_request_buffering

временно из текущего режима работы (on?) в режим работы off, например,
на 1 минуту, и если через 1 минуту на разделе куда указывает директива
client_body_temp_path появится достаточное количество свободного места,
например,  N * client_max_body_size при каком-то разумном значении N -
тогда вернуть обратное старое значение, какое было для этих директив
до момента переключения в такой режим работы.

Кстати, что интересно, для модуля grpc в коде установлено

r->request_body_no_buffering = 1;

поэтому проксирование grpc запросов всегда будет нормально работать,
даже в том случае, когда на диске будет 0 байт свободного места.

Или - не имеет смысл настолько усложнять код nginx? Потому что
в таком случае - если не настроен мониторинг свободного места
на сервере - тогда системный администратор узнает об этой проблеме
по жалобам, что POST запросы на сайте перестали нормально работать
и на backend приходит 0 байт вместо того, что отправлял клиент.

А если сделать так, чтобы nginx не терял тело запроса и корректно
отправлял бы запросы на backend - то в такой ситуации системный
администратор может еще очень долго ничего не знать о проблеме?

Вот какое решение в этой ситуации было бы лучшим вариантом
для пользователей коммерческой версии nginx-plus и для пользователей
бесплатной версии nginx? Ведь если nginx теряет тело запроса - тогда
могут сказать, что причина проблемы - это именно nginx, почему
сайтом были утеряны ценные данные в POST-запросах клиентов.

А если nginx сможет нормально функционировать и POST-запросы смогут 
нормально функционировать, не смотря на то. что на диске 0 байт
свободного места - это может быть расценено как признак высокой
надежности nginx и как признак высокого уровня качества кода.

Как будет лучше поступить в ситуации нехватки свободного места на диске?

-- 
Best regards,
  Gena



Подробная информация о списке рассылки nginx-ru