服务器被挂挖矿脚本排查实录

这大概是运维生涯最惊悚的一晚。晚上发现测试服务器卡得 SSH 都登不进去，好不容易登进去，top 一看：一个叫 kdevtmpfsi 的进程吃掉 180% CPU。搜了一下，知名度很高的挖矿木马。以下是从处置到加固的完整记录。

第一步：先断网，保留现场

第一反应是 kill 进程，忍住了——杀掉它通常几十秒后会自动复活（有守护进程），而且会打草惊蛇。先在安全组把出口带宽限制/断开外网（保留你自己的管理 IP），让它连不上矿池，同时保留现场排查。

第二步：摸清入侵路径

排查是按"它进来后要做什么"倒推的：

crontab -l                          # 果然有陌生定时任务：每15分钟拉一次脚本
ls -la ~/.ssh/authorized_keys       # 多了一把陌生公钥
cat /var/log/secure | grep -i accept  # 看到陌生 IP 用密钥登录过
ps -ef | grep -E 'watchdogs|kinsing'  # 找到守护进程 kinsing

登录成功的时间点和 Redis 的启动时间对上了——这台测试机的 Redis 是内网 IP 跑的，但安全组图省事开了 0.0.0.0，又没设密码（测试环境嘛），经典的 Redis 未授权访问写入 crontab + SSH key 的入侵链。中招的直接原因就这个。

第三步：清理

• 删除恶意 crontab，检查 /etc/cron.d、/var/spool/cron 下的陌生文件
• 删掉 authorized_keys 里的陌生公钥
• pkill 挖矿进程和守护进程，删除 /tmp 下对应的可执行文件
• 改 root 和所有业务账号密码
• 看了一遍 /etc/passwd 有没有陌生用户、SUID 文件有没有被替换（find / -perm -4000 -mtime -30）

测试机没存敏感数据，判断没有数据泄露风险，选择清理而不重装。如果是生产机，标准答案是直接重装——你永远无法确定清干净了。

第四步：加固（防再犯）

• Redis：bind 内网 IP + requirepass + 禁用危险命令（CONFIG/FLUSHALL 改名），永远不要 0.0.0.0 裸奔
• 安全组收敛到最小开放原则，用 nmap 从外网扫一遍自己验证
• 重要目录（crontab、authorized_keys）上文件审计或至少定时 diff
• 云监控加 CPU 告警，这次其实告警响了半天，我看了一眼以为是压测……面子挂不住，但事实就是

整个排查用了三个多小时。事后最大的感触：绝大多数被黑不是遇到了高手，而是自己在墙上留了门。挖矿木马不偷数据、不留后门的算"有职业操守"的，下次未必这么好运。安全这课，学费早晚要交，趁便宜的学费学到就是赚到。