应急响应

出事时最贵的是犹豫——一份可以照着执行的六阶段流程、「先取证还是先断网」这个经典两难怎么判、以及个人站也能提前十分钟准备好的应急包。

安全事件的处置质量，几乎完全取决于事前准备。事发当下人是慌的、判断是差的、时间是不够的——你能依靠的只有提前写好的东西。

这一章给一份可以照着执行的流程。

六个阶段

① 准备 → ② 发现与确认 → ③ 遏制 → ④ 根除 → ⑤ 恢复 → ⑥ 复盘

① 准备是唯一可以从容做的阶段，也是决定其余五个阶段能否顺利的关键。

① 准备（现在就做）

一份写下来的应急信息卡

放在不依赖你自己系统的地方（因为出事时你的系统可能正好用不了）：

【联系人】
  谁能决定「下线服务」            —— 姓名、电话
  谁有域名注册商账号             —— 姓名、电话
  谁有云账号的最高权限           —— 姓名、电话
  云厂商工单入口 / 客服电话
  法务或合规联系人（涉及用户数据时）

【系统清单】
  域名与注册商、DNS 托管方
  服务器 IP / 云资源清单
  数据库位置、备份位置与恢复方式
  第三方服务清单（支付、短信、OAuth）

【应急凭据】
  离线保存的一份紧急访问方式（硬件密钥备份 / 打印的恢复码）

最容易出问题的是「只有一个人有关键账号」。 那个人休假、手机丢了、或者恰好就是被社工的对象——整个响应就卡住了。

至少要有两个人能访问域名注册商和云账号，且恢复码离线备份（打印出来放保险柜，不是存在那台可能被加密的电脑里）。

提前想清楚一个问题

「什么情况下我们会主动下线服务？」

事发当下讨论这个问题，会因为「怕影响业务」而拖延。提前定好触发条件：

确认数据正在被批量外传 → 立即断
确认服务器被植入后门 → 立即隔离
疑似但未确认 → 先加强监控，不下线

② 发现与确认

收到告警或外部报告后，第一件事是确认真实性，不要立刻拔网线（除非命中上面的触发条件）。

# 快速体检
who                                   # 有谁登录着
last -20                              # 最近登录记录
ps auxf                               # 异常进程（尤其是父进程为 1 的）
ss -tulpn                             # 异常监听端口
crontab -l; ls -la /etc/cron.*        # 计划任务后门
find /var/www -newermt "-24 hours" -type f    # 24 小时内变更的 Web 文件

记录你做的每一步和时间。这不只是给事后复盘用——如果涉及法律程序，操作记录本身就是证据链的一部分。

③ 遏制：先止血

这个阶段的目标是阻止损失扩大，不是查清原因。

经典两难：先取证还是先断网？

先断网 → 止损快，但内存里的证据（正在运行的恶意进程、网络连接、解密后的载荷）会丢失。
先取证 → 证据全，但攻击者还在里面继续搞。

给绝大多数场景的建议：先隔离，不要关机。

「隔离」是把机器从网络里摘出来（改安全组、断网卡），但保持运行。这样既切断了攻击者的通路和数据外带，又保住了内存中的证据。

关机是最糟的选择——它同时丢失内存证据，而且不比隔离更安全。

按情况选择遏制手段：

情况	动作
单台服务器被控	从负载均衡摘掉 + 网络隔离，保持运行
凭据泄露	立即轮换（密钥那章讲过，这是唯一止血动作）
某个账号被盗	强制登出该用户所有会话 + 冻结账号
正在被拖数据	收紧数据库权限 / 断开应用与数据库
域名被劫持	联系注册商，走紧急申诉通道
大面积沦陷	触发预案，整体下线并挂公告页

同时保存证据：

# 内存镜像（如果有条件，在隔离后立刻做）
# 磁盘镜像
dd if=/dev/sda of=/mnt/evidence/disk.img bs=4M status=progress

