在Nginx中缓慢的Http Post攻击

时间:2018-04-26 11:52:27

标签: http security nginx nginx-reverse-proxy qualys

为了检查我们的应用服务器中的漏洞,我们运行了Qualys扫描。从报告中我们发现我们的应用服务器容易受到HTTP Post攻击的影响。为了缓解这种攻击,我们根据Qualys报告(https://blog.qualys.com/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks)在应用服务器前配置了nginx。根据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;
    }
}

2 个答案:

答案 0 :(得分:1)

除非您有一个非常受欢迎的网站,但对于开始或新网站,有一些设置设置为太高的值。您可以在网站上线后随时调整它。

1)worker_rlimit_nofile 102400

不确定你的服务器有多少内存,但我认为这个数字太大了,我建议设置为:

worker_rlimit_nofile 8192;

2)worker_connections 100000

通常根据CPU /核心数,内容和负载配置worker_processes和worker_connections。公式为max_clients / second = worker_processes * worker_connections。 worker_connections值不需要为100000;默认的Nginx值仅为1024,如果您有4个CPU核心,则它可以处理的客户端数量为1024 x 4 = 4096个客户端/秒。

我还建议添加multi_accept on;,通知每个worker_process一次接受所有新连接,而不是一次接受一个新连接。

events {
    worker_connections 1024;
    multi_accept on;
}

3)客户端正文和标题大小

防止慢速http攻击的建议之一是设置相当小的client_max_body_sizeclient_body_buffer_sizeclient_header_buffer_sizelarge_client_header_buffers,并在必要时增加。但我认为您可能会将这些指令设置得太低而不会影响服务器的性能,我建议您暂时使用Nginx http core module建议的默认值。

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;
BTW,作为最佳实践,所有基本设置都应该包含在http指令中,以便它适用于所有http流量。我还建议您设置access_log on,因为在服务器部署的早期阶段更好地了解流量(和攻击)非常有用。

http {
    access_log off;  
    autoindex off;

    # other settings

    .....

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

答案 1 :(得分:0)

NGINX docs for client_body_timeout

  

仅将超时设置为两次连续读取操作之间的一段时间,不为整个请求正文的传输设置。如果客户端在这段时间内未传输任何内容,则请求会因408(请求超时)错误而终止。

(重点是我的)

我读到,由于Qualys可以通过在59秒后发送块然后在118秒后再次发送块来保持连接打开,从而避免了在保持连接打开的情况下超时。

我不知道限制“整个请求主体的传输”的特定方法。