课程笔记：CC（Challenge Collapsar）攻击与防护

课程名称：计算机网络应用 核心摘要：本讲在上一讲 DDoS 攻击基础上，深入讲解应用层 DDoS 攻击——CC 攻击（Challenge Collapsar）的定义、命名由来、攻击原理与典型场景，并系统梳理多维度防护方案，涵盖代码优化、架构优化（负载均衡、CDN、页面静态化）、限流黑白名单、验证码机制及雅虎专利思路。

一、 核心概念与原理

1.1 CC 攻击的定位

• CC 攻击（Challenge Collapsar） 属于 DDoS 攻击的一种，但与传统的基于传输层/网络层的 DDoS 不同。
• 传统 DDoS 基于 TCP（SYN Flood）、UDP、ICMP 等协议，攻击的是整个系统服务；CC 攻击是 应用层（Layer 7）的 DDoS 攻击，通讯协议层次更高，偏向应用层。
• CC 攻击既可以攻击某个具体的资源接口（API）/页面，也可以攻击整个系统，攻击难度相对更低、攻击场景更多。

1.2 命名由来

含义：挑战黑洞——意指以挑战姿态发起针对"黑洞"般庞大资源消耗的攻击。

1.3 攻击本质

• 攻击者不直接发出攻击，而是借助 代理服务器（或控制大量"肉鸡"、代理软件）生成指向受害主机的看似合法的请求，实现攻击与伪装。
• DDoS 本质：分布式拒绝服务（Distributed Denial of Service）——把资源占用完毕后，正常请求无法处理，即"拒绝服务"。
• CC 攻击针对应用中资源消耗较大的接口或页面频繁发起请求，目的是耗尽服务端资源（CPU、内存、数据库连接、磁盘 IO 等）。

1.4 两种典型攻击方式

1. 代理服务器/肉鸡方式

   • 模拟多个用户，借助代理服务器或代理软件，不停向高 IO、高资源消耗的接口发起访问。
   • 使用代理的目的：隐藏攻击者真实 IP（类似代理上网原理，出口 IP 为代理服务器 IP）。

2. 篡改高流量页面 + iframe 嵌入方式

   • 黑客入侵流量极大的网站（如某门户首页），篡改页面，在其中嵌入一个 <iframe> 指向目标资源。
   • 每当有正常用户访问该高流量页面时，都会自动向目标资源发起一次访问。
   • 当访问量足够大时，即转化为对目标服务器的 CC 攻击；流量过小则不构成攻击。

二、 技术细节与协议分析

2.1 CC 攻击 vs 传统 DDoS 对比

2.2 攻击原理深入：耗尽资源的链路

• 系统中消耗资源较大的操作是 CC 攻击的首选目标：
  • 数据库查询（尤其是大表深分页查询）
  • 磁盘读写 IO
  • 复杂计算（CPU 密集）

典型场景：MySQL 深分页查询

-- 大表深分页：offset 越大，扫描行数越多，越耗时
SELECT * FROM big_table
ORDER BY id
LIMIT 1000000, 20;   -- 偏移 100 万条，效率极低

• 单条查询无法立刻完成 → 数据库连接无法及时释放 → 连接被持续占用。
• 攻击者并发调用该接口 → 数据库连接池耗尽 → 正常网页请求被拒绝。
• 若涉及写操作，会引发锁竞争，更易导致数据库连接失败。

2.3 攻击针对的请求类型

三、 实践应用与配置命令

3.1 防护体系总览（多维度防护）

防护应在 网关层之外（商业产品） 与 网关之后（代码/架构层） 协同构建：

[商业产品: 阿里云DDoS防护/WAF]  ← 网关之外
        ↓
[NGINX 限流 + 黑白名单]         ← 网关层
        ↓
[负载均衡 + CDN + 页面静态化]    ← 架构层
        ↓
[代码优化: Redis/Memcache 缓存]  ← 代码层

3.2 四大防护方向

方向一：应用代码性能优化

• 合理使用缓存系统：引入 Redis 或 Memcache，将高频数据放入内存，降低数据库压力。
• 缓存既能提升系统并发能力，也能缓解 CC 攻击带来的读压力。

方向二：网络架构优化

