凌晨两点半手机连着震了三次。生产服务器CPU告警监控图上直接拉满100%并且持续了快十分钟没有回落。登录服务器top一刷一个名为systemd-service.sh的进程占着接近800%的CPU还不断有新的子进程冒出来。看到这个名字我心里已经有数了——中了挖矿病毒而且是有伪装、带持久化的那种。不到一个月我已经是第二次处理同类型的挖矿病毒了上次叫systemd-update.sh这次改名成了systemd-service.sh换汤不换药。这篇博文就完整记录这次排查处理的全过程包括如何定位可疑进程、怎么判断恶意脚本、清理时应该按什么顺序操作、以及事后加固要做哪些事情。无论你是刚接手服务器的运维新人还是已经被挖矿病毒折腾过的老手这篇内容应该都能帮你省下不少排查时间。1. 现象与初步判断CPU飙升到底从哪来1.1 告警第一现场看似正常的进程名先描述一下当时的现场情况。监控系统告警显示这台8核16G的云服务器CPU使用率从平时的10%左右直接飙到接近100%load average到了10以上。第一反应是业务流量突增但看了Nginx访问日志和业务监控流量跟平时没有明显差异这就基本排除了正常业务压力的可能。登录服务器后我先执行了uptime确认负载再跑top -c按CPU排序头部几个进程号分别是6012、6130、6280进程名全部显示为[kworker]后面跟着一串看起来很长很乱的内核工作队列名称。第一次遇到这种情况的新手很容易被骗过去因为kworker是内核线程正常情况下确实是系统自己拉起来的不占太多CPU。但这里有两个破绽。第一kworker进程带的参数形式异常正常的内核线程名称是被方括号括起来的比如[kworker/0:1]而这个进程显示的是类似[kworker/3:1] /tmp/.systemd-service.sh这样的内容命令列后面明显跟了脚本路径。第二kworker线程不可能有PID的父进程链变化只要执行pstree -ap | head -50就能看到这些进程的父进程是/bin/bash而不是内核的kthreadd。1.2 为什么不能直接重启服务器有个同行问我“既然都确认是挖矿病毒了重启服务器不就行了吗重启之后进程不就都没了”这里必须说清楚重启只能暂时清空内存里的进程无法清理磁盘上的恶意文件和持久化配置。这类挖矿病毒几乎都会在重启后自动拉起因为它的启动项早就写进了crontab、systemd目录、/etc/rc.local甚至是SSH公钥里面。你重启一百次它就能起来一百次。另外服务器上可能还有业务数据和服务贸然重启会中断线上业务造成比挖矿本身更大的损失。所以正确的做法是在不中断业务的前提下先完成排查取证再断网、清理、修复、加固最后再考虑是否需要重启验证。挖矿病毒只要在跑就一直在消耗CPU和流量早一分钟处理完就少一分损失但绝对不能慌到乱重启。2. 定位可疑进程三条命令锁定元凶2.1 top与ps的组合快速找到异常进程树第一步永远是确认进程树的关系。top -c看到了多个高CPU进程但进程名会被截断所以要立刻用ps把完整命令行拉出来ps -ef --sort-%cpu | head -30输出里出现了一个非常典型的信号进程PID 6012的完整命令行是/bin/bash /tmp/.systemd-service.sh而且这个bash进程下面持续fork出新的子进程子进程还会随机改名。有的版本会伪装成[kworker]有的直接用node、python等常见解释器的名字。紧接着查看进程的启动时间和工作目录ls -lh /proc/6012/ ls -lh /proc/6012/cwd /proc/6012/exe cat /proc/6012/cmdline | tr \0 /proc/6012/exe指向了/bin/bashcmdline里能直接看到/tmp/.systemd-service.sh。注意这个路径是隐藏目录前面带了一个点ls /tmp默认是看不到的必须用ls -la /tmp | grep systemd或者find /tmp -name *.sh -mtime -7才能发现。2.2 顺着/proc目录往下挖确认病毒行为/proc是Linux暴露进程运行时信息的虚拟文件系统排查恶意进程时必须熟练使用。这一步我做了三件事第一看进程的可执行文件、环境变量和打开的文件cat /proc/6012/environ | tr \0 \n | head -20 ls -l /proc/6012/fd | head -20环境变量一般没什么异常但打开的文件列表有时能直接暴露出恶意脚本引用了哪些文件。第二看进程网络连接ss -antp | grep 6012 netstat -antp 2/dev/null | grep 6012挖矿进程通常会连接矿池地址但不少新变种会用代理转发或者通过多个中转端口做加密通信如果没看到明显的矿池IP也不要放松警惕。第三用lsof进一步确认lsof -p 6012如果环境里没装lsof可以用ls -l /proc/6012/fd替代。这一步的结论很明确进程在持续写文件到/tmp目录并周期性发起外部TCP连接结合高达800%的CPU占用率挖矿病毒的特征已经比较完整了。2.3 病毒的自保护机制进程互相拉起的套路这里要重点讲一下为什么普通kill根本杀不掉。当我第一次执行kill -9 6012后CPU占用确实降下来了但不到20秒又飙回接近100%。再次查看进程发现出现了新的PID路径还是/tmp/.systemd-service.sh这就是所谓的“守护双进程”或者“多进程互相拉起”机制。这类脚本通常会在自身代码里写死一个循环如果检测到主进程不在了就重新复制脚本并用nohup或setsid重新拉起有的版本还会有多个样本互为监视进程A死掉进程B在20秒内把它拉起来反之亦然。这也是为什么很多新手在清理挖矿病毒时反复失败的根本原因——只杀进程不删文件、不清理定时任务病毒很快就能原地复活。处理这类自我保护型病毒的正确顺序是先断外网再用pkill批量杀同名进程随即删掉恶意文件然后清理定时任务和各类自启动项最后再全盘复查一遍是否有残留。3. 揪出.systemd-service.sh挖矿病毒是如何伪装的3.1 伪装成systemd的惯用伎俩恶意脚本名字叫.systemd-service.sh放在/tmp这种临时目录里故意和系统里真实的systemd服务相关联。这是一种非常常见的“社会工程学式误导”管理员看到systemd字样第一反应是系统服务不敢随便动这反而给了病毒更多存活时间。更聪明一点的变种会把脚本文件伪装成以下路径/usr/lib/systemd/systemd-service /usr/lib/systemd/system/systemd-service.sh /usr/lib/systemd/systemd-service.sh这些路径看起来都很“系统”尤其是放在/usr/lib/systemd/system/下的文件如果不仔细看还真会被当成自带的systemd服务。判断标准很简单真实systemd服务的文件通常是由包管理器安装的有明确的签名和归属挖矿脚本则往往是root创建的时间戳异常而且内容里必然有挖矿程序的下载地址或启动参数。3.2 脚本内容的典型结构把脚本抓出来看一眼基本每一行都是套路。第一批是设置隐蔽环境重定向输出、设置PATH变量、检查是否已经在运行。第二批是下载和更新挖矿程序从远程服务器curl或wget一个二进制包解压后放到/usr/lib或者/var/tmp。第三批是持久化写入crontab、写入systemd service、写入SSH公钥。第四批才是真正拉起挖矿进程。我这次看到的脚本内容里还有一段很有意思它竟然会检测常见的安全监控工具如果发现top、lsof、ps等命令的输出被替换或者发现安全Agent的进程在运行脚本就会暂时休眠一段时间等风头过去再继续挖矿。这种对抗手段越来越普遍所以排查时哪怕top显示的CPU很正常也不能完全排除挖矿病毒的存在必须结合网络连接、文件改动时间、负载异常等多个维度来判断。3.3 持久化藏匿的典型位置挖矿病毒能不能“复活”关键看持久化有没有漏掉。常见的落地点有这么几类持久化位置典型路径/命令说明crontab/var/spool/cron/root、/etc/crontab、/etc/cron.d/*最常见一行* * * * * /tmp/.systemd-service.sh就够systemd service/etc/systemd/system/*.service、/usr/lib/systemd/system/*.service注册成服务后开机自启还有自动重启策略初始化脚本/etc/rc.local、/etc/init.d/老式启动方式很多CentOS 7以下系统会中招SSH公钥/root/.ssh/authorized_keys、/home/*/.ssh/authorized_keys植入后门公钥随时可以重新登录shell启动文件/root/.bashrc、/root/.profile、/etc/profile.d/*.sh登录时自动执行清理的时候上面每一个位置都得检查一遍。少查一个病毒就可能星星之火再次燎原。4. 清理与加固流程从断网到去根的一次完整操作记录4.1 第一步先断网或封禁外联防止二次下载这一步非常关键。如果条件允许通常最干脆的操作是直接通过云控制台的安全组暂且删掉出方向的全部规则或者只保留必要端口把挖矿程序的外联通道切断。如果暂时不敢动安全组也可以在本机用防火墙命令把恶意进程外联地址封掉但注意这只适合短期应急因为矿池地址是动态变化的域名解析也可能走CDN。我当时直接用iptables封掉了脚本连接的那个矿池IP并且在安全组上把所有非业务端口的外联全部拒绝。断网之后挖矿进程即使还在运行也因为无法连接矿池而陷入等待状态CPU占用会明显下降这时再来清理就安全得多。4.2 第二步批量杀死挖矿进程并删除恶意文件断网后紧接着执行进程清理。注意不要一个一个kill直接用pkill按特征匹配既快又能防止进程互相拉起pkill -9 -f .systemd-service.sh pkill -9 -f kdevtmpfsi pkill -9 -f kinsing pkill -9 -f xmrig上面这些是几类常见的挖矿进程不一定会全中先批量杀一遍。紧接着用ps aux复查是否还有残留ps aux --sort-%cpu | head -20确认没有异常进程后立刻删除磁盘上的恶意脚本和二进制文件。清理时建议把整个常见落点都过一遍rm -rf /tmp/.systemd-service.sh rm -rf /usr/lib/systemd/systemd-service rm -rf /usr/lib/systemd/system/systemd-service.sh rm -rf /var/tmp/.systemd-service.sh find / -name *systemd-service* -mtime -3 2/dev/nullrm命令删完之后一定要再跑一遍find因为有些变种会把副本藏得很深比如放到/boot、/lib这种目录下面不整体搜一遍根本找不到。文件删完才算真正挡住了“复活”的第一条路。4.3 第三步清除定时任务与systemd服务文件删完紧接着处理持久化。先查crontabcrontab -l cat /etc/crontab ls -la /etc/cron.d/ ls -la /var/spool/cron/如果发现里面有/tmp/.systemd-service.sh相关的行直接编辑删除。这里分享一个细节光用crontab -e删还不够因为病毒可能同时写进了多个用户的cron比如www用户、mysql用户。要逐个用户检查包括系统级cron目录。再查systemd服务systemctl list-unit-files | grep -i systemd | grep -v native ls -la /etc/systemd/system/ | grep -v enabled systemctl status systemd-service 2/dev/null如果发现病毒注册了自启服务需要执行以下一系列操作systemctl stop systemd-service 2/dev/null systemctl disable systemd-service 2/dev/null rm -f /etc/systemd/system/systemd-service.service systemctl daemon-reload最后别忘了检查/etc/rc.local看有没有被追加启动命令。这一步做完后可以在本机模拟重启来验证持久化清理是否彻底但生产环境最好不要随意重启可以等到业务低峰期再做。4.4 第四步修复SSH后门与可疑账号持久化清理完之后一定要检查SSH相关文件挖矿病毒通常会在入侵后植入公钥方便攻击者随时回连。cat /root/.ssh/authorized_keys ls -la /root/.ssh/ cat /etc/passwd | grep -E /(bin/bash|bin/sh)$ awk -F: {if ($3 0) print $1} /etc/passwd重点是三个方面检查authorized_keys里有没有自己从来没加过的公钥检查是否有意外的UID为0的账号检查是否多了不认识的普通账号。如果发现异常公钥直接删掉对应行如果发现非法账号用userdel -r 用户名彻底删除。另外还要检查登录记录和bash历史看攻击者是通过什么方式进来的。last -20查看最近的登录IPgrep Accepted /var/log/secure | tail -20查看SSH成功登录记录。如果看到陌生IP频繁爆破成功的记录说明这台机器很可能因为弱口令被入侵了后续必须强制改密码并限制登录来源。4.5 第五步加固操作清单清理完只是把病毒“赶跑”了如果漏洞不堵上它或者别的病毒很快还会再进来。按优先级列一份加固清单修改所有账号密码包括root和各个应用账号密码强度至少12位以上包含大小写、数字和特殊字符。禁用root密码登录改用密钥登录。在/etc/ssh/sshd_config里设置PermitRootLogin prohibit-password同时把PasswordAuthentication改成no。限制SSH来源IP如果服务器只面向固定办公网IP就在安全组里加白名单其他IP全部拒绝。关闭不需要的端口和服务用ss -lnp检查当前监听的端口不用的服务直接停掉。部署入侵检测比如云厂商自带的安全Agent、主机监控、fail2ban之类至少确保有人在攻击发生时能第一时间发现。定期备份数据库和关键配置至少每天一次异地备份万一被勒索或破坏能快速恢复。5. 常见问题与排查技巧实录5.1 快速查询命令速查表把这次排查用到的关键命令整理成一张表方便以后直接抄作业排查目标推荐命令查看CPU占用Top进程top -c、ps -ef --sort-%cpu查看进程完整命令行ls -l /proc/PID/cmdline、tr \0 /proc/PID/cmdline查看进程网络连接ss -antp、netstat -antp查看进程工作目录和执行文件ls -lh /proc/PID/cwd /proc/PID/exe查找近期被修改的可疑文件find /tmp /var/tmp /usr/lib /boot -name *.* -mtime -3 2/dev/null检查定时任务crontab -l cat /etc/crontab ls -la /etc/cron.d/检查SSH公钥cat /root/.ssh/authorized_keys检查异常账号awk -F: {if ($3 0查看登录记录last -20、grep Accepted /var/log/secure5.2 实战中的三个坑第一个坑是只知道杀进程不知道删文件。很多新手在top里看到可疑进程kill -9一下看到CPU降下来就觉得完事了。结果第二天CPU又满回头看才明白病毒文件还在磁盘上crontab也还挂着。清挖矿病毒的核心不是杀进程而是删文件、清配置、堵后门每一步都不能省。第二个坑是只看进程名不看完整路径。挖矿病毒最擅长伪装[kworker]、systemd-service、kdevtmpfsi、kinsing各种名字都有。如果只看进程名很容易把恶意进程当成系统进程放过去。任何时候都要用ps -ef查看完整命令行用/proc/PID/exe确认程序路径不能被表面的名字迷惑。第三个坑是清理期间忘了保留样本和日志。我自己踩过这个坑有一次太着急发现病毒就赶紧rm -rf结果后续想分析攻击路径连样本都没留。现在我的习惯是先cp一份到隔离目录再对进程做gcore或者把脚本内容留存之后再清理。这样既能取证也能给云厂商提交样本帮助他们更新查杀规则相当于是为整个安全生态做了贡献。5.3 给初学者的防护优先级建议处理完这次事件后我重新梳理了一下服务器防挖矿的安全优先级。对中小型团队、个人开发者来说很多高级安全方案并不现实但只要抓住最核心的几点就能挡住绝大多数脚本小子的批量扫描第一不要让root直接通过密码登录SSH。这是绝大多数服务器被入侵的主要原因。改成密钥登录后爆破攻击基本失效。第二安全组出方向默认拒绝按需放行。很多挖矿病毒都是服务器被入侵后主动外连矿池的出方向控制做得好就算中了毒也挖不出去。第三监控必须要有CPU告警和登录告警。不是所有团队都有专职安全但CPU持续飙高、凌晨有人SSH登录成功这类事件完全可以用监控系统实现自动通知。第四系统中的软件要及时更新特别是Web中间件、数据库、Redis这类常见入口很多挖矿病毒就是通过未授权访问Redis或Web漏洞进来的。最后聊一点我自己的习惯。每次处理完挖矿病毒我都会在服务器上留一个固定的“体检记录”记录最近一次清理的时间、发现的问题、已做的加固措施并且把这次找到的恶意样本、矿池地址、攻击IP统一整理成一份文档。这样下一次再出现类似问题时我不用从头摸索拿出来对照一遍就能快速定位。实际上很多挖矿病毒的家族都是同一套代码改改壳处理过一次“.systemd-service.sh”下次再看到“.systemd-update.sh”之类的变种基本十分钟就能清理干净。服务器安全这件事说到底就是一个反复对抗、持续加固的过程把基本功做到位你就能比别人少熬好几个凌晨的告警夜。