收到异常告警（CPU 打满、外连可疑 IP、疑似被植入挖矿）时，按下面的顺序排查，别急着重装系统——那样会毁掉现场和证据。
「服务器疑似被入侵后的应急排查清单」提醒我们一个朴素的事实：云上安全纵深防御靠的不是临场发挥，而是平时的体系化建设。告警是否准确、日志是否齐全、权限是否收敛，决定了故障来临时是从容处置还是手忙脚乱。
1. 隔离，保留现场
先用安全组限制该实例的出 / 入方向，防止横向扩散，同时保留现场供分析。
2. 看进程与外连
top # 找高 CPU 进程
ps aux # 查看可疑进程与启动路径
ss -antp # 查看外连 IP 与对应进程
lsof -p PID # 定位进程打开的文件3. 查持久化后门
检查 crontab -l 与 /etc/cron.*、~/.ssh/authorized_keys、systemd 服务、开机启动项、以及动态库劫持（/etc/ld.so.preload）。
4. 找入侵入口
审计登录日志（last、/var/log/secure）找异常 IP 登录；检查 Web 日志找 webshell 与异常上传；排查弱口令与未修复漏洞。
5. 清除与加固
杀掉恶意进程、删除文件，修改所有相关口令，打补丁，收敛安全组，开启云安全中心防护。
6. 复盘
如果无法确认系统已被彻底清理干净，最稳妥的做法是重装系统 + 从可信备份恢复数据。
小结：应急处置的核心是"先隔离、留证据、断根因、再加固"，切忌上来就重启重装。
取证顺序与事后必须更换的凭据
应急的第一步不是清理，而是保全。直接重启或重装会把内存与临时状态里的线索一次性销毁，之后再也说不清攻击者做了什么。
- 保全现场：对系统盘做快照或镜像，导出系统日志、应用日志、进程列表与网络连接记录，记录操作时间与执行人。
- 排查持久化：计划任务、启动项与系统服务、SSH 授权密钥文件、动态库预加载配置、新增或被篡改的账号、被替换的系统命令。
- 回溯入口：弱口令与默认口令、未修复的组件漏洞、暴露在公网的管理后台、泄露或硬编码的访问密钥，是绝大多数入侵的起点。
- 横向影响：确认同网段其他机器、数据库、对象存储是否被访问过，不要只处理最先告警的那一台。
清理之后必须更换的凭据范围要足够大：本机保存的所有密码与密钥、访问密钥、数据库账号、控制台账号（含子账号）、可能被读取过的证书与令牌，以及代码仓库里的配置。只删恶意程序而不换凭据，等于给攻击者留了下次进来的钥匙。
一份可执行的日常清单
- 暴露面盘点：定期梳理对外端口与服务，关闭不必要的开放。
- 权限最小化：账号与密钥按最小权限分配，定期回收闲置权限。
- 告警治理：清理长期无人响应的告警，保证留下的告警都值得处理。
- 预案演练：对高频故障场景准备处置预案并定期演练。
清单不复杂，难在坚持；而云上安全纵深防御的差距，恰恰体现在坚持上。
云上安全纵深防御的体系化思路
与其追求单点工具的极致配置，不如先保证覆盖面：关键资产是否都在监控之内、重要操作是否都有审计、对外暴露面是否都经过评估。覆盖面完整之后，再谈深度优化才有意义。
体系化的另一个好处是可传承：不依赖某个人的记忆，而是依赖流程与清单，团队整体水位才会稳定提升。