一、CC 攻击为什么难防
CC 攻击（Challenge Collapsar，挑战黑洞）属于应用层拒绝服务攻击。它的狡猾之处在于——每一个请求单独看都是完全正常的。
对比一下两种攻击：
| 对比项 | 流量型 DDoS | CC 攻击 |
|---|---|---|
| 攻击目标 | 带宽被占满 | 服务器计算资源被耗尽 |
| 请求特征 | 异常流量，一眼可辨 | 与正常请求无异 |
| 防御手段 | 流量清洗 | 频率分析 + 行为识别 |
| 典型表现 | 网站打不开（网络不通） | 网站打不开（服务器卡死） |
因为请求本身合法，传统基于「攻击特征」的防护手段基本失效。WAF 防 CC 依靠的不是「识别攻击特征」，而是识别异常的访问模式。
二、WAF 识别 CC 的四个维度
1. IP 频率
统计同一 IP 在单位时间内的请求次数。正常人浏览网站的节奏是可以预期的（几秒一个页面），而攻击工具会以极高的频率发起请求。
但要注意：单看 IP 频率容易误判——公司出口 NAT、公共 WiFi 会共享 IP，正常用户也可能触发高频。所以这一维度通常需要配合其他维度使用。
2. URL 频率
这个维度更精准。CC 攻击的特点是集中打某个消耗资源的接口，比如：
- 搜索页
/search?q=xxx——每次查询都走数据库模糊匹配； - 列表页的翻页参数——深度分页性能极差；
- 动态接口——需要复杂计算或多次查询。
如果某个 URL 在短时间内被高频调用且来源分散，是 CC 攻击的典型信号。
3. 并发连接数
攻击者可能用少量 IP 建立大量并发连接，保持连接不释放，耗尽服务器的连接池。单看频率可能不高，但并发数异常。
4. 行为特征
更高阶的识别方式。正常人访问网站有相对固定的模式：先访问首页，再点进栏目，停留一段时间，页面之间有跳转关系。而攻击工具往往：
- 只反复请求同一个接口，不加载其他资源；
- 访问间隔极其规律（机械式固定频率）；
- 没有任何鼠标轨迹与滚动行为；
- 不携带正常的 Referer 和 Cookie。
三、WAF 的四类处置手段
| 手段 | 适用场景 | 用户体验影响 |
|---|---|---|
| 频率限制（限速） | 轻度异常、疑似误判 | 几乎无感，仅限制超出的部分 |
| JS 挑战 | 需要验证是否为真实浏览器 | 首次访问略有延迟 |
| 滑块验证 | 高置信度的可疑流量 | 需要人工交互，会对正常用户造成干扰 |
| 直接封禁 IP | 明确的攻击源 | 无感，但需注意误封风险 |
合理的策略是分级处置：先限速，再挑战，最后才封禁。这样对正常用户的影响最小。
四、阈值怎么设才合理
原则一：按业务实际流量设定
不要照搬网上的数值。一个日均 IP 100 的博客，和一个日均 10 万的电商站，合理阈值完全不同。建议做法是：先看自己站点的正常峰值，再在其基础上留 2-3 倍余量。
原则二：先宽松，再收紧
上线初期建议先用观察模式，让 WAF 记录但不禁用请求，观察几天日志，确认阈值是否合理，再切换到拦截模式。
原则三：分类设置
| 资源类型 | 阈值建议 |
|---|---|
| 静态资源（图片/CSS/JS） | 可放宽，正常加载会产生较多请求 |
| 普通页面 | 按正常浏览节奏设定 |
| 搜索、列表等重接口 | 从严，这是 CC 最常打的目标 |
| 登录、支付等敏感接口 | 最严，同时配合验证码 |
五、遇到 CC 攻击时的处置流程
- 确认是攻击还是真实流量激增——先看流量来源分布，如果高度集中可疑，如果分散均匀可能是推广带来的真实增长；
- 定位被打的接口——从日志找出请求量最高的 URL；
- 针对性加固——对该接口单独设置更严的频率限制；
- 升级处置等级——必要时开启 JS 挑战或滑块；
- 事后优化——检查该接口是否可缓存、是否有更高效的实现方式。
六、小结
CC 攻击靠「数量」取胜，防御的核心是从访问模式中发现异常。WAF 提供了 IP 频率、URL 频率、并发连接、行为特征四个识别维度，以及限速、挑战、封禁三档处置手段。关键在于阈值合理 + 分级处置——既能挡住攻击，又不误伤真实用户。
