很多人第一次发现 VPS 可能被入侵，脑子里只剩两个念头：
- 赶紧关机
- 赶紧改密码
这两个动作听起来都很合理，但真到了应急现场，做错顺序比什么都不做更危险。
因为被入侵后的前 24 小时，最难的不是“知道要做什么”，而是判断：
- 要不要立刻断网？
- 能不能直接重启？
- 应该先保留证据还是先恢复业务？
- 改密码是不是越早越好？
- 这台机还能不能继续信任？
这篇文章就专门解决这几个问题。
我不会给你那种“发现异常就重装系统”的一句话答案，而是给你一套更适合 VPS / Linux 服务器 场景的前 24 小时处置清单：先控风险，再保留证据，再决定重建还是恢复。
如果你只记一句话，就记这个：
发现 VPS 疑似被入侵后，优先隔离网络，而不是第一时间重启或关机。
为什么？
因为一旦你直接：
- 关机
- 重启
- 粗暴清进程
- 立刻删文件
你可能会同时失去最关键的几类证据：
- 内存中的恶意进程
- 当前网络连接
- 攻击者会话状态
- 临时密钥、令牌、解密信息
但另一方面，如果你什么都不做，让服务器继续联网，攻击者可能还在：
- 横向移动
- 持续回连
- 清日志
- 窃取更多数据
所以正确思路通常不是“关不关机”二选一，而是：
- 先隔离网络
- 再保留关键证据
- 再判断是短期止血、长期调查，还是直接重建
这是整篇里最重要的问题。
对大多数 VPS 事件来说，最稳的顺序是：
- 先断开公网访问能力
- 但尽量保持系统不断电、不重启
这意味着你更应该做的是：
- 在云厂商控制台里临时收紧安全组 / 防火墙
- 禁止新入站访问
- 尽量切断可疑出站连接
- 必要时把实例从公网摘掉
而不是直接：
rebootshutdown now
如果你已经看到下面这些信号，隔离网络要优先于一切：
- 持续对外发包、疑似攻击别人
- 正在大规模向外传数据
- 正在横向扫描内网
- 正在被用作代理、钓鱼、垃圾邮件节点
- 业务里有明显的持续入侵活动
这时不隔离，损失只会继续扩大。
如果你面临的是：
- 合规调查
- 涉及客户数据泄露
- 需要追踪攻击路径
- 怀疑是持久化后门或高级入侵
那你就更要克制“立刻重启”的冲动。
因为一旦断电，很多 volatile evidence（易失性证据）就没了。
- 正在造成持续危害 → 先隔离网络
- 需要保留取证价值 → 不要急着关机/重启
- 两者都重要 → 先网络隔离，再做现场保全
这是最关键的止血阶段。
先记下来：
- 异常时间
- 触发告警的来源
- 哪个服务异常
- 哪些账号/端口/进程可疑
这一步看起来简单，但后面复盘、沟通和判断时间线时非常重要。
优先使用：
- 云商防火墙
- 安全组
- 控制台网络规则
目标是：
- 阻断攻击者继续连入
- 阻断可疑出站
- 尽量不破坏现场
这一步必须克制。
不要因为慌张就立刻做这些事：
- 一键杀毒
- 自动修复脚本
- 清空
/tmp - 删 cron
- 直接
apt upgrade
这些都可能污染现场，让你后面既追不到原因，也无法确认影响范围。
如果这台 VPS 在跑生产业务，前 15 分钟就要做一个决定：
- 这台机是否必须立刻下线？
- 有没有备用节点或静态降级页？
- 是否需要把流量切到备机？
别把“业务连续性”留到一个小时后才想起来。
如果已经怀疑 root、sudo 用户、部署账号、面板账号泄露，先暂停使用这些账号继续操作，避免把污染扩大，也避免攻击者借你自己的操作掩盖痕迹。
建议立刻开一个单独的应急记录：
- 谁在什么时候做了什么
- 改了哪条规则
- 导出了哪些日志
- 看到了哪些异常
后面你会非常感谢这一步。
在 Linux / VPS 场景里，前一小时最有价值的不是“赶紧修”，而是“先把关键现场留住”。
- 当前进程列表
- 当前网络连接
- 登录会话与用户活动
- 关键系统日志
- 定时任务、启动项、SSH key、sudo 配置变化
- Web 服务、数据库、面板、容器日志
- 有没有异常进程名
- 有没有可疑父子进程关系
- 有没有陌生的监听端口
- 有没有对外连接到陌生 IP
- 有没有新创建账号 / 新加 SSH key
- 有没有被改过的定时任务 / systemd 服务
因为攻击者很多关键行为只活在“当前运行状态”里：
- 回连连接
- 内存马 / 文件无落地恶意代码
- 临时令牌
- shell 会话
一重启，这些就可能直接消失。
很多人一发现入侵，第一反应就是：
- 改 root 密码
- 改数据库密码
- 改云商密码
这不是错，但顺序可能错了。
如果攻击者还在机器里，或者有持久化后门，那么你刚改好的新密码、令牌、密钥，攻击者可能很快又拿到。
所以更稳的顺序通常是：
- 先隔离访问
- 确认影响范围
- 先失效会话 / token / key
- 再批量轮换凭据
- root / sudo 用户密码
- SSH key
- 面板账号
- 数据库账号
- 部署机凭据
- API key / Access Token
- 对象存储密钥
- CI/CD secrets
如果这台 VPS 上有：
.env- 部署脚本
- 自动化工具
- GitHub Actions / GitLab Runner / webhook
那泄露的往往不只是这台服务器本身，而是一整串上下游凭据。
这是另一个关键决策点。
下面这些情况，通常应该默认把“重建”当主路线：
- root 已被拿下
- 不确定攻击入口和持续时间
- 有明显持久化痕迹
- 怀疑内核级 / 高权限后门
- 业务允许通过备份恢复
- 无法确认系统是否仍可信
为什么？
因为清理不等于可信恢复。
你删掉一个挖矿程序，不代表没有第二个后门；你修复一个 cron，不代表没有 systemd 持久化；你恢复一个文件，也不代表攻击者没改过别的东西。
只有在以下条件比较明确时，才勉强考虑：
- 影响范围很小
- 入侵路径已明确
- 没有高权限持久化
- 有足够把握确认清理完成
- 业务上短期无法重建
即便如此，也更建议尽快迁移到新实例。
很多团队以为“把网站拉起来”就叫恢复，实际上远远不够。
如果漏洞还在、端口还开着、权限还没收紧，攻击者回来只需要几分钟。
恢复了机器，但旧 key 还有效，这和没恢复区别不大。
恶意文件、后门脚本、污染备份，有时不只在主机上。
这是 Linux VPS 最常见的持久化位置之一。
如果你恢复后一小时内没有加强监控，那你其实不知道攻击者有没有回来。
为了方便执行，可以把前 24 小时拆成下面 4 段。
- 记录异常来源
- 控制面板层面隔离网络
- 决定是否切流/降级
- 不重启、不清现场
- 导出日志
- 查看进程、端口、连接
- 记录账号、任务计划、服务变化
- 保留关键证据副本
- 判断影响范围
- 失效会话与 token
- 轮换高危凭据
- 判断是否直接重建
- 从可信备份恢复到新环境
- 补丁、权限、MFA、网络策略加固
- 开启高频监控
- 记录根因、时间线和待补动作
对大多数个人站长、小团队、工具站来说，最现实的路线通常不是“做完整取证实验室”，而是：
- 先隔离网络
- 尽量保留基础证据
- 导出关键日志和配置
- 轮换所有关键凭据
- 用可信备份重建新实例
- 把旧机只作为调查样本，不再直接恢复上线
这是成本和安全之间最平衡的做法。
如果你本来就有备份、快照和恢复流程，这时候会轻松很多。没有的话，可以先补这两篇：
通常不建议直接关机。更稳的默认动作是先隔离网络，避免进一步危害，同时尽量保留内存、连接和会话这些易失性证据。
大多数情况下先断网 / 隔离访问更优先。因为如果攻击者仍在线，新密码也可能很快再次泄露。
如果已经涉及高权限、持久化或影响范围不明，通常更建议重建新实例，而不是继续信任旧系统。
那就更要坚持“先隔离、再保留基础证据、然后重建”的思路。不要一边慌张修，一边把现场全部破坏掉。
VPS 被入侵后的前 24 小时，最危险的不是“动作太慢”，而是顺序错了。
真正稳的处理方式通常是：
- 先隔离网络，避免继续受害
- 尽量保留证据，不要急着重启
- 先判断信任边界，再轮换凭据
- 能重建就重建，不要过度迷信‘清干净了’
一句话总结就是：
先止血，再取证，再恢复；不要把“重启一下试试”当成应急响应。
如果你的 VPS 现在还没被入侵，这篇最有价值的部分其实不是“事后怎么做”，而是提醒你提前准备：
- 备份
- 快照
- 日志
- MFA
- 恢复 runbook
因为真正出事的时候，你最缺的从来不是命令，而是时间。