企业官网高频CC攻击应急处置流程

企业官网遭遇CC攻击时，最直观的表现不是带宽跑满，而是服务器CPU和内存资源在短时间内被大量看似正常的请求耗尽。真正的危险在于，这种攻击往往混杂在正常业务流量中，单纯封IP会误伤真实客户。应急响应的核心不是硬抗，而是要在保证业务连续性的前提下，快速把攻击流量和正常流量剥离开。

登录服务器后，不要先看流量图，直接跑命令。用netstat -an | grep :80 | wc -l统计当前并发连接数，如果这个数字远超日常峰值5倍以上，基本可以判定为CC攻击。接着用netstat -an | grep :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20查看连接数最高的IP，如果某个IP或几个IP的连接数达到数百甚至上千，而正常用户一般只有几个连接，这就是典型的CC攻击特征。还有一个关键判断点：查看服务器负载uptime，如果1分钟负载超过CPU核心数的2倍，同时网站响应极慢，但带宽占用并不高，那几乎可以肯定是CC攻击而非流量型DDoS。

确认攻击后，第一件事不是去分析日志，而是先在前端把恶意请求挡掉。如果用的是Nginx，立即修改配置文件加上limit_conn和limit_req模块。limit_conn用来限制单个IP的并发连接数，limit_req用来限制请求速率。一个实战中验证有效的配置是：

http {
    limit_conn_zone $binary_remote_addr zone=conn_perip:10m;
    limit_req_zone $binary_remote_addr zone=req_perip:10m rate=10r/s;
    
    server {
        limit_conn conn_perip 10;
        limit_req zone=req_perip burst=20 nodelay;
    }
}

这个配置将每个IP的并发连接限制为10个，请求速率限制为每秒10次，突发容量20个。对于企业官网这种场景，正常用户浏览页面时并发连接通常不超过5个，请求速率也在合理范围内。配置生效后，攻击流量会被直接拒绝，服务器负载会迅速下降。如果用的是Apache，需要启用mod_evasive模块，配置参数类似，但Nginx在高并发场景下资源消耗更小，应急时优先推荐。

前端限流只是暂时缓解，要彻底解决问题必须找到攻击流量的特征。CC攻击通常会模拟正常请求，但仔细分析日志就能发现规律。攻击者往往会集中请求某一个或某几个URL，比如搜索接口、登录页面或某个动态页面。用命令cat access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -20统计被请求最多的URL路径，如果某个路径的请求量远超其他页面几十倍，这就是攻击目标。更隐蔽的攻击会伪造User-Agent，但大部分攻击脚本使用的UA头都比较固定，用cat access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -nr | head -20查看UA分布，如果某个相同的UA出现频率异常高，就可以作为过滤特征。还有一个容易被忽略的维度是请求来源的Referer字段，攻击请求通常没有Referer或Referer为空。

手动封IP在CC攻击面前效率太低，攻击者可能使用数千个代理IP轮换。需要建立一个自动化的封禁机制。在Linux下，可以编写一个简单的shell脚本，结合iptables实现动态封禁。核心逻辑是：实时解析Nginx访问日志，统计每个IP在最近1分钟内的请求次数，超过阈值就加入iptables黑名单，封禁时间设置为10分钟，到期自动解封。脚本示例如下：

#!/bin/bash
tail -f /var/log/nginx/access.log | while read line; do
    ip=$(echo $line | awk '{print $1}')
    count=$(grep -c $ip /tmp/ip_count.tmp 2>/dev/null)
    if [ $count -gt 100 ]; then
        iptables -I INPUT -s $ip -j DROP
        echo "$(date) blocked $ip" >> /var/log/block_ip.log
        sleep 600
        iptables -D INPUT -s $ip -j DROP
    fi
done

这个脚本比较粗糙，生产环境建议使用fail2ban这类成熟工具。配置fail2ban监控Nginx日志，设定规则：60秒内单个IP请求超过120次就封禁600秒。fail2ban的好处是稳定可靠，不会因为脚本bug导致系统问题，而且支持自动解封和日志记录。需要注意的是，阈值设置要结合网站实际情况，一个正常用户在浏览商品详情页时，1分钟内可能会产生30到50次请求，阈值要高于这个数字，避免误伤。

