Incident 响应

这一课你将能做到

1. 说清 NIST 定义的事件响应生命周期六阶段，并给每个阶段列出 3 个具体动作
2. 为本站写一个数据库泄露的应急响应 Runbook，包含遏制步骤（每一步的可操作命令）
3. 解释「遏制」和「根除」的区别，避免「以为删了恶意文件就安全了」的常见错误

为什么要学

再强的防御也可能被绕过。真正的安全成熟度不在于你防住了多少攻击，而在于你被攻破后，多久能发现、多久能止血、多久能恢复。很多公司的响应手册就一页纸：「重启试试」——这是灾难。

人话：事件响应（IR）就像消防演习。事前准备：灭火器在哪、疏散路线怎么走；事发时：先报警、再疏散、最后灭火；事后复盘：为什么起火、烟感为什么不响、下次怎么改进。IR 不是技术问题，是流程和纪律。

先建立图像

NIST SP 800-61 事件响应生命周期：

准备 ──→ 检测与分析 ──→ 遏制 ──→ 根除 ──→ 恢复 ──→ 事后复盘
 │           │             │         │         │           │
 │           │             │         │         │           │
Runbook   SIEM告警       断网      清后门    重建    改进+追责
演练       人工上报       改密码    打补丁    重部署  写报告
联系人表   取证分析       冻结账号  修漏洞    验证    更新预案

场景：发现数据库被拖库后的时间线：

T+0min   SIEM 告警: 异常大量 SELECT * FROM users
T+2min   值班人员确认告警属实
T+5min   遏制: ① 切流量到备用库 ② 冻结异常连接 ③ 轮换凭证
T+15min  根除: 溯源入口漏洞(SQL注入)→修代码→测试→打补丁
T+30min  恢复: 新库上线→数据校验→逐步恢复流量→监控异常
T+2h     复盘: 会议→报告→措施→责任人
T+7d     合规通知: 72小时监管窗口期(如适用)

跟着做

步骤 1：建立基础 Runbook（数据库泄露场景）

Runbook 是「遇事不慌」的底气。写清每一步、谁做、联系方式、超时升级。

# Runbook: 疑似数据库数据泄露
触发条件：SIEM 告警「异常查询量」、用户投诉数据出现在暗网、
         日志发现陌生 IP 大量连接 MySQL

## 阶段 1：检测与确认（0-5 分钟）
1. 值班人员查看 SIEM 告警详情：IP、时间、查询语句、影响范围
2. 联系应用负责人确认是否为正常业务行为（批量导出？数据迁移？）
3. 非值班时间自动拨打值班手机，5 分钟未响应升级到二线

## 阶段 2：遏制（5-15 分钟）
1. 改数据库密码（所有账号，不是只改 root）
   ALTER USER 'app'@'%' IDENTIFIED BY '新强密码';
   ALTER USER 'app_readonly'@'%' IDENTIFIED BY '另一个新密码';
   FLUSH PRIVILEGES;

2. 在数据库层断开所有现有连接（不包括管理连接）
   SHOW PROCESSLIST;  -- 找到异常连接的 ID
   KILL <连接ID>;

3. Nginx 层把流量切到维护页（保留取证日志）
   return 503;

4. 轮换所有相关密钥：
   - JWT 签名密钥 → 所有旧 token 失效
   - Redis 密码
   - 第三方 API Key（支付、短信等）
   - 服务器 SSH key（如果怀疑主机被入侵）

5. 快照备份（用于取证分析，不是恢复用）
   - 数据库完整备份
   - 服务器磁盘快照（系统盘+数据盘）
   - 相关日志文件打包拷贝到隔离存储

## 阶段 3：根除（15-60 分钟）
1. 溯源：从入侵点反推
   - 最后一条正常查询是什么时间？
   - 异常查询的第一个来源 IP？
   - 应用日志里同一时段有什么异常请求？（如 `/api/search?q=' OR 1=1`）

2. 修复漏洞：
   - 如果是 SQL 注入 → 改参数化查询
   - 如果是弱密码 → 改强密码 + MFA
   - 如果是未打补丁 → 立即升级

3. 验证修复：
   - 用原 payload 再次尝试，确认被拦截
   - 扫描全代码库同类漏洞
   - Dependabot/扫描器确认无已知 CVE

## 阶段 4：恢复（60-120 分钟）
1. 从可信备份重建数据库（不要用被拖库的数据库直接恢复）
2. 数据完整性校验：记录数、校验和抽样比对
3. 逐步恢复流量（10% → 50% → 100%），持续监控
4. 前 24 小时加强监控频率：每 5 分钟看一遍关键指标

