DDoS恢复演练：从被打到恢复服务的90分钟流程

线上业务最怕的不是「有没有装防火墙」，而是故障真的发生时，管理员不知道先关哪个端口、先联系谁、先恢复哪份备份。本文换一个角度，不再重复讲 DDoS（分布式拒绝服务攻击）、防火墙和备份分别怎么配置，而是用一套 90 分钟演练流程，说明如何把这些配置串成可执行的恢复预案。

适用场景很明确：一台公网业务服务器突然出现大量异常连接，网站 5xx 增多，SSH（安全外壳协议）登录变慢，监控显示入口流量比平时高出 5-10 倍。你需要做的不是临时翻教程，而是按顺序完成分流、止血、取证、恢复和复盘。

前 10 分钟：先判断是攻击、故障还是配置变更

故障开始后的前 10 分钟决定后面是否会乱。很多人第一反应是重启服务器，但在 DDoS 场景下，重启只能让连接数短暂归零，攻击流量还在，服务很快又会被打满。更稳妥的做法是先用三类指标定位问题边界。

• 入口流量：看机房或控制面板的 Mbps、pps 曲线，如果 5 分钟内突增到平时 5 倍以上，优先怀疑流量型攻击。
• 连接状态：执行 ss -ant | awk '{print $1}' | sort | uniq -c，如果 SYN-RECV 或 TIME-WAIT 异常堆积，说明连接层已经承压。
• 应用错误：检查 Nginx（高性能 Web 服务器）或 Apache（Web 服务器）日志中的 499、502、504，占比超过 20% 时要同时处理应用层限速。
• 最近变更：确认过去 2 小时内是否改过 DNS（域名解析系统）、WAF（Web应用防火墙）、安全组或 CDN（内容分发网络）规则，避免把配置事故误判成攻击。

这里的关键是留下时间戳。建议在工单或内部群里固定记录「发现时间、峰值流量、错误码占比、当前动作」。后续无论是和机房沟通，还是做事后复盘，这些记录都比口头描述可靠。

10-30 分钟：把攻击流量挡在源站之前

判断入口已经异常后，下一步不是在服务器上无限加规则，而是尽快让清洗层或代理层接管。源站 CPU（中央处理器）和网卡资源有限，攻击流量如果已经打满上游链路，本机 iptables 规则再精细也来不及执行。

如果业务前面已有 CDN（内容分发网络）或高防入口，先把站点切到「仅代理访问源站」模式：源站防火墙只允许代理节点 IP 访问 80/443，其他公网来源全部拒绝。没有代理层时，应立即联系机房开启清洗，并提供目标 IP、攻击开始时间、协议类型和峰值截图。多数服务商处理清洗请求时，最需要的是这些可验证信息，而不是一句「网站打不开」。

源站侧可以同时做最小化止血，重点是只保留必要端口：

只允许已知管理 IP 访问 SSH
iptables -A INPUT -p tcp --dport 10022 -s 203.0.113.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 10022 -j DROP

对 ICMP 做基础限速，避免 ping flood 消耗资源
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

这类规则的目标不是「彻底抗住攻击」，而是为清洗切换争取 10-20 分钟窗口。更多高防节点选择和攻击类型差异，可以参考 WHT 社区的美国高防服务器哪家强：DDoS防护能力深度对比，但在故障现场，先恢复业务入口比横向比较更重要。若演练中需要记录带宽（网络传输容量）或防护费用，也要在表格旁写清「价格截至 2026 年 7 月，以官网实时价格为准」，避免半年后继续沿用旧报价。

30-60 分钟：收敛端口，同时保留取证信息

入口压力缓下来后，很多团队会立刻宣布恢复。这个判断太早，因为攻击期间可能已经暴露了弱口令、面板端口或数据库端口。30-60 分钟这一段要做的是端口收敛和取证，避免攻击结束后留下更大的安全洞。

先跑一次监听端口清单：

ss -tulpn | grep LISTEN
journalctl -u ssh --since "60 minutes ago" | tail -100
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

看到 3306（MySQL 数据库）、21（FTP 文件传输协议）、25（SMTP 邮件传输协议）这类端口暴露公网时，不要只在面板里点关闭，最好同步检查系统层防火墙和云端安全组。两层规则不一致时，常见结果是面板显示已关闭，但公网扫描仍能看到端口。

接着处理登录面：禁用 SSH 密码登录，保留密钥；把 fail2ban 的封禁时间设置到 24 小时；把面板登录入口限制到固定办公 IP 或 VPN（虚拟专用网络）。如果你还不熟悉 Linux（开源操作系统）基础防火墙，可以先看 WHT 的技术教程分类，再把 UFW、iptables 和面板规则统一到一张清单里。

60-90 分钟：验证备份能恢复，而不是只看文件存在

攻击不一定会破坏数据，但恢复演练不能跳过备份验证。很多事故真正扩大，是因为管理员以为每天都有备份，结果恢复时才发现数据库缺表、文件权限错了，或者远程备份目录已经连续 7 天同步了空文件。

这里建议做一次轻量恢复验证，不直接覆盖生产环境。步骤可以控制在 30 分钟内：拉取最近一份数据库备份到临时目录，检查 gzip 是否能解压；用 mysql --force 导入到临时库；抽查核心表数量；再恢复一份网站目录到测试路径，确认文件属主和权限没有丢失。

gzip -t /backup/20260715/mysql_all.sql.gz
mysql -u root -p test_restore < /backup/20260715/mysql_all.sql
find /backup/20260715/www -type f | wc -l
rsync -n -av /backup/20260715/www/ /tmp/restore-check/

如果这四个检查都能通过，说明备份至少具备「可读取、可导入、可枚举、可复制」四个基本条件。更完整的安全链路，可以延伸阅读使用美国虚拟主机对网站安全的影响，里面讨论了自动备份、补丁管理和恢复验证之间的关系。

复盘：把一次救火变成下一次的检查表

一次演练结束后，真正有价值的是复盘清单。建议把结果写成 5 个字段：攻击开始和结束时间、峰值流量、受影响服务、手动操作命令、后续整改项。下次再遇到同类问题，值班人员可以直接按清单执行，而不是靠经验临场发挥。

• 入口层：清洗或代理切换是否在 10 分钟内完成，DNS（域名解析系统）生效时间是否可接受。
• 源站层：SSH（安全外壳协议）、数据库、面板端口是否符合最小暴露原则。
• 应用层：限速规则是否误伤正常用户，错误码是否在恢复后 15 分钟内回落。
• 备份层：最近 1 份备份是否通过解压、导入、文件数量和权限抽查。
• 沟通层：机房工单、内部通知和客户说明是否有固定模板。

总结一下，DDoS恢复演练的重点不是把每条安全规则写得多复杂，而是让入口清洗、防火墙收敛、日志取证和备份验证形成闭环。如果你需要托管在更省心的环境里，可以选择带中文支持和可选防护能力的服务作为候选，但仍建议按本文流程每季度演练一次。安全不是一次配置完成，而是每次故障前都能证明自己恢复得回来。