蓝易云CDN：企业遭遇DDoS攻击后的应急处置与常见防御手段

对于企业来说，DDoS攻击带来的不仅仅是技术层面的麻烦。业务中断的每一分钟都在流失收入和用户信任，客户投诉涌入客服渠道，管理层要求立刻给出恢复时间表——技术团队往往是在多重压力下同时作战。所以应急处置的核心不只是"怎么挡住攻击"，更是怎么在混乱中做出正确的决策顺序 🎯

一、攻击发生后的黄金十分钟

企业遭遇DDoS攻击时，最容易犯的错误是"一上来就动手改配置"。正确的做法是先用两分钟完成态势判断，再分优先级执行处置动作。

第一步：快速定性攻击类型

# 同时抓取三项关键数据来判断攻击类型
# 第一条：查看网卡实时流量，判断是否为带宽型攻击
# sar是系统活动报告工具，-n DEV表示查看网络设备统计
# 1 3 表示每秒采样一次，连续3次
# rxkB/s列就是每秒接收的数据量（KB），换算成Mbps判断带宽是否被打满
sar -n DEV 1 3

# 第二条：查看当前TCP连接状态分布
# ss比netstat更快，适合在高负载场景下使用
# -s参数输出连接状态的汇总统计而非逐条列出
# 重点关注SYN-RECV（半连接）和ESTAB（已建立连接）的数量
ss -s

# 第三条：查看Web服务的请求速率
# 实时统计最近5秒内Nginx访问日志的行数
# 如果access.log每秒新增数千行且大量请求集中在少数几个URL
# 基本可以判断为应用层CC攻击
tail -f /var/log/nginx/access.log | pv -l -i 5 > /dev/null

三条命令分别对应三种攻击类型的判断依据：带宽暴涨指向流量型攻击，半连接堆积指向协议型攻击，请求密度异常指向应用层攻击。定性准确才能对症下药，避免把精力浪费在错误的方向上 📊

第二步：启动流量牵引

确认攻击后，最优先的动作是把流量牵引到具备清洗能力的基础设施上。如果企业已经接入蓝易云CDN，确认域名解析指向CDN的CNAME即可。如果尚未接入，此刻紧急接入的操作流程是：修改DNS将域名CNAME到CDN分配的加速域名，然后在CDN控制台配置回源地址。

DNS生效存在传播延迟，通常需要几分钟到几十分钟。这段时间就是攻击影响最严重的窗口期，所以源站自身的抗压能力至关重要。

第三步：源站紧急止血

在CDN接管流量之前（或作为CDN防护的补充），源站需要立即执行自保措施：

# 使用iptables的hashlimit模块对新建连接做速率限制
# hashlimit比limit模块更精细，它能按来源IP分别限速
# --hashlimit-name connlimit 为这条规则命名，用于创建内核哈希表
# --hashlimit-above 15/sec 含义：当某个IP每秒新建连接超过15个时触发
# --hashlimit-mode srcip 以源IP为限速维度
# --hashlimit-burst 25 允许25个连接的初始突发（应对正常用户短时多请求场景）
# --hashlimit-htable-expire 30000 哈希表条目30秒后过期（单位毫秒）
# -p tcp --dport 443 仅针对HTTPS端口
# -j DROP 超过阈值的新连接直接丢弃
iptables -A INPUT -p tcp --dport 443 -m state --state NEW \
  -m hashlimit --hashlimit-name connlimit \
  --hashlimit-above 15/sec --hashlimit-mode srcip \
  --hashlimit-burst 25 --hashlimit-htable-expire 30000 \
  -j DROP

这条规则的设计思路是：正常用户打开一个网页通常产生5到10个并发连接（HTML加上CSS、JS、图片等资源请求），设置15/秒的阈值加上25个突发余量，对正常访问完全无影响，但能精准拦截单IP高频发起连接的攻击行为 🔒

二、攻击平息后的必做动作

很多企业在攻击停止后就松了口气，恢复业务后不再处理。这是一个严重的疏忽——攻击停止不代表威胁消失，而且第一次攻击往往只是试探。

取证与溯源

# 从Nginx日志中提取攻击时段的请求特征
# 假设攻击发生在14:00到14:30之间
# awk的时间过滤条件匹配日志中的时间戳字段
# 提取每个请求的IP、请求路径和User-Agent
# 通过排序和去重找出请求量最大的IP和最集中的攻击路径
awk '$4 >= "[27/Mar/2026:14:00" && $4 <= "[27/Mar/2026:14:30"' \
  /var/log/nginx/access.log \
  | awk '{print $1, $7, $NF}' | sort | uniq -c | sort -rn | head -50

