什么是CC攻击
CC攻击(Challenge Collapsar) 是一种针对Web应用层的分布式拒绝服务攻击。它通过模拟大量正常用户,持续向服务器发送高频请求,目标是耗尽服务器的处理资源(CPU、内存、连接数),导致其无法响应真实用户,从而达到瘫痪服务的目的。
您可以把它理解为:不是用一股巨力(大流量DDoS)直接冲垮你的大门,而是雇佣成千上万的人(肉鸡/代理),每人以正常方式但不停地挤进你的店铺,问最复杂的问题、浏览最耗时的页面,直到你的店员精疲力竭,无法服务任何真正的顾客。
核心攻击原理与特点
为了更直观地理解,下图清晰地展示了CC攻击的运作流程和它与传统DDoS攻击的关键区别:
flowchart TD
A[攻击者控制大量肉鸡] --> B[构建看似合法的HTTP请求]
B --> C{请求指向哪里?}
C --> D[攻击高消耗页面 (如搜索、数据库查询)]
C --> E[攻击核心接口 (如登录、提交订单)]
D & E --> F[目标: 耗尽服务器 CPU/内存/数据库/带宽资源]
F --> G[结果: 服务器响应缓慢或瘫痪 真实用户无法访问]
H[传统流量型DDoS] --> I[海量垃圾数据包 堵塞网络管道]
subgraph 关键区别
G
I
end

