一、引言
上一篇我们讲了 DDoS 攻击（分布式拒绝服务），它像 "洪水" 一样用海量流量把服务器冲垮。但有一种攻击更 "阴险"：它流量不大、请求看似正常，却能悄无声息地把网站拖垮 ------ 这就是 CC 攻击。
很多站长遇到过这样的困惑："我的服务器带宽明明没满，网站却打不开，后台 CPU 直接飙到 100%，这到底是怎么回事？" 答案往往就是 CC 攻击。
那么 CC 攻击到底是什么？它为什么这么难防？本文带你一次看懂。
二、什么是 CC 攻击？
CC 攻击 的全称是 Challenge Collapsar（挑战黑洞）。这个名字起源于一款名为 Collapsar 的抗 DDoS 设备，因为这种攻击专门 "挑战" 这款设备，故而得名。
从本质上说，CC 攻击是 DDoS 攻击的一种应用层（L7）变种 。与直接灌流量的 "暴力" 攻击不同，CC 攻击模拟的是 大量真实的正常用户：
- 它不会发送畸形的、明显的攻击数据包；
- 它的请求在协议层面完全 "合法"；
- 它攻击的不是带宽，而是 服务器的应用资源------CPU、内存、数据库连接、处理线程等。
一句话概括：CC 攻击就是用 "看起来完全正常的请求"，把服务器的处理能力耗尽。
三、CC 攻击的原理
要理解 CC 攻击，先要知道一个基本事实：一个网站能同时处理的 "活跃请求" 是有限的。
正常用户访问时，服务器需要：
- 接收请求；
- 读取数据库 / 调用接口；
- 生成页面返回给用户。
每一个请求都会短暂占用一个处理线程、一部分内存、一条数据库连接。服务器同一时刻能处理的请求数是固定的（比如 100 个并发），一旦超过，后面的请求就只能排队，排队久了就超时、卡死。
CC 攻击的原理，就是制造海量 "看似真实" 的并发请求，把这些处理线程、数据库连接全部占满，让真正的用户挤不进来：
攻击者（C&C）
│ 下发指令
┌──────┼──────┐
肉鸡1 肉鸡2 ... 肉鸡N
│ │ │
│ 海量"正常"HTTP请求 │
└───────┬─────────┘
┌──▼──┐
│ Web服务器 │
│ 线程/内存/连接│
│ 全部占满 │ → 合法用户无法访问
└─────┘
3.1 为什么难识别？
这是 CC 攻击最 "恶心" 的地方：
- 来源分散：来自成百上千个不同的 IP，封一个 IP 无济于事；
- 请求合法：是标准的 HTTP GET/POST 请求，流量特征与正常用户几乎无法区分；
- 流量不大 ：单个请求很小，不像 UDP 洪水那样瞬间占满带宽，因此传统的流量清洗设备常常 "看不见" 它。
四、CC 攻击与 DDoS 的区别
|------|------------------|--------------|
| 对比项 | 传统 DDoS（流量洪水） | CC 攻击 |
| 攻击层级 | 网络层 / 传输层（L3/L4） | 应用层（L7） |
| 攻击对象 | 带宽、连接表 | 应用进程、CPU、数据库 |
| 流量特征 | 流量巨大、特征明显 | 流量不大、伪装正常 |
| 识别难度 | 相对容易 | 极难，易被误认为正常流量 |
| 防御方式 | 流量清洗、黑洞 | 限流、WAF、人机识别 |
五、CC 攻击的常见手法
5.1 直接请求型
攻击者控制大量肉鸡，直接向目标网站高频发起正常请求（访问首页、轮询接口、反复查询），用最朴素的方式耗尽资源。这是最常见的形式。
5.2 慢速攻击型（Slowloris / 慢速 POST）
这类攻击更 "狡猾"，不靠数量，靠 "拖延"：
- Slowloris ：与服务器建立连接后，故意缓慢地、一点一点地发送请求头，让服务器一直 "吊着" 等待完整请求，从而占满所有空闲连接，使新连接无法建立。
- 慢速 POST：缓慢上传请求体（body），长时间占用服务器的处理线程。
5.3 定向打击型
攻击者针对网站的高消耗接口发起攻击，例如：
- 频繁触发复杂的数据库查询（如全表搜索）；
- 大量调用耗时的业务接口（如生成报表、发送验证码）；
- 反复请求需要消耗大量计算的功能（如图片处理、加密）。
这种攻击往往 "小流量、大伤害"，一个请求就能顶普通请求几十倍的消耗。
六、如何识别 CC 攻击？
遭遇 CC 攻击时，通常会出现这些特征：
- 带宽不高，但 CPU / 内存使用率异常飙升；
- 网站响应变慢、出现大量超时或 502 错误；
- 后台日志出现大量不同 IP 的、重复性很高的请求；
- 数据库连接数、处理线程数被打满；
- 有些请求 "只发不发完"（慢速攻击特征）。
可以通过 Nginx 日志快速排查（Linux）：
# 统计访问次数最多的前 10 个 IP，攻击往往来自少数高频 IP
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10
# 查看当前服务器线程数 / 连接状态
ss -ant | awk '{print $1}' | sort | uniq -c | sort -n
注意：真实的 CC 攻击来源分散、请求 "合法"，靠日志人工排查往往滞后，需要专业的防护手段。
七、如何防御 CC 攻击？
CC 攻击的核心是 "伪装成正常用户"，所以防御的关键在于区分 "真用户" 和 "机器请求"。
7.1 限流（Rate Limiting）------ 最基础的手段
- 对单个 IP 设置访问频率上限（如每秒 N 次）；
- 对单个会话 / 账号设置调用配额；
- 对高消耗接口单独限流，防止被 "定向打击"。
示例：Nginx 简单限流
# 定义请求限制：每个 IP 每秒最多 10 次请求
limit_req_zone $binary_remote_addr zone=cc:10m rate=10r/s;
server {
location / {
limit_req zone=cc burst=20 nodelay;
# ... 其他配置
}
}
7.2 人机识别 ------ 验证码与行为分析
- 对高频访问或异常请求 弹出验证码（滑块、图形、行为验证）；
- 引入人机识别 / 风控引擎，通过 Cookie、浏览器指纹、行为轨迹判断 "真人" 还是 "脚本"。
这是对抗 CC 攻击最有效的手段之一，因为机器很难通过真人验证。
7.3 WAF（Web 应用防火墙）------ 精准拦截
- 使用 WAF 规则识别并拦截恶意特征（如异常 UA、畸形请求、高频 IP）；
- 结合IP 信誉库，对来自已知攻击源的流量直接拦截；
- 配合CC 防护策略，自动对可疑 IP 触发限流或验证码。
7.4 架构层面的 "躲"
- CDN 加速：将业务分布到多个节点，隐藏源站 IP，分散攻击流量；
- 源站 IP 保密：确保真实服务器 IP 不暴露（否则攻击者可绕过 CDN 直打源站）；
- 服务降级：对不重要的功能（如推荐、评论）做降级处理，保住核心业务。
7.5 防御手段对比
|------------|----------|----------|---------------|
| 手段 | 作用 | 优点 | 局限 |
| 限流 | 限制请求频率 | 成本低、见效快 | 可能误伤正常用户 |
| 验证码 / 人机识别 | 区分真人与脚本 | 拦截效果最直接 | 影响用户体验 |
| WAF | 精准拦截恶意请求 | 自动化、规则可调 | 对 "合法伪装" 仍有漏网 |
| CDN + 源站保密 | 分散流量、藏源站 | 架构层面兜底 | 需整体规划 |
八、总结
一句话概括：CC 攻击是利用 "大量看似正常的应用层请求"，耗尽服务器处理资源，让合法用户无法访问的一种 DDoS 变种。
它不靠大流量取胜，靠的是 **"伪装成真人 + 来源分散"**，所以比传统 DDoS 更难识别、更难防御。防 CC 攻击没有银弹，核心思路是：
- 藏好源站 IP（防止被绕过）；
- 多层限流 + 人机识别（逼退机器请求）；
- 接 WAF + CDN（让专业团队帮你扛）；
- 监控告警 + 预案演练（第一时间发现并响应）。
面对伪装成 "真人" 的机器，最好的防御不是硬扛，而是让它 "验明正身"。
如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你遭遇 CC 攻击的经历和应对经验！