# 导出攻击期间的连接日志用于后续分析
# conntrack是Linux内核连接追踪模块的用户态工具
# -L 列出当前所有被追踪的连接
# -o extended 输出扩展信息，包含连接的字节数和包数
# 将结果保存到文件，供安全团队事后分析攻击流量特征
conntrack -L -o extended > /tmp/attack_conntrack_$(date +%Y%m%d%H%M).log

保留这些日志至少90天。如果攻击造成了业务损失，这些记录是向执法机构报案或向保险公司索赔的关键证据 📁

复盘与加固

召集技术团队做一次结构化复盘，重点回答四个问题：攻击是什么时候被发现的（检测能力）？从发现到开始处置用了多久（响应速度）？哪些处置动作有效、哪些无效（手段有效性）？有哪些环节可以自动化（流程优化）？

三、企业常见的DDoS防御手段

应急处置是"救火"，日常防御才是"防火"。以下是企业在实践中被验证有效的防御手段。

1. CDN分布式吸收

将业务流量接入蓝易云CDN后，攻击流量被分散到多个边缘节点处理，源站只接收经过清洗的回源流量。CDN的核心价值在于用分布式架构把攻击的"集中力量"化解为分散在各节点的"小压力"，就像把一拳的力量分散到整个手掌 ✋

2. 多维度限流策略

单一维度的限流容易被绕过。企业应该同时部署IP维度、指纹维度和URL维度的叠加限流：

# 三个维度的限流区域分别针对不同攻击模式

# 维度一：按客户端IP限流
# 防止单个IP发起高频请求（适用于集中型攻击）
limit_req_zone $binary_remote_addr zone=by_ip:10m rate=20r/s;

# 维度二：按JA4 TLS指纹限流
# 同一攻击工具即使分布在不同IP上，TLS指纹也相同
# 这一层能拦截使用代理IP池的分布式CC攻击
limit_req_zone $http_x_ja4 zone=by_ja4:20m rate=80r/s;

# 维度三：按请求URI限流
# 保护高资源消耗的接口（如搜索、登录、支付回调）
# 即使单IP和单指纹都没触发阈值
# 但某个接口的总请求量异常暴增时也能触发保护
limit_req_zone $uri zone=by_uri:10m rate=100r/s;

server {
    location /api/ {
        # 三层同时生效，任一层触发都会拦截
        limit_req zone=by_ip burst=30 nodelay;
        limit_req zone=by_ja4 burst=100 nodelay;
        limit_req zone=by_uri burst=150 nodelay;
        
        proxy_pass http://backend;
    }
}

三个维度的限流像三层筛网叠在一起——粗筛拦截明显的单点攻击，中筛拦截工具化的分布式攻击，细筛保护关键接口不被集中打穿。攻击者要同时绕过三层限制的难度呈指数级上升 🧱

3. 弹性架构设计

纯粹依赖"挡"是不够的，架构本身的弹性同样重要。具体措施包括：将动态内容和静态资源分离部署，静态资源全部通过CDN缓存交付，后端只处理必须实时计算的请求；对数据库查询做好缓存层（如Redis），避免CC攻击直接穿透到数据库层；业务接口设计上增加验证码、Token校验等人机识别环节，提高攻击者每次请求的成本。

4. 威胁情报联动

孤立的防御是低效的。蓝易云CDN通过分析全网拦截日志，持续积累恶意IP信誉库和攻击工具JA4指纹库。当某个新型攻击工具首先出现在A客户的流量中被识别后，其指纹特征可以在分钟级别同步到全网所有节点，B客户在遭遇同一工具攻击时就能直接拦截，不需要重新学习 🌐

5. 定期防御演练

很多企业平时不演练，真正被攻击时发现预案中写的联系人已经离职、应急脚本因为系统升级已经跑不通、CDN控制台密码没人记得。建议每季度做一次DDoS应急演练，模拟从告警触发到完成处置的全流程，确保预案中的每个环节都能真正执行 ⏱️

四、给企业决策者的建议

DDoS防护不仅仅是技术部门的事。企业需要在三个层面做好准备：技术层面部署CDN清洗、WAF规则、内核加固等防护能力；流程层面建立书面的应急预案，明确谁来做什么决策、谁负责执行什么操作、谁对外沟通；预算层面为高防带宽和CDN服务预留合理费用——DDoS防护本质上是一种保险投入，平时看不到收益，但关键时刻能避免数倍甚至数十倍的损失。

攻击者只需要找到一个突破口就够了，而防御者必须守住所有可能的入口。这场不对等的博弈中，体系化的纵深防御加上持续验证的运营机制，才是企业真正可靠的安全底线 💪