与流量型DDoS相比,CC攻击具有以下显著特点:
- 攻击成本低:通常只需要普通的PC和带宽即可发起,利用代理服务器或“肉鸡”(被控主机)即可隐藏真实IP。
- 识别防御难:因为每个请求都模拟自正常浏览器,协议完全合法,传统的防火墙和入侵检测系统很难将其与真实用户的海量访问区分开。
- 针对性强:攻击者可以精确地攻击消耗资源大的动态页面(如数据库搜索、视频加载)或关键接口(如登录、支付),达到“四两拨千斤”的效果。
如何防御CC攻击
防御的核心思路是 “区分正常用户与攻击请求” 。作为服务器管理员,可以从以下几个层面构建防线:
-
Nginx应用层防御(最直接有效)
你之前询问的Nginx配置,正是防御CC攻击的核心工具:
严格限流:使用 limit_req_zone 和 limit_conn_zone 模块,对单个IP的请求频率和并发连接数进行严格限制。这是对抗CC攻击的第一道门槛。
优化连接参数:合理设置 keepalive_timeout(连接保持时间)和 worker_connections(单个进程连接数),避免服务器被大量空连接挂起。
启用缓存:对静态资源和部分动态页面启用代理缓存,减少请求直接打到后端应用服务器的压力。 -
Web应用自身优化
关键操作验证:在登录、评论、提交订单等关键操作前,加入图形验证码或滑块验证,能有效阻断自动化脚本。
人机验证:集成Google reCAPTCHA或hCaptcha等验证服务,区分人类和机器人。 -
使用专业防火墙/WAF
行为分析:现代WAF能基于IP、会话、用户行为的异常模式(如每秒请求数、访问页面规律)进行智能拦截。
浏览器挑战:触发挑战(如JavaScript计算),只有真实浏览器才能通过,从而过滤掉简单的模拟请求工具。 -
借助CDN和高防服务
流量稀释:将网站接入CDN,静态资源由边缘节点分发,可以将攻击流量分散,减轻源站压力。
高防IP/高防CDN:当遭遇大规模攻击时,可以将域名解析切换到运营商或云服务商提供的“高防”服务上,由他们提供流量清洗中心,过滤掉恶意流量,只将正常请求回源到你的服务器。
攻击排查及解决实操
核心防御配置修改
- Nginx配置安全增强:添加全局限流与黑名单区域(置于配置文件顶部)
通常在 http 块内,或所有 server 块之前添加。
# 定义全局限流和黑名单区域
http {
# 1. 限制请求频率:以客户端IP为键,10MB内存空间,平均速率限制为每秒10个请求
limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=10r/s;
# 2. 限制并发连接数:以客户端IP为键,10MB内存空间
limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
# 3. 动态黑名单:实时封禁恶意IP(配合后面 geo 指令使用)
map $binary_remote_addr $is_banned_ip {
default 0;
# 可以在这里手动添加永久黑名单IP,例如:
# 171.213.163.119 1;
# 74.7.244.52 1;
}
# 4. 定义白名单(如自己办公室IP、搜索引擎IP等,可跳过限流)
geo $limit_whitelist {
default 0;
10.0.0.0/8 1; # 内网IP段全部放行
192.168.0.0/16 1;
# 在此处添加您的公网IP: 123.123.123.123 1;
}
}
- 修改您的 HTTPS server 块(针对 443 端口)
在您的 HTTPS server 块内部(建议在 location / { 之前)应用限制。
server {
listen 443 ssl;
server_name huixinli.cn www.huixinli.cn;
# ... 您原有的 ssl 证书等配置保持不变 ...
# ===== 启用安全限制 =====
# A. 连接数限制:每个IP最多允许20个并发连接(可根据情况调整)
limit_conn conn_limit_per_ip 20;
# B. 请求频率限制:应用 req_limit_per_ip 区域,允许突发30个请求,无延迟,超出部分延迟处理
limit_req zone=req_limit_per_ip burst=30 nodelay;
# C. 如果IP在黑名单中,直接返回 444(连接关闭)
if ($is_banned_ip) {
return 444;
}
# D. 白名单IP跳过限流(重要!)
limit_req_status 429;
limit_conn_status 429;
# 白名单判断
set $limit_key $binary_remote_addr;
if ($limit_whitelist) {
set $limit_key "";
}
# E. 优化连接参数,防止资源被慢连接耗尽
# 关闭 keepalive 可非常有效防御,但略微增加正常用户开销,可临时开启:
# keepalive_timeout 0; # 最严格的防御
keepalive_timeout 15s; # 调整为较短的超时时间
keepalive_requests 50; # 每个连接最多处理 50 个请求
# ... 您原有的 root, index, location 等配置保持不变 ...
location / {
# 可以在此 location 内应用更严格或更宽松的限制
# limit_req zone=req_limit_per_ip burst=5 nodelay;
try_files $uri $uri/ /index.php?$query_string;
}
# 静态资源可以放宽限制或不做限制
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff2)$ {
# 可选:对此 location 不进行请求频率限制
# limit_req off;
# limit_conn off;
expires 365d;
add_header Cache-Control "public, no-transform";
access_log off;
try_files $uri =404;
}
# ... 其他 location 配置 ...
}
临时应急措施
如果云上VPS,可以考虑安全组禁用相关外部地址段。
如果本地主机修改, 在修改 Nginx 配置的同时,立即通过系统防火墙封禁攻击源 IP:
# 使用 iptables 封禁单个IP(例如 171.213.163.119)
sudo iptables -I INPUT -s 171.213.163.119 -j DROP
# 如果要封禁整个IP段(谨慎使用)
# sudo iptables -I INPUT -s 171.213.163.0/24 -j DROP
# 保存 iptables 规则(CentOS 7 常用)
sudo service iptables save
# 或使用 iptables-persistent (Debian/Ubuntu)
监控与后续分析
立即分析日志:攻击期间,快速查看日志确认攻击模式。
# 查看实时访问日志,过滤攻击 IP
tail -f /var/log/nginx/huixinlissl.access.log | grep 171.213.163.119
# 统计该IP的请求情况
grep 171.213.163.119 /var/log/nginx/huixinlissl.access.log | awk '{print $7}' | sort | uniq -c | sort -nr
启用高级防御:如果攻击持续且 IP 变换频繁,考虑:
动态黑名单脚本:编写脚本分析 Nginx 日志,自动将短时间内请求次数异常的 IP 加入上述 map 黑名单。
启用 Fail2Ban:自动化封禁工具,可监控 Nginx 日志并自动更新防火墙规则。
配置修改完成后,务必测试并重载:
sudo nginx -t # 测试配置文件语法
sudo systemctl reload nginx # 平滑重载配置,不影响已有连接
Linux 网络监控工具排查
常用工具对比,下表梳理了 Linux 下常用的网络带宽监控工具:
| 核心需求 | 推荐工具 | 主要功能与特点 |
|---|---|---|
| 查看单个进程的速率 | NetHogs | 按进程实时统计网络带宽,可分别查看发送 (SENT) 和接收 (RECEIVED) 速率,快速定位高带宽进程。 |
| 查看每个连接的速率 | iftop | 实时显示主机之间的连接级带宽使用情况,能看到具体 IP 和端口的流量。 |
| 查看整体带宽使用 | nload | 提供直观的图表,显示进出站流量的实时曲线,适合观察总带宽趋势。 |
| 综合性网络监控 | iptraf-ng | 一个交互式控制台工具,能按协议、端口等分类统计流量。 |
重点工具使用方法
针对排查 CC 攻击的需求,应首先使用 NetHogs 定位问题进程。
-
安装 NetHogs和iftop(以 CentOS 为例)
sudo yum install nethogs iftop -
运行与使用 NetHogs
安装后,使用 sudo 权限运行。运行后,屏幕会列出所有使用网络的进程、PID、用户以及实时发送和接收速率。sudo nethogs -
指定监控网卡(如 eth0)和刷新间隔(如 5 秒):
sudo nethogs eth0 -d 5交互快捷键:
按 s:按发送流量排序。 按 r:按接收流量排序。 按 q:退出。
排查攻击
结合攻击场景,先用 nethogs 找到带宽异常的进程(比如 nginx 的 worker 进程),再用 iftop 查看该进程与哪些外部 IP 建立了大量连接,从而确认攻击源。然后确定具体攻击源:
-
第1步:用 iftop 锁定攻击IP
关注关键指标:运行 iftop 时,可加 -n 和 -P 参数直接显示 IP 和端口。注意观察 nethogs 中的 SENT(发送)列,如果某个进程的发送数据积压(对应 netstat 中 Send-Q 很高),这是 CC 攻击导致服务器响应困难的典型表现。sudo iftop -nNP #-n:不进行主机名解析,直接显示IP,响应更快。 #-P:显示端口号,这是关键!这样你才能看到是哪个端口的流量。 #-N:以数字形式显示端口号。在 iftop 界面中:
观察顶部流量条,它会动态变化。
重点关注nginx 服务器端口(你的 443 端口)对应的远程IP。
你会看到类似下图的信息结构,找到消耗你服务器(443端口)带宽最大的远程IP(很可能就是攻击者):text 191Mb 381Mb 572Mb 762Mb 953Mb └─────────────┴─────────────┴─────────────┴─────────────┴────────────── 10.0.24.17:443 => 171.213.163.119:35547 **12.5Mb** **12.5Mb** 10.0.24.17:443 => 171.213.163.119:23906 **10.2Mb** **10.2Mb** 10.0.24.17:443 => 74.7.244.52:36180 5.1Kb **9.8Mb** ...(其他连接) ---------------------------------------------------------------- TX: cum: 1.93GB peak: 12.5Mb rates: 25.1Mb 22.3Mb 18.7Mb RX: 1.05GB 6.23Mb 12.5Mb 11.2Mb 10.5Mb TOTAL: 2.98GB 18.7Mb 37.6Mb 33.5Mb 29.2Mb箭头方向 => 表示流量从你服务器发送到对方。
中间两列速率是关键:第一列是最近2秒的平均速率,第二列是最近10秒的平均速率。这里 12.5Mb 的就是主要攻击流量。 -
第2步:用 netstat 进行验证和深度查看
netstat 无法查看实时速率,但可以验证连接状态、查看连接数量,是完美的辅助工具。
使用以下命令,可以精确统计某个可疑IP(如 171.213.163.119)与你的服务器建立了多少个连接:[root@VM-24-17-centos conf.d]# netstat -tunp | grep 443 tcp 0 25600 10.0.x.x:443 171.213.163.119:35547 ESTABLISHED 22422/nginx: worker tcp 0 19200 10.0.x.x:443 171.213.163.119:23906 ESTABLISHED 22422/nginx: worker tcp 0 17920 10.0.x.x:443 171.213.163.119:61843 ESTABLISHED 22422/nginx: worker tcp 0 23040 10.0.x.x:443 171.213.163.119:19303 ESTABLISHED 22423/nginx: worker tcp 0 19200 10.0.x.x:443 171.213.163.119:59571 ESTABLISHED 22423/nginx: worker tcp 0 17920 10.0.x.x:443 171.213.163.119:1675 ESTABLISHED 22423/nginx: worker tcp 0 0 10.0.x.x:443 171.213.163.119:24266 ESTABLISHED 22422/nginx: worker tcp 0 23040 10.0.x.x:443 171.213.163.119:3716 ESTABLISHED 22422/nginx: worker tcp 0 17920 10.0.x.x:443 171.213.163.119:17968 ESTABLISHED 22423/nginx: worker tcp 0 20480 10.0.x.x:443 171.213.163.119:44508 ESTABLISHED 22422/nginx: worker tcp 0 17920 10.0.x.x:443 171.213.163.119:63759 ESTABLISHED 22423/nginx: worker tcp 0 23040 10.0.x.x:443 171.213.163.119:2409 ESTABLISHED 22422/nginx: worker tcp 0 25600 10.0.x.x:443 171.213.163.119:50003 ESTABLISHED 22422/nginx: worker -
第3步:关联进程信息
如果 iftop 没加 -P 参数,或者你想再次确认某个端口连接属于哪个 nginx 进程,可以使用 lsof 命令:sudo lsof -i :端口号 # 例如,查看谁在使用443端口 sudo lsof -i :443这会列出所有打开443端口的进程(PID),你应该能看到多个 nginx 的PID。
微信赞赏
支付宝赞赏