防御CC攻击封禁恶意IP段操作规范

CC攻击的封禁难点从来不在“封”这个动作，而在于“封多少、封多久、封错了怎么办”。多数运维一看到流量异常就直接在防火墙里加DROP规则，结果要么封了正常CDN回源节点，要么攻击者换一批代理IP继续打。真正有效的恶意IP段封禁，必须建立在流量特征识别、IP信誉交叉验证和自动化收敛三个环节上，而不是靠人肉抓包一条条加规则。

先说一个基本判断：CC攻击的源IP段在攻击持续期间通常具有明显的聚集性。攻击者为了控制成本，往往会批量租用同一家机房或同一段广播IP的服务器，这就导致攻击流量在/24甚至/16级别上出现异常峰值。如果你只封单个IP，攻击者切换成本极低；如果你直接封整个/16，又可能误伤大量正常用户。因此，封禁操作规范的核心是确定合理的封禁粒度，并建立可回滚的封禁机制。

在封禁任何IP段之前，必须先完成攻击特征确认。CC攻击的典型特征是短时间大量请求集中在少数URL上，且请求来源IP的请求频率远高于正常用户。你需要从Web服务器日志或流量分析平台中提取以下数据：请求频率最高的前50个IP、这些IP的User-Agent分布、请求的URL集中度、以及是否存在明显的僵尸网络指纹（如固定的Cookie缺失、固定的屏幕分辨率参数缺失）。

这里有一个关键点：不要只依赖请求频率判断。很多正常的企业出口IP或校园网出口IP也会出现高并发请求，尤其是图片类或API类业务。判断恶意IP的核心依据是行为模式异常，而不是单纯的流量大小。例如，正常用户访问一个页面后会请求页面内的CSS、JS、图片等静态资源，而CC攻击脚本往往只请求目标URL本身，不加载任何静态资源。这种“只打一个点”的特征比流量峰值更可靠。

封禁粒度直接决定了误伤范围和封禁效果。规范的做法是采用分级封禁策略：第一级封禁单个IP，第二级封禁/24段，第三级封禁/16段。触发条件应基于攻击IP在该网段内的分布密度。如果某个/24段内有超过30%的IP在短时间内被识别为攻击源，那么升级封禁整个/24段是合理的；如果多个相邻/24段都出现攻击源，再考虑封禁/16段。

实际操作中，建议先封单IP并观察10到15分钟。如果攻击流量没有明显下降，说明攻击者拥有大量备用IP，此时应直接升级到/24段封禁。对于/16级别的封禁，必须由值班负责人确认，因为这种操作可能影响数万个正常IP地址。封禁/16段之前，务必检查该段内是否存在CDN节点、DNS服务器或重要的合作伙伴IP。

在Linux服务器上，封禁IP段通常使用iptables或nftables。以下是一个标准的iptables封禁/24段的命令示例：

iptables -I INPUT -s 192.168.1.0/24 -j DROP
iptables -I FORWARD -s 192.168.1.0/24 -j DROP

如果使用nftables，命令如下：

nft add rule ip filter INPUT ip saddr 192.168.1.0/24 drop
nft add rule ip filter FORWARD ip saddr 192.168.1.0/24 drop

需要特别注意的是，封禁规则必须放在规则链的靠前位置，并且要确保在封禁之前已经放行了本机回环地址和已建立连接的流量。否则可能导致服务器自身的服务通信异常。建议在封禁前先执行以下命令放行已建立连接：

iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

对于使用云服务商安全组或WAF的场景，封禁操作应在WAF层面完成，而不是在源站防火墙上操作。因为CC攻击流量如果已经到达源站，说明WAF没有起到过滤作用，此时在源站封禁只能缓解单台服务器的压力，无法从根本上解决问题。正确的做法是：在WAF上配置基于IP信誉库的自动封禁策略，同时在源站保留手动封禁能力作为应急手段。

封禁操作完成后，必须在5分钟内验证封禁效果。验证方法包括：查看防火墙规则是否生效、观察服务器负载是否下降、检查业务日志中是否还有来自被封禁IP段的请求。如果封禁后业务访问量出现断崖式下跌，且下跌幅度超过正常流量波动范围，说明可能存在误封，需要立即回滚。

回滚操作必须提前准备好。建议在每次封禁操作前，将当前防火墙规则导出备份，并记录封禁时间和封禁原因。以下是一个简单的iptables规则备份命令：

iptables-save > /root/iptables-backup-$(date +%Y%m%d%H%M%S).rules

回滚时只需执行对应的iptables-restore命令即可。对于WAF层面的封禁，回滚操作通常在WAF控制台完成，但同样需要记录操作日志，以便事后审计。

完全依赖人工封禁在CC攻击面前是不现实的，攻击者可以在几分钟内切换数百个IP。因此，自动化封禁系统是必要的。但自动化系统必须设置封禁阈值和封禁上限，避免在误判时造成大面积误封。一个合理的自动化策略是：当某个IP在60秒内请求同一URL超过100次且无静态资源请求时，自动封禁该IP 30分钟；当某个/24段在10分钟内出现超过20个被封禁IP时，自动封禁该/24段2小时；/16段封禁必须由人工确认后执行。

自动化封禁系统还应该具备白名单机制。白名单至少应包含：搜索引擎爬虫IP段、CDN回源节点IP、监控系统IP、公司内部办公出口IP。白名单的维护必须定期更新，因为CDN节点和搜索引擎爬虫的IP段会发生变化。如果白名单失效，自动化封禁系统很可能把正常流量当成攻击流量封掉。

封禁操作不是一次性的应急动作，而是一个需要持续优化的过程。每次CC攻击结束后，应该对封禁的IP段进行复盘分析：这些IP段是否属于某个特定的IDC或云服务商？攻击持续了多长时间？封禁策略是否有效缩短了攻击影响时间？通过积累这些数据，可以逐步建立起针对自身业务的恶意IP段信誉库。

一个更进一步的思路是：将封禁操作与业务限流结合起来。对于无法确定是否恶意的IP段，可以先进行限速处理，例如将单个IP的请求频率限制在正常水平的2倍以内，而不是直接封禁。这样既能保护正常用户，又能有效压制攻击流量。限速操作在Nginx层面可以通过limit_req模块实现，在iptables层面可以使用hashlimit模块。

最后强调一点：封禁恶意IP段只是CC攻击防御体系中的一个环节，它不能替代WAF规则优化、业务逻辑加固和容量弹性扩展。如果业务本身存在性能瓶颈，即使封禁了所有攻击IP，正常流量高峰也可能压垮服务器。因此，封禁操作规范必须与整体防御策略配合使用，才能达到最佳效果。