探讨自建高防 CDN 应对应用层分块传输编码（Chunked）攻击的拦截
摘要：# 当Chunked攻击遇上自建高防CDN：一场“慢刀子割肉”的攻防战 说真的，我第一次在流量监控里看到那种“慢悠悠”的异常请求时，差点以为是自己眼花了。 不像那种洪水般的DDoS，一上来就让你服务器直接宕机。这种用Chunked传输编码发起的攻击，更…
当Chunked攻击遇上自建高防CDN：一场“慢刀子割肉”的攻防战
说真的，我第一次在流量监控里看到那种“慢悠悠”的异常请求时，差点以为是自己眼花了。
不像那种洪水般的DDoS，一上来就让你服务器直接宕机。这种用Chunked传输编码发起的攻击，更像是在你系统上开了个“滴水穿石”的口子——请求看起来都挺正常，每个数据块都符合规范，但就是拖着你，一点一点地消耗你的连接资源，直到你的应用服务器彻底“累趴下”。
很多所谓的高防方案，PPT上吹得天花乱坠，真遇到这种“阴柔”打法，可能连告警都触发不了。为啥？因为单看每个请求，它都太“合规”了。
一、Chunked攻击：披着羊皮的“连接杀手”
咱们先别扯那些复杂的RFC标准。说白了，分块传输编码（Chunked Transfer Encoding）本来是个好东西，设计出来就是为了在不知道内容总长度时，能一边生成数据一边发送。你在浏览器里慢慢下载一个大文件，后台用的可能就是这种机制。
但攻击者把它玩坏了。
他们是怎么干的？想象一下这个场景：
攻击程序建立一个到你的Web服务器的连接，然后开始发送HTTP请求头，告诉服务器：“我要用分块的方式给你发数据啦。”接着，它开始发送数据“块”——但每个块之间，它故意等上几十秒，甚至几分钟。在这漫长的等待期间，你的服务器线程或连接资源就被这个“合法”的连接死死占着，动弹不得。
更绝的是，攻击者可以同时发起成千上万个这样的“慢连接”。你的服务器连接池很快就被这些“僵尸连接”占满，真正的用户请求反而挤不进来。
这种感觉，就像你去银行办业务，结果前面排了100个人，每个人到了柜台都不说话，就在那儿干坐着——柜员还不能赶他们走，因为理论上他们“正在办理业务”。
二、自建高防CDN的“软肋”在哪？
我自己折腾过几套自建高防方案，也帮不少客户排查过问题。发现一个挺普遍的现象：很多自建高防CDN，对付SYN Flood、UDP Flood这种流量型攻击还行，但面对应用层的“精细化”攻击，特别是像Chunked攻击这种，防护逻辑就有点跟不上了。
问题往往出在这几个地方：
- 默认规则“看不见”：很多开源的WAF或者防护模块，默认规则集主要防SQL注入、XSS这些。对于协议合规但行为异常的Chunked请求，它们可能直接就放行了。
- 超时配置太“宽容”：为了兼容一些老旧的客户端或者慢速网络，后端服务器（或者反向代理）的连接超时、读取超时时间往往设得比较长，比如60秒、120秒。这在平时没问题，但正好给了Chunked攻击可乘之机。
- 资源消耗监控滞后：等监控系统发现服务器连接数爆满、CPU飙升时，业务可能已经受影响好几分钟了。这种攻击的“温水煮青蛙”效应，特别考验实时检测的灵敏度。
我见过最离谱的一个案例，客户用了某大厂云的高防IP，但源站是自己搭的Nginx集群。云高防把明显的流量攻击都拦了，可就是没防住这种“慢速”的Chunked攻击，最后是源站的Nginx因为worker_connections耗尽先挂了。你说冤不冤？
三、怎么让自建高防CDN“支棱”起来？
别慌，办法总比问题多。既然知道了攻击的原理和防护的短板，咱们就能有针对性地加固。这里分享几个我觉得比较实用的思路，有些甚至不用花什么钱。
思路一：在边缘节点“掐断”异常慢连接
自建CDN的入口节点（比如用Nginx、OpenResty做的反向代理）是第一道防线，这里必须设置严格的“行为规则”。
- 缩短超时时间：在Nginx配置里，把针对客户端的
client_header_timeout、client_body_timeout调低。对于正常的用户请求，5-10秒完全够了。如果有人在10秒内连个请求头都没发全，那大概率有问题，直接返回408（Request Timeout）并关闭连接。# 在http或server块中设置 client_header_timeout 10s; client_body_timeout 10s; - 限制单个连接速率：用
limit_rate和limit_rate_after指令。比如，允许连接建立后快速传输前512KB，之后如果传输速度低于某个阈值（比如10KB/s），就认为它可能在拖时间，进行限速或断开。# 针对特定location或全局 limit_rate_after 512k; # 前512KB不限速 limit_rate 10k; # 之后限制为10KB/秒 - 识别异常的Chunked行为：这需要点定制开发。可以用OpenResty的Lua脚本，在
access_by_lua*阶段写逻辑。核心是监控请求体传输的“节奏”：如果一个请求声明了Transfer-Encoding: chunked，但数据块之间的间隔时间异常地长且规律，或者总传输时间远超其数据量应有的时间，就可以标记或拦截。-- 伪代码思路 local start_time = ngx.now() -- 在body_filter阶段监控数据到达间隔 -- 如果平均间隔超过阈值（如5秒），则记录日志并可能采取行动
思路二：用好“连接数”和“请求频率”这两把锁
Chunked攻击的本质是耗尽连接。那我们就在连接数上做文章。
-
按IP限制连接数和请求率：在Nginx里用
limit_conn_zone和limit_req_zone模块。这是成本最低、效果最显著的防护手段之一。http { limit_conn_zone $binary_remote_addr zone=per_ip_conn:10m; limit_req_zone $binary_remote_addr zone=per_ip_req:10m rate=10r/s; server { location / { limit_conn per_ip_conn 20; # 单个IP同时最多20个连接 limit_req zone=per_ip_req burst=20 nodelay; # 限流 # ... 其他配置 } } }注意：对于公网IP少的攻击源，这招很管用。但如果对方用海量代理IP（僵尸网络），效果会打折扣，需要结合其他手段。
-
设置全局连接数上限：确保你的Nginx
worker_processes*worker_connections总值，略高于你业务正常峰值的需求，但又不能无限大。给系统资源设个“天花板”，防止被彻底拖垮。
思路三：主动监测与联动封禁
防护不能只靠被动规则，还得有“眼睛”。
- 监控关键指标：别只盯着带宽和QPS。重点监控活跃连接数、请求平均持续时间、后端服务器响应时间。如果发现连接数异常高，但带宽和QPS没怎么涨，同时请求持续时间长得离谱，就要立刻警惕是不是遭遇了慢速攻击。
- 建立动态黑名单：通过脚本分析访问日志，自动找出那些“平均请求时间超长”或“建立了大量空闲连接”的IP，动态地加入到Nginx的
deny列表，或者通过API推送到边缘防火墙/路由器进行封禁。 - 考虑引入“挑战”机制：对于疑似攻击的连接，可以在边缘节点插入一个轻量级的验证，比如一个简单的JS计算挑战，或者一个验证码。正常的浏览器客户端能轻松通过，而大多数简单的攻击脚本就会卡住。这招对付一些自动化工具特别有效。
四、几句大实话和心里话
搞自建高防CDN，听起来很酷，能控成本、有灵活性，但说实话，维护成本和心智负担一点也不小。尤其是面对这些层出不穷的应用层攻击变种。
- 没有银弹：上面说的这些方法，组合使用效果才好。单靠任何一招，都可能被绕过。
- 测试！测试！还是测试！ 规则配好了，一定要用工具（比如
slowhttptest）模拟攻击一下，看看你的防护到底生不生效。别等到真被打的时候才抓瞎。 - 源站别“裸奔”：就算前面有高防CDN，源站服务器自身的基础安全加固和连接限制也要做。多层防护，心里不慌。
- 评估成本与收益：如果业务非常关键，攻击又特别频繁和复杂，有时可能真不如直接采购成熟的商业高防服务省心。自建的优势是深度定制，劣势是得自己扛下所有运维和攻防对抗的细节。
防护这事儿，本质上是一场攻防双方的成本博弈。我们的目标不是造一个绝对攻不破的堡垒，而是把攻击者的成本抬得足够高，高到他们觉得打你不划算，转而去寻找更“软”的柿子。
行了，关于自建高防CDN怎么防Chunked攻击，我能想到的实战经验差不多就这些了。这玩意儿技术细节多，坑也多，但理清了脉络，一层一层去加固，至少能让你睡得踏实点。
你的源站，现在还敢对Chunked请求“来者不拒”吗？