你的服务器被黑了，第一反应千万别是关机！
刚收到告警邮件，看到 CPU 冲到 99%，top 里一堆不认识的进程在狂占资源，SSH 登录慢得像卡顿的视频——这时候手已经摸到键盘上想 reboot？先停一下。
关机或重启，等于亲手擦掉犯罪现场最关键的指纹。内存里的连接、进程、加密密钥……全没了。你不是在止损，是在帮黑客销毁证据。
第一步到底做什么？立即“隔离”而非“断电”
发现异常，第一件事：断网，不断电。
- 阿里云/腾讯云/AWS？立刻进控制台，找到这台实例，把安全组规则改成「所有入站 + 所有出站 → 拒绝」。
- 自建机房？别犹豫，直接拔网线。物理隔离最干净。
别管它还在跑什么，先让它“失联”。
这是为了三件事：
① 阻止黑客继续远程操控；
② 拦住他往内网其他机器跳转；
③ 卡住数据外传的最后一道出口。
服务器开着，内存才活着。那些一闪即逝的线索，只在通电时存在。
一个真实教训：客户发现服务器在偷偷挖矿，第一反应是远程 sudo reboot。结果一重启，木马进程没了，但 ss -tulpn 显示的可疑监听端口、内存里残留的加密密钥、甚至攻击者刚写进 /dev/shm/ 的 shellcode——全清零了。我们后来翻了三天日志，才从 nginx access log 的异常 UA 里扒出入口，而如果当时先隔离再抓内存镜像，两小时就能定位到那个被绕过的 WordPress 插件漏洞。
如何在不惊动黑客的情况下保存现场？
隔离完，别急着登录。你敲下的每条命令，都可能覆盖痕迹、触发后门警报，甚至让攻击者察觉“有人来了”。
优先做这件事：用带外通道，静默导出关键状态。
比如：
- 阿里云 ECS 就用「VNC 远程连接」（不是 SSH）；
- 华为云用「救援模式」；
- 物理服务器有 iDRAC/iLO？直接走管理网登录。
进去后，不交互，只执行一条重定向命令：
{ ps auxf; netstat -antp; lsof -i -P -n; last -n 20; w; } > /tmp/forensic_$(date +%s).log 2>&1
然后立刻把 /tmp/forensic_*.log 用 scp 或控制台下载功能，传到你没被入侵的跳板机或本地电脑。
⚠️ 别存服务器硬盘上——攻击者很可能已替换 ls、cat，甚至篡改了 syslog，你看到的“正常”，未必是真的。
如果条件允许，用 LiME 或 AVML 做一次内存镜像（哪怕只 dump 出来存到 U 盘），比任何日志都硬核。
接下来，怎样快速判断损失范围？
现在你手上有内存快照和进程网络快照。别急着删文件，先问自己三个问题：
他们有没有留下后门？
→ 查 /etc/passwd 里多没多 UID=0 的陌生用户；
→ crontab -l 和 /etc/cron.d/ 下有没有定时拉远控脚本；
→ systemctl list-unit-files --state=enabled 里有没有名字奇怪的 service。
他们碰没碰核心数据？
→ 快速 ls -la /var/www/html/ 看有没有 .php 尾的 Web Shell；
→ ls -la /tmp /dev/shm 找非常规命名的二进制（比如 kthreadd、journald 这种伪装名）；
→ 登数据库，SELECT * FROM mysql.user WHERE Super_priv='Y'，看有没有新提权账号。
业务还能不能信？
→ 检查最近 24 小时的数据库 binlog 或应用日志，有没有批量删除、导出操作；
→ 对比备份时间戳和当前文件修改时间，看 /var/lib/mysql/ 下库文件是否被动过。
这个阶段的目标很朴素：搞清一件事——你是被蹭了点算力，还是整个系统已被当自家客厅用了？
取证完成后，该选择“恢复”还是“重建”？
答案就藏在刚才那轮检查里：
✅ 如果只看到一个挖矿进程、没新增用户、没改启动项、which ssh 输出还是 /usr/bin/ssh——可以清理后恢复。
重点清理：杀进程、删 cron、清 /tmp、重置可疑账户密码、验证备份可恢复。
❌ 但只要发现以下任一迹象，别省事，直接重建：
ls -la /bin/ssh显示修改时间比系统安装还晚；rpm -V openssh-server（CentOS）或dpkg --verify openssh-server（Ubuntu）报大量SM5DLUG异常；- 内存镜像里解析出
LD_PRELOAD注入或内核模块加载记录。
血泪经验：有个团队清完 Web Shell，又 reload 了 Nginx，觉得“干净了”。结果三天后，同一台服务器又爆了——攻击者早把恶意 so 文件塞进了 /usr/lib/x86_64-linux-gnu/，每次 ldconfig 都自动加载。最后咬牙重装系统，连磁盘都格式化了，反而比反复打补丁快。
如何从这次事件中真正学到东西，而不只是“灭火”？
业务跑起来≠事情结束。现在打开你的终端，cd 到日志目录，做三件事：
zgrep -i "password\|login\|auth" /var/log/auth.log* | tail -100—— 看有没有暴力破解记录；grep -r "wp-admin" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -10—— 找扫描 IP；lastb | head -20—— 看失败登录里有没有熟悉的 IP 范围。
把这些线索串起来，大概率能定位入口：是 WordPress 后台弱口令？是 Jenkins 未授权 API？还是某台测试机开着 22 端口暴露在公网？
找到根因后，立刻动手：
- 把所有 SSH 改成密钥登录，删掉密码登录配置；
- 给所有管理后台加二次验证（如果你用的是阿里云 RAM 或腾讯云 CAM，直接开 MFA）；
- 关掉所有非必要的公网端口，尤其是 22、3306、6379；
- 拉一次离线备份，用
rsync --delete同步到另一台内网机器，别只靠云盘快照。
这次入侵不是事故，是你系统真实的“压力测试报告”。
今天下班前就能执行的一个具体操作
打开你常用的终端，连上你最重要的那台生产服务器（比如主数据库或核心 API 服务），执行：
mkdir -p ~/emergency && cd ~/emergency
curl -o checklist.md https://gist.githubusercontent.com/xxx/yyy/raw/checklist.md 2>/dev/null || echo "# 服务器应急检查清单\n- ps auxf\n- netstat -antp\n- lsof -i\n- last -n 20" > checklist.md
echo "已完成：基础应急包雏形（含检查清单）"
然后，把这个 ~/emergency 目录，用 scp 或控制台上传功能，同步到你另一台可信的跳板机（比如运维堡垒机）上。
再花 2 分钟，把跳板机的 IP 和登录方式，发条钉钉/企业微信消息给你的搭档。
不需要买新工具，不用注册第三方平台。就用你现在天天敲的终端、正在用的云控制台、手边已有的跳板机——把第一步的“肌肉记忆”，变成一个随时能打开的文件夹。