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

Чтобы проверить уязвимость на наших серверах приложений, мы запустили сканирование 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;
    }
}

http nginx security nginx-reverse-proxy qualys
person Puratchi Selvan    schedule 26.04.2018    source источник
comment
Во-первых, какова ваша текущая конфигурация?   -  person hcheung    schedule 26.04.2018
comment
Я добавил свою конфигурацию nginx для справки   -  person Puratchi Selvan    schedule 26.04.2018

Ответы (2)


arrow_upward
1
arrow_downward

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

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.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size на данный момент.

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;   
    }
}
person hcheung    schedule 27.04.2018

arrow_upward
1
arrow_downward

Из документов NGINX для client_body_timeout

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

(выделено мной)

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

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

person mknecht    schedule 17.10.2019