CC攻击打的就是动态页面的处理能力。如果官网在平时没有做静态化，应急时可以临时启用Nginx的fastcgi_cache或proxy_cache，将动态页面缓存起来。对于不频繁更新的内容，设置缓存时间为5到10分钟，这样即使攻击请求打过来，Nginx直接从缓存返回内容，后端应用服务器和数据库压力骤降。配置要点是：

location ~ \.php$ {
    fastcgi_cache CACHE_ZONE;
    fastcgi_cache_key $request_uri;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_use_stale error timeout updating;
}

关键参数是fastcgi_cache_use_stale，它允许在后端出错或超时时返回过期缓存，这在攻击期间能保证网站至少还能访问。如果官网用了CDN，立即登录CDN控制台开启CC防护模式，将防护等级调高，同时开启JS挑战或验证码。CDN的节点遍布各地，能够在攻击流量到达源站之前就进行清洗，这是最有效的第一道防线。

当攻击绕过了IP限制和缓存层，说明攻击者可能在模拟真实用户行为，比如使用大量代理IP、每个IP请求频率不高但总量巨大。这时需要在应用层增加验证。最快的方式是在被攻击的URL路径前增加一个验证码校验。如果是自研系统，可以临时修改代码，在入口处加入一个简单的验证逻辑，比如要求请求携带一个动态生成的token。更高效的做法是接入第三方的行为验证服务，这类服务通过收集鼠标轨迹、键盘敲击节奏、设备指纹等信息来判断是真人还是脚本，对用户体验影响较小。部署时注意，验证码不要放在所有页面上，只放在攻击者集中请求的那个接口或页面即可，尽量减少对正常用户的影响。

如果攻击流量已经大到CDN节点都扛不住，或者攻击者直接绕过了CDN攻击源站，说明源站IP已经暴露。应急步骤是立即更换源站IP，并在新IP上只允许CDN的回源IP访问，其他所有IP的请求全部拒绝。在iptables中设置白名单规则：

iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP
for ip in $(cat cdn_ip_list.txt); do
    iptables -I INPUT -s $ip -p tcp --dport 80 -j ACCEPT
    iptables -I INPUT -s $ip -p tcp --dport 443 -j ACCEPT
done

这个操作要快，更换IP后立即更新DNS解析到CDN，同时通知CDN服务商更新回源配置。如果攻击规模持续扩大，考虑接入专业的高防服务，将流量牵引到高防机房进行清洗。高防服务的核心优势是带宽储备和大数据攻击特征库，能够识别并过滤掉复杂的CC攻击模式，这是自建防御难以达到的。

CC攻击往往最终会压垮数据库，因为大量请求需要查询数据库。应急时，在应用配置中调低数据库连接池的最大连接数，比如从100降到30，同时缩短连接超时时间。这样即使前端请求堆积，数据库也不会因为连接数耗尽而崩溃。更重要的是，检查SQL查询是否有慢查询，用show processlist查看当前正在执行的查询，如果发现大量相同的查询堆积，可能是某个接口被攻击，临时对该接口返回静态数据或空数据，牺牲部分功能保证整体可用。

在应急处理的同时，不要忘记保留证据。将攻击期间的访问日志、系统日志、网络流量数据完整备份下来。用tcpdump抓取一段时间的流量包，命令为tcpdump -i eth0 -w attack.pcap -c 10000，抓取1万个包即可用于后续分析。日志中可能包含攻击者的特征指纹，这些数据对于后续的溯源和报案都至关重要。同时，记录下攻击开始的时间、攻击流量的特征、采取的应急措施和时间点，形成完整的应急响应报告。

攻击停止后，不能就此了事。根据这次攻击暴露出的弱点，对系统进行加固。将应急时临时启用的限流、缓存、验证码等措施固化为常态配置。优化网站代码，减少动态请求，对频繁访问的接口增加缓存层。建立监控告警机制，当服务器并发连接数或请求速率超过基线阈值时自动发送告警，并触发预设的防御策略。定期进行压力测试和攻防演练，验证防御措施的有效性。企业官网作为对外窗口，安全防护应该是一项持续性的工作，而不是等到被攻击了才临时应对。