适用场景

应急响应的核心是「先止血、再查因、后加固」。顺序错了会两头耽误：一边忙着找原因，一边数据还在被外传/加密。所以流程要固化，第一步永远是隔离与保全证据。

配置步骤（证据采集与保存）

# 采集顺序：易失 -> 持久
# 1) 内存（先用可信工具或内存取证工具 dump）
#    Linux: /proc/kcore / LiME / AVML
#    Windows: winpmem 等

# 2) 网络连接与路由
ss -antp > /evidence/netstat.txt
ip addr > /evidence/ip.txt
ip route > /evidence/route.txt
arp -an > /evidence/arp.txt

# 3) 进程与启动项
ps auxf > /evidence/ps.txt
crontab -l > /evidence/cron.txt
systemctl list-unit-files --state=enabled > /evidence/services.txt

# 4) 日志（本机 + 集中平台）
cp -a /var/log/messages* /var/log/secure* /evidence/logs/ 2>/dev/null || true

# 5) 文件与磁盘（必要时做镜像）
dd if=/dev/sda of=/evidence/disk.img bs=4M status=progress

# 6) 记录哈希
sha256sum /evidence/* > /evidence/checksums.txt

关键参数与建议

  • 分级：按影响范围与数据敏感度分 P1-P3，P1 立即上报并启动指挥
  • 隔离：断网（保留电源）、停服务、封账号，动作要可回退且留记录
  • 证据保全：内存、日志、进程、网络连接、磁盘镜像按顺序采集，先易失后持久
  • 取证纪律：不关机（除非必要）、不删除文件、操作全程记录时间戳
  • 排查方向：入口（漏洞/弱口令/钓鱼）、持久化（计划任务/服务/启动项）、横向（账号/信任关系）
  • 清除与恢复：清除前先确认入口已封堵，否则清完还会再进来
  • 加固与复盘：补漏洞、改口令、加检测规则，形成事件报告与改进项
  • 上报：按合规要求向主管部门/监管报送，保留报送记录

容易踩的坑

  • 采集前重启，内存证据消失
  • 用被入侵主机上的工具采集，工具可能被替换
  • 只拷日志没算哈希，证据可信度被质疑
  • 采集顺序颠倒，易失证据（内存/连接）先丢
  • 证据存在被入侵主机上，被攻击者删除
  • 时间戳不记录，时间线无法建立

验证与巡检

# 证据完整性检查
1) 每个证据文件有 sha256 记录
2) 采集时间、执行人、来源主机有登记
3) 副本存放于可信介质（离线/只读）
4) 集中日志平台数据已单独导出
  • 巡检：证据清单与哈希、保管记录、离线副本、集中日志导出成功

小结

应急响应验收：能在 30 分钟内完成隔离与关键证据采集，事后有完整时间线与事件报告，且改进项全部闭环。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。