DDoS应急最怕的不是流量大，而是没人知道下一步做什么。本文把多次真实处置整理成一条脱敏时间线：前 3 分钟看什么、什么时候切高防、源站怎么止血、攻击停了 24 小时内补什么，每一步都给判据和命令。
Q：为什么 DDoS 处置要讲时间线，而不是讲工具？
- 现场的瓶颈从来不是技术，是决策顺序。知道「先干什么」比知道「有哪些工具」有用得多。
- 时间线可以演练：写下来、按分钟核对，下次就不必临场想。
- 下面这条线来自多次处置的共性。具体分钟数按业务规模调整，顺序不要改。
Q：T+0 到 T+3 分钟，第一件事做什么？
- 不是登录服务器，是确认这到底是不是 DDoS：入向带宽、连接数、源站是否还能正常响应。
- 三类假警报先排除：自己发版造成的回源风暴、七层 CC、上游线路故障。
- 三看：带宽曲线是否陡直上升、
SYN_RECV是否暴涨、源站 200 是否还在返回。
# 连接状态分布，SYN_RECV 暴涨通常是 SYN Flood 或连接耗尽
ss -s
ss -ant | awk 'NR>1{c[$1]++} END{for(k in c) print k, c[k]}'
# 实时带宽与包速率
iftop -nNP -i eth0
# 网卡吞吐趋势（看 rxkB/s 是否被打满）
sar -n DEV 1 5- 同时留证据：把这一刻的
ss输出、iftop截图、日志切一份存好，报案和复盘都要用。
Q：T+3 到 T+10 分钟，怎么判断攻击类型与量级？
- 四层洪水：带宽打满、包速率极高、平均包长偏小（常见 64 到 200 字节）。
- 连接耗尽：带宽不高但并发连接数暴涨，accept 队列满，源站卡在握手阶段。
- 七层 CC：带宽正常但 QPS 异常，URL 集中在少数接口。这一步只做区分，处置走 CC 专题。
# 抓 500 个包看协议与标志位分布
tcpdump -i eth0 -nn -c 500 'ip' 2>/dev/null \
| awk '{print $3}' | sort | uniq -c | sort -rn | head
# 按源 IP 统计连接数 Top10
ss -ant | awk 'NR>1{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head- 量级用 pps × 平均包长 × 8 估算，别只看 Mbps：64 字节小包下 1Gbps 约等于 118 万 pps，这个换算决定了你的防护到底够不够。
Q：第一决策：切高防还是先扛？
- 已接入高防的，先确认牵引有没有生效：解析是否已指向高防、清洗阈值是否触发。
- 未接入的两条路：临时切高防（改 DNS 或 CNAME），或者换 IP 把源站藏起来。
- 三个决策依据：预计持续时长（超过 10 分钟就别赌）、业务优先级（有交易就走高防）、切换成本（DNS TTL 决定了你能不能快切）。
- 切换前先做一件事：把 TTL 调小到 60 秒并等一个旧 TTL 周期过去，否则改了解析也要等几十分钟才全量生效。
- 黑洞是最后手段：它保住上游，但业务直接归零，解封节奏还不在你手上。
Q：T+10 到 T+30 分钟，源站怎么止血？
- 只允许回源网段访问。攻击者绕过 CDN 直连源站，是最常见的失守方式。
- 关掉非必要端口和非核心接口，能静态化的页面立刻静态化。
- 连接数与速率双限，先保可用，再谈体验。
- 改完立刻验证：从外部直连源站 IP 并伪造 Host，正常应该超时或被拒绝；能拿到 200 就说明白名单写漏了。
set_real_ip_from只写高防的回源网段，写0.0.0.0/0等于把真实 IP 的判断权交给任何人。
# 仅允许高防回源网段访问 443
iptables -I INPUT -p tcp --dport 443 ! -s 203.0.113.0/24 -j DROP
# 单 IP 并发连接限制
iptables -I INPUT -p tcp --dport 443 \
-m connlimit --connlimit-above 50 -j DROP
# Nginx 侧连接与速率双限
limit_conn_zone $binary_remote_addr zone=perip:20m;
limit_req_zone $binary_remote_addr zone=perreq:20m rate=20r/s;
limit_conn perip 30;
limit_req zone=perreq burst=40 nodelay;
limit_req_status 429;Q：攻击进行中，哪些动作绝对不能做？
- 不要盲目调大
worker_connections和内核 backlog：超过真实处理能力，只会把崩溃推迟到更糟的时点。 - 不要删日志。删了就没了复盘和报案的依据，也看不出攻击变化。
- 不要立刻重启服务。TCP 连接重建会带来二次冲击，通常比扛着更糟。
- 不要公开披露攻击细节和源站 IP，等于给对手实时反馈。
- 不要在攻击中做架构变更：换证书、升内核、改路由这类动作留到平稳期，故障叠加时你没法判断是谁引起的。
Q：业务侧怎么同步信息？
- 15 分钟内发出第一条告知，必须带一个「下次更新时间」，否则客服和群里会被问爆。
- 状态页返回 503 加 Retry-After，不要返回 200 空白页，后者会被搜索引擎判低质。
- 内部同步一条信息就够：影响范围、当前动作、下次更新时间、谁在决策。
Q：攻击停了，24 小时内要做什么？
- 别急着拆防护。二次波很常见，撤规则至少要等 24 小时平稳。
- 补数据：峰值带宽与 pps、攻击类型、持续时长、被绕过的点。这些是下次采购和加固的依据。
- 处理暴露面：源站 IP 泄露过就换 IP，顺带把历史解析记录、证书、邮件头过一遍。别只换一半，漏一个地方等于没换。
- 把这次的峰值和阈值对一遍：清洗阈值高于攻击峰值，说明平时设得太松；低于日常峰值，说明会被自己的业务流量触发。
# 按分钟统计请求量，找出攻击时段峰值
awk '{split($4,t,":"); m=t[2]":"t[3]; c[m]++}
END{for(k in c) print k, c[k]}' /var/log/nginx/access.log \
| sort -k2 -rn | head -10Q：复盘报告怎么写才有用？
- 五段结构：时间线、影响面、处置动作、根因、改进项。
- 全部用数字：几点几分、多少 Gbps、多少 pps、掉线多少分钟、损失多少订单。形容词在复盘里没有价值。
- 改进项必须带责任人和截止时间，否则复盘等于开了个会。
- 报告存档。下次续费、下次换供应商，这份材料比销售话术有力得多。
Q：还有什么补充建议？
- 提前按这条时间线做一次桌面推演，比出事时翻文档有效得多。
- 联系人清单要离线可查：高防供应商 7×24 电话、机房、DNS 服务商，别只存在某个人的聊天记录里。
- DNS TTL 平时就设短（300 秒以内），攻击来了你才有快速切换的余地。
- 最后一句：DDoS应急的水平，不取决于你买了多少 G 防护，取决于第 5 分钟做对了什么。