## 阶段 5：事后复盘（24-72 小时）
1. 时间线：精确到分钟的入侵→发现→遏制→根除→恢复时间线
2. 影响评估：哪些数据被访问/修改/删除？涉及多少用户？
3. 根因：漏洞为什么存在？为什么没有提前发现？（检测盲区？无扫描？）
4. 改进措施：每个措施必须有负责人和截止日
5. 合规：确认是否触发数据泄露通知义务（GDPR/个人信息保护法 72 小时）

步骤 2：建立联系人表和升级链

第一响应人：运维值班（7×24）
  ↓ 5 分钟未响应
第二响应人：安全负责人
  ↓ 15 分钟未响应
第三响应人：CTO + 法务（如涉及数据泄露）

外部资源：
- 云厂商安全团队（主机被入侵时）
- 法务（数据泄露通知义务）
- PR（用户通知文案）
- 监管报备渠道（如触发）

步骤 3：取证证据收集

证据收集必须在遏制之前或同时完成，遏制后攻击者可能清理痕迹：

# 系统层面
netstat -tulpn > /tmp/evidence_netstat.txt   # 网络连接
ps aux > /tmp/evidence_ps.txt                # 进程列表
cat /var/log/auth.log > /tmp/evidence_auth.log   # 登录日志
last > /tmp/evidence_last.txt                # 登录历史

# 数据库层面
SHOW FULL PROCESSLIST;                        # 活动连接
SHOW BINLOG EVENTS LIMIT 50;                 # binlog 近期变更
SELECT * FROM information_schema.processlist WHERE host NOT LIKE '127.0.0.1%';

# 打包
sudo tar czvf /tmp/incident-$(date +%Y%m%d-%H%M%S).tar.gz \
  /tmp/evidence_* /var/log/nginx/ /app/logs/

# 复制到隔离存储（不可被当前服务器删除的）
ossutil cp /tmp/incident-*.tar.gz oss://coderoadmap-incident-archive/

步骤 4：DDoS 快速缓解

如果遭遇流量型 DDoS，和数据库泄露不同，遏制要快，不需要溯源：

1. 启用云厂商 DDoS 防护（阿里云 DDoS 基础防护 / AWS Shield）
2. CDN 层开启「源站保护」：只回源正常流量
3. Nginx 层紧急限流：
   limit_req_zone $binary_remote_addr zone=ddos:10m rate=10r/s;
   location / { limit_req zone=ddos burst=20 nodelay; }
4. 临时封禁异常 IP 段
5. 启用 Web 缓存（CDN），减轻源站压力

步骤 5：定期演练（桌演）

每季度做一次桌面演练：

场景：某用户在暗网发现自己信息
角色分配：值班人员、安全负责人、开发、运维、法务
模拟：SIEM 告警→确认→遏制→根除→恢复→复盘
观察点：
- 值班人员是否知道先看哪条日志？
- 改密码的 ALTER 语句是否熟练？
- 升级链是否通畅？
- Runbook 是否过时（如 IP 变了、联系方式改了）？

讲清楚要点

1. 遏制 ≠ 根除：遏制是「先止血」——断连接、改密码、切流量，让损害不再扩大。根除是「治病因」——找到漏洞并修复。很多新手删了 webshell 就以为安全了，其实攻击者留了 3 个后门、改了 cron 任务，两周后又回来。

2. 快照在遏制前做：为了取证，必须保留攻击发生时的系统状态。一旦开始「修复」，日志可能被覆盖、文件被删除。快照是时间胶囊。

3. 轮换密钥要全量：只改数据库密码不够，攻击者可能已经拿到了 JWT 密钥、Redis 密码、第三方 API Key。假设所有凭证都已泄漏，全量轮换。

4. 72 小时窗口期：个人信息保护法、GDPR 要求数据泄露后 72 小时内通知监管。这要求你的 IR 流程必须能在 72 小时内完成影响评估——前提是日志完整、溯源能力强。

5. 复盘不追责：Blameless Postmortem。复盘目的是改进系统，不是找替罪羊。攻击者能成功，是因为系统有漏洞，不是人的「失误」。追责文化会让下一次事件被隐瞒。

你可能会懵的地方

