欢迎访问宝典百科，专注于IT类百科知识解答！
Linux被CC了怎么办——全面应急响应与防御实战指南
随着互联网业务的普及，CC攻击（Challenge Collapsar）已经成为Linux服务器最常见的DDoS攻击形式之一。与传统的带宽型DDoS不同，CC攻击针对Web应用层，通过大量合法或伪造的请求占用服务器连接池、CPU和内存资源，导致服务响应缓慢甚至瘫痪。根据权威安全机构的统计数据，2024年CC攻击约占Web应用层攻击总量的68%，且单次攻击峰值可达数百万QPS。对于运维工程师而言，掌握一套结构化、可落地的应急流程至关重要。本文将从攻击识别、紧急处置、系统调优、长期防御四个维度，结合详实的数据表格和命令行示例，给出完整的解决思路。
一、CC攻击的典型特征与识别方法
在决定如何应对之前，必须快速判断服务器是否真的遭受CC攻击。常见的迹象包括：CPU使用率突然飙升至95%以上、空闲连接数异常增多、Web日志中出现大量相同IP或同一UA（User-Agent）的请求、响应时间从毫秒级恶化到数十秒。为了更精准地定位，我建议使用如下命令进行实时观测：
1. 查看当前TCP连接状态与来源IP分布：
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -n20
该命令会输出连接数最多的前20个IP。如果某个IP的SYN_RECV或ESTABLISHED连接数超过几百甚至上千，就极有可能是攻击源。
2. 分析Web访问日志（以Nginx为例）：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n10
同时，观察请求的URL是否集中在同一个动态接口（如/api/login、/search.php）且请求频率异常，或User-Agent字段为空、包含随机字符串，这些都属于CC攻击的典型指纹。
| 攻击类型 | 核心特征 | 识别维度 | 典型工具 |
|---|---|---|---|
| HTTP Flood | 高频并发GET/POST请求，单IP或IP段集中 | 请求速率、来源IP分布、URL集中度 | CC攻击器、ApacheBench |
| 慢速连接(Slowloris) | 发送不完整的HTTP头，长期占用连接 | 连接完成率低，ESTABLISHED连接堆积 | slowhttptest |
| 代理型CC | 大量代理IP轮换请求，单个IP频率低 | 总QPS高但单IP不明显，需统计总连接 | ProxyChains+自定义脚本 |
| API滥用攻击 | 针对特定API频繁调用，如短信接口、查询接口 | 接口级别QPS、业务请求与时间分布 | Postman自动化脚本 |
二、紧急处置措施——黄金5分钟
确认攻击后，不要惊慌。按照以下顺序执行紧急封禁和限流，能快速减轻服务器压力。
第一步：临时黑洞或禁用应用服务。如果CPU已100%且无法SSH操作，应立即在云控制台或机房网络设备上对服务器IP进行黑洞或云访问控制列表（ACL）临时封堵。若仍有SSH权限，执行systemctl stop nginx或kill -9 <父进程ID>终止Web服务，防止资源被彻底打满。
第二步：利用防火墙快速封杀攻击IP。使用iptables对明显攻击源进行丢弃操作：
iptables -A INPUT -s 123.45.67.89 -j DROP
对于大量陌生IP，建议使用fail2ban动态封禁。修改本地/etc/fail2ban/jail.local，增加以下配置：
[nginx-cc]
enabled = true
filter = nginx-cc
action = iptables-multiport[name=nginx-cc, port="http,https"]
logpath = /var/log/nginx/access.log
maxretry = 100
findtime = 60
bantime = 3600
这表示60秒内同一IP出现100次访问就封禁1小时。同时，利用nginx_http_limit_req_module模块实现接口级速率限制：
http{} 中定义全局区域：
limit_req_zone $binary_remote_addr zone=anti_cc:10m rate=30r/m;
server{} 中调用：
limit_req zone=anti_cc burst=50 nodelay;
以上配置将每个IP每分钟请求数限制为30个，并允许50个突发缓冲。
第三步：拔掉不必要的服务端口。如果攻击入口不是80/443，可以临时执行iptables -A INPUT -p tcp --dport 8080 -j DROP，同时关闭数据库远程端口等。
三、Linux系统内核与Web服务深度调优
当紧急封禁无法彻底阻止带有真实分布式的攻击源时（例如僵尸网络），需要从操作系统层面增强抗压能力。以下参数经过实战验证能显著提升Linux服务器的并发承受力。
1. 内核参数优化（/etc/sysctl.conf）
编辑/etc/sysctl.conf并追加：
net.ipv4.tcp_syncookies = 1 # 防止SYN Flood攻击
net.ipv4.tcp_max_syn_backlog = 65535 # 增大半连接队列
net.ipv4.tcp_fin_timeout = 15 # 缩短TIME_WAIT生命周期
net.ipv4.tcp_tw_reuse = 1 # 允许复用TIME_WAIT连接
net.ipv4.tcp_tw_recycle = 0 # 注意：新内核建议关闭NAT环境下的tw_recycle
net.core.somaxconn = 65535 # 队列上限
net.netfilter.nf_conntrack_max = 1048576 # 提高连接表容量
执行sysctl -p生效。
2. Nginx配置调优。在nginx.conf的events块和http块中调整：
worker_processes 8;
worker_rlimit_nofile 65535;
events { use epoll; worker_connections 102400; }
keepalive_timeout 10;
client_header_timeout 5s;
client_body_timeout 10s;
send_timeout 5s;
同时，可以在http块中开启limit_conn_zone $binary_remote_addr zone=perip:10m;，用于限制单个IP的并发连接数：
limit_conn perip 50;
3. 扩展至多实例负载均衡。如果单机已经无法支撑，可以快速添加多台临时Web服务器，使用nginx upstream或云负载均衡SLB分发流量。注意在每台机器上同步上述安全配置。
四、长期防护架构与第三方服务选择
紧急处理只是治标，若业务长期暴露在公网，必须构建多层次的防御体系。下表对比了主流防护方案的关键指标，供选型参考：
| 防护方案 | 适用场景 | 防护能力 | 成本估算 | 接入延迟 |
|---|---|---|---|---|
| 高防IP | 一切对外业务DDoS+CC混合攻击 | 可支持T级带宽清洗，CC防护QPS≥100万 | 按保底带宽+弹性收费，月均≥5000元 | 增加1-3ms延迟 |
| CDN+边缘WAF | 静态内容为主，或需全球加速 | 分散攻击源，WAF拦截SQL注入、CC规则匹配 | 按流量或请求数计费，月均≥2000元 | 增加5-20ms，与节点位置有关 |
| Web应用防火墙(WAF) | 精细到URL/IP/会话的防护 | 自定义规则，支持频控、人机验证 | 月均≥1000元，不同企业版差异大 | 代理部署时增加1-5ms |
| 自建LVS+Keepalived集群 | 技术能力强，有IDC资源 | 依赖自身带宽与硬件，适合10G以下攻击 | 服务器+运维成本，无固定服务费 | 无额外添加延迟 |
开通高防或CDN后，需要将DNS解析的A记录或CNAME切换至服务商提供的IP/域名。切换前建议先在源站防火墙白名单中只允许高防节点回源，防止真实IP暴露再次被攻击。
五、日常预防与应急演练总结
应对CC攻击没有一次性解决方案，必须建立常态化机制。建议每周执行一次以下自检清单：
1. 监控告警：部署Zabbix/Prometheus，对CPU、内存、TCP连接数、特定URL的QPS进行阈值告警，阈值可设在正常值的150%。
2. 自动化封禁脚本：编写基于日志分析的脚本，自动提取异常IP并调用云API（如阿里云安骑士、腾讯云LHC）进行封堵，实现分钟级响应。
3. 定期备份与应急预案：备份nginx配置、iptables规则、fail2ban配置；同时每季度进行一次模拟CC攻击演练，确保团队熟悉处置流程。
4. 业务架构弹性：将无状态服务容器化，基于Kubernetes的HPA（水平自动扩缩容）在负载升高时自动扩容Pod副本，从应用层消化突发流量。
最后提醒：切勿在未明确攻击特征时盲目重启服务器，否则会丢失原始“现场”，且重启后仍可能被再次打瘫。优先保留netstat、tcpdump、nginx日志等证据，便于事后溯源和调整规则。通过本指南中的结构化数据与命令，相信你能将CC攻击的影响降至最低，让Linux服务器在恶劣的互联网环境中保持稳定运行。
