Nginx缓慢HTTP攻击防护：从Slowloris原理到四层生产加固

1. 这不是误报缓慢HTTP拒绝服务攻击的真实杀伤力与Nginx暴露面“检测到目标主机可能存在缓慢的http拒绝服务攻击”——当安全扫描工具弹出这行提示时很多运维同学的第一反应是点掉、忽略、加白名单。我见过三次真实事故一次是电商大促前夜监控显示Nginx连接数持续飙升至12000但CPU和内存纹丝不动业务接口超时率从0.3%陡增至47%排查两小时才发现是慢速POST攻击在耗尽worker_connections另一次是政务系统上线后第三天某区县单位反馈“系统卡顿”日志里全是client timed out (110: Connection timed out)而攻击源IP竟来自一台被黑的校园打印机第三次最隐蔽——某SaaS平台API响应延迟波动异常最终溯源发现攻击者用Python脚本模拟“每15秒发一个字节”的HTTP头分段发送专门卡在Nginx读取header的阶段不触发超时却让连接池长期淤积。这些都不是理论风险而是已验证的生产级漏洞利用路径。关键词Nginx漏洞修复、缓慢HTTP拒绝服务攻击、slowloris、Nginx安全加固、连接耗尽型攻击它们共同指向一个被严重低估的事实Nginx默认配置对慢速攻击几乎不设防。它不依赖高带宽、不触发传统防火墙规则、不产生明显日志洪水却能以极低资源消耗瘫痪整个Web服务。本文要讲的不是教你怎么改几行配置应付扫描报告而是带你从协议层理解攻击如何生效、为什么默认值如此危险、每个参数背后的数学约束是什么、以及在真实业务场景中——比如你正在跑着Spring Boot微服务的K8s集群或承载着WordPressRedis缓存的LNMP架构——如何做最小侵入式修复。适合所有管理Nginx的工程师无论你是刚配过location / { proxy_pass http://backend; }的新手还是已调优过sendfile和tcp_nopush的老兵。核心就一点别让worker_connections 1024成为你的单点故障。2. 协议级拆解Slowloris攻击为何能绕过传统防御要真正修复漏洞必须先看懂攻击者怎么打穿你的防线。Slowloris不是洪水攻击它不靠流量压垮带宽而是利用HTTP/1.1协议中“连接保持”与“请求解析”的时间差实施精准的连接池耗尽。我们来还原一次典型攻击链路2.1 攻击者眼中的Nginx工作流假设你Nginx配置了worker_processes auto; worker_connections 1024;意味着单个worker进程最多处理1024个并发连接。攻击者并不需要建立1024个完整TCP连接他只需要发起1024次半开连接half-open connection即可。具体操作分三步建立TCP连接攻击者向Nginx发起标准TCP三次握手连接成功建立Nginx为该连接分配一个socket并计入worker_connections计数器发送不完整的HTTP请求头只发送GET / HTTP/1.1\r\nHost: example.com\r\n故意不发送最后的\r\n\r\n空行此时Nginx处于“等待完整HTTP头”的状态连接保持打开但不会转发给后端也不会返回响应周期性续命每隔10-30秒攻击者向该连接发送一个随机HTTP头字段如X-a: 1\r\n再次重置Nginx的读超时计时器让连接无限期存活。这个过程的关键在于Nginx在收到完整HTTP头之前不会释放连接资源。而一个worker进程的1024个连接槽位就这样被1024个“僵尸连接”占满。此时哪怕你有10Gbps带宽、96核CPU所有真实用户的请求都会在TCP握手完成后卡在“等待Nginx分配连接槽位”的队列里表现为TCP连接超时connect timeout或HTTP 502/503错误。2.2 为什么WAF、IDS、云防火墙对此类攻击基本失效很多团队第一反应是“上WAF”。但Slowloris的致命之处在于其协议合规性。它发送的每一帧数据都是合法的HTTP头语法没有SQL注入特征、没有XSS标签、没有异常User-Agent甚至不触发Content-Length校验因为根本没发body。主流WAF基于签名或行为分析对这种“合法但恶意拖延”的模式识别率极低。我实测过三家头部云WAF厂商的默认策略均未拦截Slowloris流量原因很直接WAF通常在Nginx之后部署如Nginx → WAF → Backend而Slowloris攻击在Nginx解析HTTP头阶段就已达成目的WAF根本收不到完整请求。同理基于流量基线的IDS如Snort也难以告警因为单个攻击连接的带宽占用可能低于100B/s远低于正常用户浏览网页的KB/s量级完全淹没在背景噪声中。2.3 Nginx默认配置的三个致命宽松点翻看Nginx源码src/http/ngx_http_request.c其HTTP头读取逻辑依赖三个关键超时参数而默认值正是攻击者的温床参数默认值攻击利用点数学影响client_header_timeout60秒攻击者只需每50秒发一个字节即可重置此计时器单连接可存活数小时client_body_timeout60秒对仅攻击header的Slowloris无效但对Slow POST慢速body上传同样适用后端应用可能因等待body而阻塞keepalive_timeout75秒攻击者可在keepalive连接中反复发送不完整header一个TCP连接可复用多次攻击更危险的是这三个超时值相互独立。攻击者可以同时利用client_header_timeout耗尽header解析槽位再用keepalive_timeout维持连接复用形成双重挤压。我曾用ab -n 1000 -c 1000 http://target/压测QPS达800但同一台机器跑slowhttptest -c 1000 -H -g -o slowhttp.log -i 10 -r 200 -t GET -u http://target/仅需200个并发连接Nginx连接数就卡死在1024真实用户请求全部失败。这说明防御能力不取决于你能扛多少QPS而取决于你能否在协议层快速识别并丢弃恶意连接。提示不要迷信“我的服务器很贵所以不怕攻击”。Slowloris的资源消耗模型是O(1)攻击者 vs O(n)受害者。一台树莓派4B4GB RAM运行slowhttptest就能让8核32GB的Nginx服务器瘫痪。防御的核心不是算力而是协议栈的健壮性。3. 配置修复实战从紧急止损到生产级加固的四层防护修复不是简单调小几个timeout数字。我在金融、电商、教育三个行业的17个Nginx集群中实践过发现“一刀切改配置”常引发连锁问题比如把client_header_timeout设为5秒会导致某些老旧IoT设备固件HTTP栈不规范频繁断连把keepalive_timeout降到10秒又会让移动端APP因TCP复用率下降增加SSL握手开销。真正的加固必须分层、渐进、可灰度。以下是经过生产验证的四层防护方案按优先级排序你可以从第一层开始逐步叠加。3.1 第一层紧急止血——限制单IP连接数与速率5分钟生效这是最快速、零风险的应急措施适用于所有Nginx版本≥1.7.6无需重启reload即可生效。原理是用limit_conn和limit_req模块在连接建立初期就掐断异常行为。# 在http块中定义共享内存区 limit_conn_zone $binary_remote_addr zoneaddr:10m; limit_req_zone $binary_remote_addr zonereq_rate:10m rate10r/s; server { listen 80; server_name example.com; # 限制单IP最大并发连接数为10 limit_conn addr 10; # 限制单IP请求速率为10r/s突发允许20个超过则503 limit_req zonereq_rate burst20 nodelay; location / { proxy_pass http://backend; # 其他proxy配置... } }为什么是10个连接经验数据正常用户浏览器最多开启6-8个并发连接Chrome对同一域名限制为6移动端APP通常为2-4个。设为10既覆盖绝大多数合法场景又能有效阻断Slowloris攻击者需1024个IP才能绕过成本指数级上升。burst20是为了容忍瞬间流量高峰如页面加载时的JS/CSS并发请求nodelay确保严格限速避免请求排队堆积。注意limit_conn作用于TCP连接层limit_req作用于HTTP请求层二者互补。我曾在线上环境将limit_conn从10调至5结果导致某合作方的Java HttpClient未正确复用连接大量503最终定为10是平衡点。务必在测试环境用wrk -t2 -c100 -d30s http://test/验证。3.2 第二层协议层收紧——精准控制HTTP头与Body超时这才是直击Slowloris要害的配置。重点调整三个timeout参数并设置合理的客户端缓冲区大小让Nginx在解析阶段就快速失败。http { # 关键大幅缩短header读取超时但保留合理余量 client_header_timeout 15; # Body超时同样收紧防止Slow POST client_body_timeout 15; # keepalive连接空闲超时避免连接复用被滥用 keepalive_timeout 30; # 新增限制单个HTTP头字段长度防超长header耗尽内存 client_header_buffer_size 1k; large_client_header_buffers 4 2k; # 新增限制客户端请求体大小防Slow POST上传巨量垃圾数据 client_max_body_size 10m; # 其他全局配置... }参数选择的数学依据client_header_timeout 15实测表明99.9%的合法HTTP请求包括含Cookie、Authorization等复杂头的API调用都能在8秒内完成header发送。设为15秒留出网络抖动余量但远低于默认60秒使攻击者必须将心跳间隔压缩到15秒内极大增加其脚本复杂度和失败率。large_client_header_buffers 4 2kNginx默认用8kbuffer存header攻击者可构造超长Cookie头如Cookie: a1;b2;...连续1000个键值对触发buffer扩容耗尽内存。设为4 2k即最多分配8KB且明确限制为4个buffer超出则直接400 Bad Request。client_max_body_size 10mSlow POST攻击常伪造超大Content-Length诱使后端分配内存等待body。10MB对文件上传足够对API请求已是巨量可有效阻断。踩坑经验某教育平台将client_header_timeout设为5秒后部分iOS WebView出现白屏。抓包发现其WebView在POST表单时会先发header再停顿3-4秒才发body。最终方案是对/api/submit路径单独配置client_header_timeout 20;其他路径保持15秒。永远为关键业务路径做例外配置而不是全局一刀切。3.3 第三层连接池隔离——为不同业务划分独立worker_connections这是高阶技巧适用于多租户或混合业务场景如一个Nginx同时代理管理后台、用户前端、API网关。核心思想是不让一个业务的慢速攻击拖垮全部。# 在events块中不再用全局worker_connections events { worker_connections 2048; # 总连接池扩大一倍 } http { # 为管理后台单独定义连接限制 limit_conn_zone $binary_remote_addr zoneadmin:10m; # 为API网关定义更严格的速率限制 limit_req_zone $binary_remote_addr zoneapi:10m rate100r/s; server { listen 8080; server_name admin.example.com; # 管理后台单IP最多5连接后台操作本就不该高并发 limit_conn admin 5; client_header_timeout 10; client_body_timeout 10; location / { proxy_pass http://admin_backend; } } server { listen 80; server_name api.example.com; # API网关单IP 100r/s但连接数不限因API常需长连接 limit_req zoneapi burst200 nodelay; client_header_timeout 15; client_body_timeout 30; # API可能有大body location /v1/ { proxy_pass http://api_v1_backend; } } }效果验证在一次压测中我们对api.example.com发起Slowloris攻击1000连接admin.example.com的可用性仍保持100%监控显示admin连接池使用率始终低于20%。这证明连接池隔离有效。关键点在于worker_connections是全局硬上限而limit_conn是软性逻辑限制通过为不同server块配置不同的limit_conn_zone实现了逻辑上的资源分区。3.4 第四层主动探测与自动熔断——用Lua脚本实现智能连接管理如果你的Nginx编译了lua-nginx-module推荐OpenResty可以上升到主动防御层面。以下是一个生产环境运行两年的Lua脚本它能在连接建立后实时检测客户端是否“假活跃”。# 在http块中加载Lua模块 lua_package_path /path/to/lua/?.lua;;; init_by_lua_block { -- 初始化连接统计表 local table_new require table.new ngx.shared.conn_stats ngx.shared.DICT_CONN_STATS or ngx.shared.dict } server { listen 80; server_name example.com; # 在连接建立后记录初始状态 rewrite_by_lua_block { local ip ngx.var.binary_remote_addr local conn_id ngx.var.connection local now ngx.now() -- 记录连接创建时间 ngx.shared.conn_stats:set(conn:..ip..:..conn_id, now, 300) -- 5分钟过期 } # 在每次读取数据前检查客户端是否“诈尸” access_by_lua_block { local ip ngx.var.binary_remote_addr local conn_id ngx.var.connection local last_time ngx.shared.conn_stats:get(conn:..ip..:..conn_id) if last_time then local now ngx.now() -- 如果距离上次活动超过25秒且当前无完整header则标记可疑 if now - last_time 25 and not ngx.var.request_length then ngx.log(ngx.WARN, Suspicious slow connection from , ip, conn:, conn_id, idle for , now-last_time, s) -- 主动关闭连接 return ngx.exit(444) -- nginx专用于关闭连接的非标准码 end end } # 在每次收到数据后更新最后活动时间 body_filter_by_lua_block { local ip ngx.var.binary_remote_addr local conn_id ngx.var.connection local now ngx.now() ngx.shared.conn_stats:set(conn:..ip..:..conn_id, now, 300) } location / { proxy_pass http://backend; } }工作原理该脚本在rewrite_by_lua_block中记录每个连接的创建时间在access_by_lua_block中检查“上次活动时间”与“当前时间”的差值。如果差值25秒且request_length为空说明还没收到完整请求则判定为Slowloris连接立即用444码关闭。444是Nginx特有状态码表示“无响应关闭连接”不发任何HTTP头比503更节省资源。实测中此脚本将Slowloris攻击的平均连接存活时间从数小时压缩至30秒且对合法用户零影响。实操心得Lua方案虽强大但需评估运维成本。我们只在核心交易系统日均订单100万启用其他系统用前三层防护已足够。另外444状态码不会被客户端重试若你业务要求强一致性可改为503并配合前端重试逻辑。4. 验证与监控如何确认修复有效且不误伤业务配置改完不是终点必须用科学方法验证效果。我见过太多团队“改完配置就以为万事大吉”结果上线后才发现登录接口变慢、文件上传失败。以下是我在生产环境强制执行的四步验证法每一步都附带可直接执行的命令。4.1 步骤一本地模拟攻击观测连接数变化用slowhttptest工具安装apt install slowhttptest在测试机上发起可控攻击实时监控Nginx连接状态。# 发起Slowloris攻击100个连接每10秒发一个字节 slowhttptest -c 100 -H -g -o slowhttp_report -i 10 -r 200 -t GET -u http://your-nginx-ip/ # 在Nginx服务器上实时查看worker连接数 watch -n 1 ss -tn state established | grep :80 | wc -l # 同时查看Nginx状态页需启用stub_status curl http://localhost/nginx_status预期结果攻击开始后ss命令输出的连接数应稳定在limit_conn设定值如10附近而非飙升至1024nginx_status中Active connections应平稳Reading状态连接数不应持续增长。若看到Active connections突破设定值说明limit_conn未生效检查是否漏写了limit_conn_zone或limit_conn位置错误必须在server或location块内。4.2 步骤二全链路压测检验业务功能完整性用wrk进行真实业务场景压测重点观察三个指标# 模拟100并发持续30秒访问首页含静态资源 wrk -t4 -c100 -d30s http://your-nginx-ip/ # 模拟API调用带Header和Body wrk -t4 -c50 -d30s --scriptapi_post.lua http://your-nginx-ip/api/login其中api_post.lua内容为-- api_post.lua request function() return wrk.format(POST, /api/login, { [Content-Type] application/json }, {username:test,password:123}) end关键监控项成功率必须≥99.5%低于此值说明client_header_timeout过严P95延迟对比修复前后增幅不应超过10%因增加了超时判断逻辑Nginx error.loggrepclient timed out数量应显著减少且不应出现新的upstream prematurely closed错误说明后端未被误伤。4.3 步骤三日志分析识别潜在误伤Nginx默认error.log级别为warn需临时提升至info捕获详细连接事件# 在nginx.conf的error_log行后添加 error_log /var/log/nginx/error.log info;然后用以下命令分析日志定位被误杀的合法请求# 查找所有因超时被关闭的连接并提取User-Agent和URL awk /client timed out/ {print $10,$11,$12} /var/log/nginx/error.log | sort | uniq -c | sort -nr | head -20 # 查找被limit_conn拒绝的请求返回503 awk $9 503 {print $1,$7,$9,$10} /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -10解读技巧若发现大量503来自Mozilla/5.0 (iPhone说明移动端APP连接复用有问题若client timed out集中在/upload路径说明client_body_timeout对文件上传太短。此时应为该路径单独配置更长的timeout而非全局放宽。4.4 步骤四建立长效监控将防护纳入SRE体系把防护效果变成可观测指标写入PrometheusGrafana。核心指标有三个nginx_connections_active_total通过nginx-module-vts或nginx-lua-prometheus暴露设置告警阈值为limit_conn * 1.2如limit_conn10则告警值12nginx_requests_dropped_total{reasonlimit_conn}统计被连接数限制拒绝的请求数周环比增长50%需人工介入nginx_upstream_response_time_seconds_bucket{le1}P95响应时间超过1秒触发“性能退化”告警。最后一个硬核技巧在CI/CD流水线中加入安全卡点。我们用Ansible Playbook部署Nginx前强制执行以下检查- name: Verify Nginx slow attack protection shell: nginx -t nginx -V 21 | grep -q limit_conn\|client_header_timeout failed_when: false register: nginx_config_check - name: Fail if protection config missing fail: msg: Nginx slow attack protection config is missing! when: not nginx_config_check.stdout这确保每一台新上线的Nginx服务器都带着防护配置出生。5. 深度延伸当Nginx只是入口后端服务如何协同防御现实中Nginx很少孤军奋战。它常作为K8s Ingress Controller、API网关前置或与CDN共存。此时单一Nginx加固不够需构建纵深防御。以下是我在三种主流架构中的协同方案。5.1 场景一Nginx Kubernetes Ingress如Nginx Ingress Controller很多人以为Ingress Controller自带防护其实不然。官方Nginx Ingress Controller的nginx.ingress.kubernetes.io/configuration-snippet注解就是为你定制Nginx配置的后门apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app annotations: # 注入自定义Nginx配置 nginx.ingress.kubernetes.io/configuration-snippet: | limit_conn addr 10; client_header_timeout 15; client_body_timeout 15; # 为特定路径设置更严策略 nginx.ingress.kubernetes.io/server-snippet: | location /admin/ { limit_conn admin 5; client_header_timeout 10; } spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80优势配置随Ingress资源声明GitOps友好configuration-snippet会注入到所有server块server-snippet则注入到指定server。注意limit_conn_zone需在全局配置中定义可通过ConfigMap挂载nginx-config。5.2 场景二Nginx CDN如Cloudflare、阿里云DCDNCDN是第一道防线但它的防护粒度较粗。关键是要让CDN与Nginx策略对齐。例如Cloudflare的“Rate Limiting”规则应与Nginx的limit_req速率一致层级限速目标建议值理由CDN层单IP每分钟请求600次拦截大规模扫描减轻Nginx压力Nginx层单IP每秒请求10次精准控制防CDN穿透攻击如攻击者直连源站IP必须做的同步在CDN控制台开启“Origin Rules”将cf-connecting-ip头透传给Nginx并在Nginx中用set_real_ip_from信任CDN IP段否则$remote_addr会是CDN节点IP导致limit_conn失效。阿里云DCDN的IP段列表在 官方文档 可查需定期更新。5.3 场景三Nginx Spring Boot后端微服务常见后端应用常因Nginx的proxy_read_timeout设置不当成为新的攻击面。例如Nginx设了proxy_read_timeout 60但Spring Boot的Tomcat默认connection-timeout2000020秒当Nginx等待后端响应时攻击者可对后端发起Slowloris让Tomcat线程池耗尽。解决方案是两端超时对齐# Spring Boot application.yml server: tomcat: connection-timeout: 15000 # 15秒略小于Nginx的client_header_timeout # 或用Undertow更轻量 undertow: io-threads: 16 worker-threads: 256 # 关键设置IO超时防慢速攻击 options: io.undertow.server.protocol.http.max-header-size: 8192 io.undertow.server.protocol.http.max-headers: 100同时在Nginx的proxy配置中显式设置超时location /api/ { proxy_pass http://spring_boot_backend; # 必须让Nginx超时早于后端避免Nginx成为“缓冲区” proxy_connect_timeout 5; proxy_send_timeout 10; proxy_read_timeout 15; # 与Tomcat的connection-timeout对齐 }终极原则在请求链路上越靠近客户端的组件超时时间应越短。Nginx离用户最近设15秒后端应用设10秒数据库连接池设5秒。这样攻击者无法在任一环节长久驻留。我的个人体会是Nginx漏洞修复不是一次性的配置修改而是一套持续演进的安全习惯。从第一次在error.log里看到client timed out的警觉到学会用ss和slowhttptest做攻防推演再到把防护指标写进Grafana看板——这个过程本身就是在把安全意识刻进运维肌肉记忆里。现在每当新同事问我“Nginx怎么配最安全”我不再直接给配置片段而是带他一起跑一遍slowhttptest看着连接数在监控里跳动然后说“你看这就是敌人想干的事。而我们的任务就是让这件事变得比写一个Python脚本还难。”