• P1/P2/P3 优先级怎么定？ P1（严重）：数据泄露、勒索软件、核心服务宕机——立即全员响应。P2（高）：单个服务不可用、影响部分用户——30 分钟内响应。P3（中）：安全告警待验证、低风险漏洞——排期处理。不同公司定义不同，但必须在 Runbook 里写明。

• 勒索软件要不要付赎金？ 行业标准是「不建议付」：付赎金不保证恢复、可能助长犯罪、且解密工具本身可能有后门。如果你有备份能恢复，坚决不付；如果完全没备份且业务关键，这是一个商业决策（非纯技术），需要和法务、管理层一起决定。

• 攻陷后需要重装系统吗？ 生产环境建议「重建而非修复」——从可信基线镜像重新部署，恢复数据。因为攻击者可能改了系统二进制、植入 rootkit，你无法「确认」修干净了。重建是唯一能证明干净的手段。

• 日志被删了怎么办？ 如果实时外发到独立日志平台（SIEM），攻击者删不了。如果日志只存在本地，删除后极难恢复。这就是为什么要配置 Filebeat 实时外发到 Elasticsearch/OSS，且日志服务账号独立。

• 复盘报告给谁看？ 内部：安全团队、管理层、涉事开发团队。外部（视情况）：监管、用户（数据泄露通知）、董事会。注意措辞：事实+时间线+改进措施，不推卸责任、不披露过多技术细节（防止被二次利用）。

错法对照

错法	问题	正解
先修漏洞再保存证据	无法溯源	先快照取证，再遏制根除
只改 root 密码	攻击者可能用了 app 账号	全量轮换所有凭证
删了恶意文件就算根除	后门/定时任务/SSH key 还在	重建系统，从可信基线恢复
不通知法务/监管	触发 72 小时通知义务	IR 流程含合规评估节点
复盘时追责个人	下次事件会被隐瞒	Blameless，改进系统而非人
没有 Runbook，遇事现查	延误黄金遏制时间	事前写好、定期演练

卡点急救

1. ALTER USER 改密码后应用连不上：Spring Boot 连接池有缓存的旧密码，需要重启应用。提前准备：改密码后统一重启所有实例，或直接用连接池的「密码热刷新」机制（如 HikariCP 配合 Vault 动态凭证）。

2. 恢复后用户仍然报「数据不对」：可能是恢复时间点选太早（丢失了一些正常写入）或选太晚（包含了攻击者的恶意修改）。解法：恢复后做数据校验（记录数、关键表抽样），对比攻击前最后一个可信备份。

3. 取证时服务器被攻击者锁了（改了 root 密码）：靠云厂商控制台重置密码（阿里云 VNC 控制台），或靠快照启动新实例分析。这就是为什么要实时外发日志——主机被锁了，日志还在 SIEM 里。

面试常问

• 事件响应的六个阶段是什么？ NIST SP 800-61：① 准备（预案、演练、工具）；② 检测与分析（SIEM、日志、人工上报）；③ 遏制（短期：止血，长期：隔离受影响系统）；④ 根除（找到根因并修复）；⑤ 恢复（从可信备份重建，逐步恢复服务）；⑥ 事后复盘（时间线、影响评估、改进措施、合规通知）。

• 遏制和根除有什么区别？ 遏制是「不让损害继续扩大」，动作包括：改密码、断连接、切流量、封 IP。根除是「消除入侵原因」，动作包括：修漏洞、删后门、打补丁、重建系统。先遏制后根除，顺序不能颠倒——否则修漏洞时攻击者还在系统里看着你操作。

• 发现数据库泄露后，第一时间做什么？ 按顺序：① 确认告警（排除误报）；② 快照取证（保存当前状态）；③ 遏制（改密码、断连接、切流量、轮换凭证）；④ 评估影响范围（哪些数据、多少用户）；⑤ 根除（溯源漏洞→修复）；⑥ 恢复（重建→验证→逐步上线）；⑦ 合规通知（72 小时窗口）；⑧ 复盘。

自测三问

1. 为什么「先修漏洞再保存证据」是错误的？正确顺序是什么？
2. 发现泄露后只改数据库密码够不够？为什么？
3. 复盘为什么要 Blameless？追责文化会导致什么后果？

小结一句话

事件响应不是救火技巧，是事先写好的 Runbook 和演练出的纪律：先止血、再治病、重建比修复更可靠、复盘只改系统不追责。

延伸

• NIST SP 800-61 计算机安全事件处理指南
• 下一课：合规与扫描——SOC 2、ISO 27001、NIST 框架，以及把「安全要求」变成「可审计的证据」。