服务器疑似被入侵后的第一小时：别急着删，先保住事实

事故现场像打翻墨水的书桌：第一反应若是用力擦，可能连原本写了什么也一起抹掉。

发现未知进程、异常登录、CPU 突增或文件被改时，很多人的第一反应是重启、杀进程、删除文件、立刻升级。这样可能暂时安静，却会破坏内存状态、时间线和攻击路径，也可能让仍然存在的入口躲起来。事件响应的第一目标不是马上恢复洁净感，而是控制影响并保留足够事实。

NIST 在 2025 年发布 SP 800-61 Rev.3，把事件响应放进整个风险管理循环，而不是孤立的“出事后流程”。对个人服务器也适用：准备、发现、响应、恢复和复盘彼此连接。流程不必厚重，但顺序必须清楚。

先判断是否仍在扩散

确认哪些系统、账号和服务受到影响。若存在持续外联、批量加密或横向移动，优先隔离网络或受影响容器。隔离不等于立刻关机：断网可以保留内存和进程证据，直接断电会失去易失信息。只有无法阻止破坏继续时，才把停机放在证据之前。

使用另一条可信通信渠道记录操作，不要在可能被监控的主机上讨论所有应对计划。个人场景可以是本地离线笔记或另一台设备。每一步写时间、执行者、命令和结果，哪怕执行者只有自己，之后也能还原因果。

建立最小证据包

保存当前时间、登录用户、进程树、网络连接、监听端口、最近认证日志、systemd 服务、容器列表、镜像 ID、挂载、计划任务和关键文件哈希。不要一上来运行全盘杀毒或递归压缩，它们会制造大量磁盘读取、改变访问时间，甚至把小服务器拖死。

日志应复制到只读或远端位置，并记录来源路径和哈希。云平台操作日志、DNS 修改记录、Registry 拉取记录和登录 IP 也属于证据。应用日志可能被攻击者删除，因此跨系统时间线比单一日志更可信。

凭据轮换要按依赖顺序

如果怀疑主机 root 已失守，不能在同一主机上生成新密钥，因为攻击者可能继续读取。先从可信设备撤销云账号、DNS、代码仓库和备份访问，再处理应用 Token 和用户密码。优先保护能重置其他身份的上游账户。

轮换时记录旧 Key 的最后使用时间和来源，能帮助判断是否被滥用。不要只改 SSH 密码，却保留攻击者创建的 authorized_keys、sudoers、systemd unit、cron 或容器。身份恢复必须和持久化排查一起进行。

清理还是重建

当攻击者获得 root、Docker socket 或未知持久化能力时，从可信镜像重建通常比在原系统“打扫干净”更可靠。清理适合影响明确、边界清楚的事件；重建适合信任根已经破坏。备份恢复时只带回确认过的数据和配置，不要把未知二进制、启动脚本和旧 Token 原样搬回。

重建前保留磁盘快照供后续分析，但不要让快照继续对公网启动。新环境先修复初始入口，再恢复业务，否则只是把相同漏洞搬到干净机器上。

恢复后的七天

提高日志保留和告警敏感度，观察旧凭据、旧 IP、异常 User-Agent 与失败任务。检查账单、出站流量和新建资源，因为攻击影响可能不在主机文件里。把事件时间线、根因、有效控制和失效控制写成简短复盘。

AI 可以帮助整理大量日志和构建时间线，但不要让模型把“没有看到”写成“没有发生”。每个结论附上证据路径和置信度，保留相互矛盾的信号。事故报告首先是事实仓库，其次才是叙事。

个人服务器也值得准备一个事件包

提前准备一份只读采集脚本、服务器资产表、云控制台入口、关键账号撤销链接和离线联系方式。脚本只收集状态，不自动修复；每次系统升级后运行一次，确认命令仍然有效。真正出事时，大脑会倾向于做熟悉但未必正确的动作，预先写好的顺序能降低这种压力偏差。

事件包还应记录哪些数据不允许上传外部分析平台。日志里可能含有用户信息和 Token，紧急时更容易因为求助而二次泄露。准备好脱敏脚本和安全传输方式，是响应能力的一部分。

可以直接照着做的检查清单

• 先隔离持续破坏，再决定是否关机，避免无意义重启。
• 记录时间线并保存进程、网络、认证、计划任务和容器证据。
• 从可信设备撤销上游账号与 Token，再处理主机内凭据。
• 检查 SSH key、sudoers、systemd、cron 和容器持久化。
• root 或 Docker 控制面失守时优先从可信镜像重建。
• 恢复后持续观察七天，并用证据和置信度撰写复盘。

延伸阅读

• NIST SP 800-61 Rev.3 Incident Response
• CISA StopRansomware Response Checklist
• Docker Daemon Logs
• MITRE ATT&CK

事件响应的专业感，不来自命令多，而来自顺序稳定：控制、保全、判断、恢复，然后让同一条路不再被走第二次。