• 引入负载均衡设备：硬负载（F5 等）或软负载（Nginx/LVS/HAProxy），避免流量集中到单台服务器。

  若所有流量集中在单台服务器，初级 CC 攻击即可瞬间击垮服务器。

• 购买 CDN 服务（网宿、阿里云等）：
  • CDN 在全国部署边缘节点，用户就近访问边缘节点，主服务器压力大幅降低。
  • 攻击往往打在边缘节点上，边缘节点 down 掉不影响主节点正常工作。
• 页面静态化技术（商城系统常用）：
  • 为每个商品 / SPU 生成静态详情页，访问不再回源数据库。
  • 结合浏览器缓存、服务端缓存、CDN，对主系统影响极小。

方向三：对抗手段（限流 + 黑白名单）

• 使用 Nginx 限流模块 或 WAF（Web 应用防火墙） 限制每个 IP 的请求频率。

# Nginx 限流示例：基于 IP 限制请求速率
limit_req_zone $binary_remote_addr zone=cc_limit:10m rate=10r/s;

server {
    location /api/ {
        limit_req zone=cc_limit burst=20 nodelay;
        # 超出限流规则的请求触发策略
        # 可配合 Lua 脚本动态加入黑名单
    }
}

• IP 黑白名单机制：
  • 对外面向大众的 API：只能用 黑名单（白名单过于庞大不现实）。
  • 对第三方提供的定向服务：可采用 白名单。
  • 黑名单应自动维护：触发限流策略后自动加入黑名单，不再允许访问。

方向四：验证码机制（针对写操作）

• 对 写入资源型请求（POST） 引入验证码，区分人 vs 机器。
• CC 攻击通常使用代理服务器或肉鸡，验证码难以自动输入，可有效拦截。
• 验证码设计需把握"度"：
  • 过于简单 → 易被暴力破解。
  • 过于复杂 → 正常用户也无法识别。

3.3 雅虎专利思路：Detecting System Abuse

• 专利来源：Yahoo，名称 Detecting System Abuse。
• 核心假设：应用层 DDoS 攻击的 IP 都是真实 IP（攻击者 IP 数量有限，如控制 1000 台肉鸡）。
• 算法思路：
  • 根据 IP 地址 + Cookie 信息 计算客户端的请求频率。
  • 假设 1000 个 IP 共请求 10000 次，则每个 IP 对同一页面请求约 10 次，持续下去各 IP 请求次数增加，但始终在这 1000 个 IP 中轮询。
  • 根据频率特征进行拦截。
• 现状：Yahoo 内部已产品化，但未开源；有财力和技术储备的公司可参考专利实现自研 CC 防护系统。
• 现实判断：99% 的 Web 系统极少面临真正的 CC 攻击，多数公司无需自研。

四、 重点与难点提示

• 考点 1：CC 攻击属于应用层（L7）DDoS，区别于基于 TCP/UDP/ICMP 的传输层 DDoS。
• 考点 2：CC 全称 Challenge Collapsar，Collapsar 意为"黑洞"。
• 考点 3：CC 攻击借助代理服务器/肉鸡模拟合法请求，针对高资源消耗接口耗尽服务端资源。
• 考点 4：数据库连接池耗尽是 CC 攻击的典型后果（大表深分页 + 并发查询）。
• 易错点：缓存优化是针对**读（GET）请求，对写（POST）**请求需结合验证码与限流。
• 易错点：对外大众 API 只能用黑名单（自动维护），白名单仅适用于定向第三方服务。
• 面试题：简述 CC 攻击与 DDoS 攻击的区别。
• 面试题：如何从代码、架构、网关三个层面防御 CC 攻击？
• 面试题：雅虎 Detecting System Abuse 专利的核心思路是什么？

五、 课后疑问/遗留问题

1. Nginx 限流模块（limit_req / limit_conn）的具体参数调优与生产配置实践？
2. 如何基于 IP + Cookie 自动计算请求频率并动态维护黑名单（雅虎专利的工程化实现）？
3. 写操作（POST）场景下，除验证码外还有哪些更优的人机识别方案（如行为验证、设备指纹）？
4. 商业产品（阿里云 DDoS 高防、WAF）与应用层自研防护如何协同分层？
5. 后续课程是否会讲解更复杂的混合型 DDoS + CC 攻击的联合防护实战案例？