# 至少把日志复制出来（复制到别的机器，不要留在可能被清的机器上）
tar czf /mnt/evidence/logs-$(date +%s).tar.gz /var/log /var/www/*/logs

④ 根除

这一阶段最重要的原则：

被完全控制过的服务器，不要「清理干净后继续用」——重装。

理由很实在：你无法证明自己找全了所有后门。攻击者可能改了系统二进制、加了内核模块、在计划任务/systemd unit/.bashrc/SSH authorized_keys 里留了多处持久化。漏掉一处，几周后他就回来了——而且这次他知道你在看什么。

容器化的一个巨大好处正在这里：重建一个容器是几分钟的事，从可信的镜像重新拉起，干净利落。这也是为什么「不可变基础设施」是安全实践而不只是运维实践。

根除清单：

找到并修复入口漏洞（没修这个，重装也白搭）
从可信来源重装/重建系统
轮换所有可能接触过的凭据——数据库密码、API key、SSH 密钥、云凭据、会话密钥
检查并清理持久化点：cron、systemd、authorized_keys、启动脚本、容器镜像
强制所有用户重新登录（使全部会话失效）
如果密码哈希可能泄露，强制用户改密码

⑤ 恢复

分阶段恢复，不要一次性全放开：

1. 在隔离环境重建 → 验证功能与安全配置
2. 小流量灰度 → 密切监控
3. 逐步放开
4. 保持高强度监控至少 2 周

为什么要监控两周：攻击者常常会回来试探。这段时间的告警阈值应该调低，宁可多几次误报。

恢复数据时的关键判断：

备份是在入侵之前还是之后做的？
如果不确定入侵时间点，往前多回溯几个版本
备份里可能已经包含了后门——恢复后要重新检查

⑥ 复盘

复盘必须是「对事不对人」的（blameless）。

如果复盘会变成追责会，下一次有人发现异常时会倾向于隐瞒或自己偷偷处理——而这会让下一次事故严重十倍。

要回答的问题：

怎么进来的？ 具体到哪个漏洞、哪个配置、哪个流程缺口。
为什么没早点发现？ 缺哪条监控？告警响了但被忽略了吗？
影响范围到底多大？ 基于日志给出结论，不要靠猜。
哪些措施本可以阻止或减轻？ 对应到具体的待办。
同类问题在别处还有吗？ ——这一条最容易漏，也最有价值。 一个越权漏洞往往不止一处。

产出必须是带负责人和截止日期的行动项，不是一份感想。

涉及用户数据时

这不再只是技术问题：

法律义务：中国有《个人信息保护法》《数据安全法》《网络安全法》，欧盟有 GDPR（72 小时内报告），各地要求不同——提前搞清楚适用于你的规则。
通知用户：说清楚泄露了什么、可能的影响、用户该做什么（改密码、留意可疑信息）。
诚实：隐瞒或淡化造成的二次伤害，通常远大于事件本身。 用户能原谅一次事故，很难原谅一次欺骗。

一个人的最小预案

如果你就是一个人维护一个个人站，把这些准备好就够了：

1. 域名注册商与云账号的恢复码 —— 打印出来，离线保存
2. 一份写下来的系统清单（域名、服务器、数据库、第三方服务）
3. 备份能恢复 —— 而且亲手演练过一次
4. 知道怎么快速下线：
   - 把 DNS 指向一个静态公告页，或
   - 在 CDN 上开「维护模式」
5. 服务器重建脚本 / Docker Compose 文件在 git 里 —— 能快速在新机器上拉起

第 3 条的「亲手演练过一次」是重点。没恢复过的备份，只是一堆你以为能用的文件——真到用的时候才发现格式不对、缺文件、或者密码忘了，这种事非常常见。

第 5 条也很实在：本站（daiw）的两条产线都是 Docker + git 里的 compose 文件，理论上换一台机器几分钟就能重建。这种可重建性本身就是安全能力——它让「重装而不是清理」变成一个容易做的选择。

小结

处置质量取决于事前准备，事发当下人是慌的。
应急信息卡要放在不依赖自己系统的地方；关键账号至少两个人能访问。
遏制阶段：先隔离，不要关机——保住内存证据，同时切断通路。
被完全控制过的服务器要重装，不要清理后继续用；容器化让这件事变得廉价。
根除必须先修入口漏洞，并轮换所有可能接触过的凭据。
恢复后高强度监控两周，攻击者常会回来试探。
复盘必须 blameless，否则下次事故会被隐瞒；最有价值的一问是「同类问题在别处还有吗」。
一个人的最小预案：恢复码离线、系统清单、演练过的备份、快速下线手段、可重建的部署配置。

专栏正文到此结束。最后给一份可以逐条打勾的清单。👉 上线安全检查清单

应急响应

本页目录