# 应急响应

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

- 作者：David（道雾轩）
- 专栏：网站安全一本通（https://daiw.net/manual/web-security.md）
- 最后更新：2026-08-11
- 原文：https://daiw.net/manual/web-security/incident-response
- 转载与引用：请注明出处并附原文链接（https://daiw.net/about/copyright）

# 应急响应

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

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

## 六个阶段

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

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

## ① 准备（现在就做）

### 一份写下来的应急信息卡

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

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

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

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

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

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

### 提前想清楚一个问题

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

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

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

## ② 发现与确认

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

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

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

## ③ 遏制：先止血

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

<Callout type="warn">
  **经典两难：先取证还是先断网？**

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

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

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

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

按情况选择遏制手段：

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

**同时保存证据**：

```bash
# 内存镜像（如果有条件，在隔离后立刻做）
# 磁盘镜像
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
```

## ④ 根除

**这一阶段最重要的原则**：

<Callout type="warn">
  **被完全控制过的服务器，不要「清理干净后继续用」——重装。**

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

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

根除清单：

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

## ⑤ 恢复

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

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

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

**恢复数据时的关键判断**：

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

## ⑥ 复盘

<Callout type="info">
  **复盘必须是「对事不对人」的（blameless）。**

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

  **要回答的问题**：

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

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

## 涉及用户数据时

这不再只是技术问题：

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

## 一个人的最小预案

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

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

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

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

## 小结

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

专栏正文到此结束。最后给一份可以逐条打勾的清单。👉 [上线安全检查清单](https://daiw.net/manual/web-security/checklist)
