Медленная Http Post атака в Nginx

Question

Чтобы проверить уязвимость на наших серверах приложений, мы запустили сканирование Qualys. Из отчета мы обнаружили, что наши серверы приложений уязвимы для медленной атаки HTTP Post. Чтобы смягчить эту атаку, мы настроили nginx перед серверами приложений на основе отчета Qualys ( https://blog.qualys.com/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks). Согласно Qualys, если серверы поддерживают соединение открытым более 120 секунд, они считают, что сервер уязвим для медленной атаки HTTP Post. Даже если время ожидания nginx по умолчанию составляет 60 с, оно поддерживает соединение более 2 минут на нашем сервере приложений. Мы также проверили состояние соединения nginx, оно сохраняет соединение в состоянии записи более 2 минут.

Пожалуйста, помогите нам настроить nginx для предотвращения медленной атаки HTTP Post.

Текущая конфигурация nginx

user nginx;
worker_processes auto; 
worker_rlimit_nofile 102400; 

events {
    worker_connections 100000; 
}

access_log off;  
autoindex off;
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=2r/s;   
limit_conn_zone $binary_remote_addr zone=limitzone:10m;  
limit_conn_status 403;   
limit_req_status 403;
sendfile on; 
tcp_nopush on; 
tcp_nodelay on; 
keepalive_timeout 20 15; 
client_body_timeout 5s;  
client_header_timeout 5s;  
send_timeout 2;  
reset_timedout_connection on;   
types_hash_max_size 2048;  
server_tokens off;
client_body_buffer_size 100K;  
client_header_buffer_size 1k;  
client_max_body_size 100k;  
large_client_header_buffers 2 1k;

include /etc/nginx/mime.types;
default_type application/octet-stream;

upstream backend {   
    server 127.0.0.1:8080 max_conns=150;   
}

server {  
    listen 443 ssl http2 default_server;
    \# listen [::]:443 ssl http2 default_server;
    server_name *******;
    underscores_in_headers on;

    if ($request_method !~ ^(GET|HEAD|POST|PUT|DELETE)$ ) {
        return 444;
    }

    *** ssl configuration ***
        .....

    location / {  
        limit_conn limitzone 20; 
        limit_req zone=req_limit_per_ip burst=5 nodelay; 
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;   
        proxy_cookie_path / "/; HTTPOnly; Secure; SameSite=strict";   
        proxy_set_header X-Real-IP $remote_addr;  
        proxy_set_header X-Forwarded-Proto https; 
        proxy_pass http://backend;
    }
}

Answer 1

Если у вас нет очень популярного сайта, но для начала или нового сайта есть несколько настроек, которые имеют слишком высокое значение. Вы всегда можете настроить его позже после того, как сайт заработает.

1) worker_rlimit_nofile 102400

Не уверен, сколько памяти имеет ваш сервер, но я думаю, что это слишком большое число, я бы предложил установить что-то вроде:

worker_rlimit_nofile 8192;

2) worker_connections 100000

Обычно он настраивает worker_processes и worker_connections в зависимости от количества процессоров / ядер, содержимого и нагрузки. Формула имеет вид max_clients/second = worker_processes * worker_connections. worker_connections значение не должно быть в 100000; Значение Nginx по умолчанию только в 1024если у вас есть 4 ядра ЦП, число клиентов, которые он может обработать, будет 1024 x 4 = 4096 клиентов / секунду.

Я бы также предложил добавить multi_accept on; который информирует каждый рабочий_процесс о принятии всех новых подключений за раз, вместо того, чтобы принимать одно новое подключение за раз.

events {
    worker_connections 1024;
    multi_accept on;
}

3) Тело клиента и размер заголовка

Одна из рекомендаций по предотвращению медленной http-атаки - установить достаточно малую client_max_body_size, client_body_buffer_size, client_header_buffer_size, large_client_header_buffersи увеличивать при необходимости. Но я думаю, что вы могли бы установить эти директивы слишком низкими, чтобы они повлияли на производительность сервера, я бы порекомендовал просто использовать значения по умолчанию, рекомендованные модулем http ядра Nginx на данный момент.

client_header_buffer_size 1k;
client_body_buffer_size 16k;    # 8k for 32-bit or 16k for 64-bit platform
client_max_body_size 1m;
large_client_header_buffers 4 8k;

Кстати, как лучшая практика, все основные настройки должны быть обернуты в http директива, так что это относится ко всему http трафика. Я бы также рекомендовал вам установить access_log on так как очень полезно лучше понимать трафик (и атаки) на ранней стадии развертывания сервера.

http {
    access_log off;  
    autoindex off;

    # other settings

    .....

    upstream backend {   
        server 127.0.0.1:8080 max_conns=150;   
    }
}

Answer 2

Из документации NGINX для client_body_timeout

Тайм-аут устанавливается только на период между двумя последовательными операциями чтения, а не для передачи всего тела запроса. Если клиент ничего не передает в течение этого времени, запрос завершается с ошибкой 408 (тайм-аут запроса).

(курсив мой)

Я читал это, поскольку Qualys могла бы поддерживать соединение открытым, отправляя блоки через 59 секунд, а затем снова через 118 секунд - тем самым избегая тайм-аута, сохраняя соединение открытым.

Я не знаю конкретного способа ограничить "передачу всего тела запроса".