一、你遇到过“趴窝”的网站吗？
配置前的检查
WAF CC看似简单，真正落地时却很容易踩坑。明明后台显示CPU使用率不到30%，带宽也没有被打满，但用户就是打不开页面——点一下等10秒，刷新后超时。这时候你查日志，发现既没有海量IP请求，也没有大体积报文。传统CC攻击那种“洪水猛兽”式的特征一个都不像。
你可能遇到了另一种更难缠的攻击：低频协同CC攻击（Low-rate DoS）。它不靠数量，靠节奏；不靠速度，靠协同。这篇文章专门写给非安全专业的技术或站长，帮你理解这类攻击到底是什么，以及为什么“边缘节点的WAF”能智能识别并动态压制它。
二、先搞懂：普通的CC攻击怎么防？
故障定位思路
经典的CC攻击（Challenge Collapsar）其实就是“应用层DDoS”。攻击者控制大量僵尸或者肉鸡，同时向目标网站发起看似正常的HTTP请求（比如GET首页、登录接口）。
传统WAF的防御逻辑很直接：
- 频率阈值：单个IP在单位时间内请求超过N次，直接拉黑或限速。
- 并发连接数：单个IP同时打开的TCP连接超过M个，直接断开。
- 特征指纹：User-Agent、Referer、Cookie等字段批量重复则拦截。
这套规则能挡住90%的低级攻击，因为它依赖“峰值”和“量变”。但低频协同攻击恰恰是反其道而行之。
三、低频协同CC攻击：慢到让你误以为是正常用户
配置前的检查
Low-rate DoS（也称“慢速攻击”“分布式低频攻击”）的核心思想是：不触发阈值，但累积效果却能耗尽服务器资源。
- 每个攻击源只发少量请求：比如一个傀儡机器每秒只发1~2个请求，甚至每隔几秒才发一次，远低于正常爬虫或普通用户的访问频率。
- 大量源协同行动：几千个IP各自缓慢请求，但加起来的总请求量依然很高。由于每个IP的请求频率都“合法”，传统单IP阈值规则完全失效。
- 攻击目标往往是“慢消耗”资源：比如一个需要数据库查询的接口，或者一个会触发大量PHP计算的页面。每个请求都让服务器多付出一点CPU/内存，累积起来就让服务器逐渐变慢。
这种攻击在日志里看起来就像“突然来了一波真实用户”。如果没有全局视角，你甚至找不到异常点。
四、为什么普通WAF防不住？两个关键盲区
盲区一：统计窗口太短
传统WAF通常按秒或分钟统计IP请求数。攻击者把请求分散到5分钟甚至更长的时间窗口内，每个IP的单窗口请求量就降到正常范围。比如一个真实用户每分钟访问10个页面，攻击者让每个IP每分钟只发3~5个，完全混入正常流量。
盲区二：无法关联“慢速突增+分布式
即使某个IP不过量，但从全局看突然有1000个新IP在同时访问同一个URL，而且访问节奏高度一致，这本身就是一个强信号。但传统WAF缺乏跨边缘节点的协同能力，每个节点只看到自己的一亩三分地，无法聚合判断“协同”行为。
想继续深入：此处可内链到“WAF CC优化清单”文章。
关联教程：此处可内链到“WAF CC部署与验证”内容。
五、边缘节点+智能识别：从“单点防”到“全网感知”——WAF CC
基于WAF边缘节点来防御低频协同攻击，本质上是在每个CDN/WAF节点上部署轻量级的流数据采集器，并通过中心大脑进行实时聚合分析。这套方案的关键分三步：
第一步：边缘节点实时采集“微特征”
每个边缘节点不只记录“来自哪个IP、什么时间、请求哪个URL”，还记录更细的维度：
- 请求间隔分布：对于同一个IP，记录每次请求之间的时间间隔（毫秒级）。规律性极强的间隔（如固定1.5秒）往往是脚本特征。
- 请求路径收敛性：如果一个IP反复请求同一个URL，而且时间间隔几乎不变，属于异常。
- 连接保持时长：低频攻击常使用长连接，发送完请求后不立即关闭，缓慢占用连接池。
这些特征在单个节点上可能微不足道，但汇总后就能形成全局画像。
第二步：中心大脑做“协同相关性分析”
中心大脑将几个参数聚合计算：
- 时间切片内的“新奇IP比例”：过去5分钟内，有多少IP是之前从未出现过的？如果突然从10%飙升到80%，且这些IP的请求间隔高度一致，基本可以判定是低频协同攻击。
- 请求目标的收敛度：如果多个边缘节点上报的异常IP都集中在同一个URL（比如 /api/order），则锁定该URL为被攻击目标。
- 速率波动模式：低频攻击常采用“起伏”模式——突然增加一批慢速IP，过几分钟后这批IP隐退，另一批IP继续。这种模式跟真实用户流量的随机性完全不同。
这些分析不需要深度学习，用滑动窗口+统计学方法就能实现低延迟判定。
第三步：动态流控——不封IP，只削峰
传统思路是直接封禁可疑IP，但这对于低频攻击问题很大：一来误杀率高（可能封到真实用户），二来攻击者可以随时换IP。所以更聪明的做法是动态流控（Dynamic Rate Limiting）：
- 针对被攻击的URL做分级限速：例如，正常时允许每秒1000次请求，检测到低频率协同后，将该URL的全局速率上限降到300次/秒。超出的请求返回503或触发验证码。
- 对可疑IP做“延迟惩罚”：不封禁，但人为增加200ms延迟，不影响真实用户（200ms几乎不可感知），但会打乱攻击脚本的节奏。攻击者可能需要不断调整脚本，增加攻击成本。
- 白名单保护关键API：对核心业务接口设置更严格的白名单规则，仅允许某些认证后的用户访问，进一步降低攻击影响范围。
相关阅读：此处可内链到“WAF CC常见问题”专题。
六、一个简化流程对照表
先看关键判断
| 攻击阶段 | 边缘WAF行为 | 效果 |
|---|---|---|
| 正常流量 | 直接放行，不干预 | 低延迟 |
| 低频协同刚开始（新奇IP比例突增） | 中心大脑发出预警，边缘节点开始采集更细粒度的特征 | 无用户感知 |
| 确认低频协同攻击（收敛度高+间隔规律） | 自动触发动态流控：目标URL限速，可疑IP延迟惩罚 | 攻击方效率下降，真实用户几乎无感 |
| 攻击持续升级（IP池巨大） | 边缘节点自动扩大流控范围，结合验证码进一步过滤 | 服务器CPU保持稳定，SLA不受影响 |
WAF CC：七、核心优势：不依赖“完美特征”
配置前的检查
传统WAF防不住低频协同攻击，本质上是试图用“局部、短时”的特征去判断“全局、长时”的行为。基于边缘节点智能识别最大的改变，是把分析窗口从“单点单秒”扩展到“全网分钟级”甚至“小时级”。
即使攻击者每次只发一个请求，只要几千个IP在5分钟内对同一个URL的行为模式高度相似，系统就能通过相关性分析抓出来。而且动态流控不需要精确识别每个IP是否为恶意——只对可疑群体做整体限速，误杀概率极低。
八、给站长的实操建议：如何提前防护？
配置前的检查
- 确认你的WAF是否支持“边缘流聚合”功能。不是所有CDN/WAF都能做跨节点的协同分析，很多只是简单的单节点限速。需要明确询问厂商。
- 开启慢速攻击防护模块。大多数专业的WAF（如雷池、Cloudflare、AWS WAF等）有专门的“Slowloris/Low-rate DoS防护”，本质就是上述智能识别+流控的简化版。
- 不要完全依赖默认阈值。低频攻击通常需要更长的统计窗口（如60秒、300秒），建议调大单IP的统计周期，但配合“全局新奇IP比例”阈值来触发防御。
- 定期做压力测试。用工具模拟低频协同场景（如使用Hping3或自定义脚本），测试WAF是否能在真实流量中准确识别并保护业务。
补充参考：此处可内链到“WAF CC故障排查实例”。
总结
配置前的检查
低频协同CC攻击是“温水煮青蛙”式的威胁，它利用传统WAF的统计盲区，让服务器在不知不觉中资源耗尽。而基于WAF边缘节点的智能识别+动态流控，通过“边缘采集+中心关联+整体限速”的思路，在不影响用户体验的前提下，有效压制了这类慢速攻击。对运维人员来说，理解这个原理比记住具体操作更重要——因为攻击手法会变，但“全局看行为”的防御思想不会过时。按这个顺序复查，WAF CC遇到异常时也更容易定位。
延伸阅读