账单涨了，服务器却没有新增业务，CPU常年90%以上，很多人第一反应是流量变大了。但这类情况背后，经常是阿里云挖矿程序在暗中运行。它通常不影响页面打开，用户本人很难察觉，这也是它能存活很久的原因。
什么是阿里云挖矿程序
一般指部署在阿里云ECS实例或容器环境里的恶意脚本或二进制文件。攻击者入侵服务器后植入挖矿客户端，连接矿池，持续提交计算结果换取虚拟货币收益。这类程序常伪装成系统进程，还会和木马、后门捆绑在一起。只删掉挖矿本体，未必能切断攻击者的后路。
对你来说，直接损失是按量计费的资源被白白消耗。更麻烦的是业务变慢、数据可能暴露，服务器还可能被拿去扫描或攻击其他主机，到那一步，处理起来成本会高很多。
常见入口
多数情况下，入侵并不依赖高深的漏洞，而是一些长期没人管的老问题。
- 弱口令或私钥泄露：SSH使用简单密码，或者私钥被误提交到公开代码仓库。发现后应立即作废该密钥，并检查仓库的历史提交。
- 公网暴露且无鉴权的服务：Redis、Docker API、Jupyter这类服务如果监听公网又没有密码，扫描器很快就能找到。临时调试完记得关掉端口。
- 未修补的已知漏洞：框架或中间件的漏洞公开后，攻击者会批量利用，窗口期往往只有几天。
- 安全组放得太宽：高危端口对0.0.0.0/0开放，等于没有门。
一个常见的排查场景
这种情况在中小团队里并不少见。促销期间，服务器负载看上去还算正常，账单却明显高于平时。运维人员以为是流量上涨，直到查看监控才发现，业务低峰期CPU依然满载，进程列表里有个名字像系统服务的程序。
继续追查，常见的入口是为了临时调试而开放的Redis端口，并且没有设置密码。攻击者借此写入定时任务，每隔几个小时重新下载挖矿程序。手动删掉一次文件，很快又会恢复。
这件事给人的提醒很具体：暴露面过大，缺少定期巡检，清理时只删了表面文件，持久化机制没有处理。
怎么判断服务器是否中招
先不要急着重装，用几条命令确认情况更稳妥。
- 用top或htop查看CPU占用，关注长期高占用、名字陌生的进程。找到可疑PID后，执行ls -l /proc/PID/exe，查看它实际指向的文件。如果路径位于/tmp、/var/tmp或隐藏目录里，基本可以确定有问题。
- 检查crontab -l、/etc/crontab、/etc/cron.d，以及systemctl list-unit-files中是否有不明任务或服务。挖矿程序常靠这些项在被删除后复活。
- 用ss -tnp查看网络连接，留意是否连到未知IP或矿池域名。
- 在阿里云云监控中对比CPU曲线。如果高占用时段与业务高峰对不上，基本就不是正常负载。
- 检查~/.ssh/authorized_keys，确认其中是否有你不认识的公钥。
清除的顺序
顺序错了，程序很可能反复回来，所以建议按下面的步骤处理。
- 先记录现场。保存进程列表、网络连接、可疑文件路径和定时任务内容，这些信息既能帮你判断入口，也方便交给安全团队分析。
- 先断开可疑进程的网络连接，再停止进程。如果直接杀进程，而持久化脚本仍在，它可能很快把程序拉起来。
- 清理持久化项，包括定时任务、systemd服务、启动脚本和rc.local，删除所有不认识的条目。
- 删除植入的文件，并检查/tmp、/var/tmp、/dev/shm等可写目录。
- 修改相关账号密码，轮换SSH密钥和服务凭据。如果凭据已经泄露却不更换，前面的清理基本等于白做。
- 修补漏洞，关闭不需要的公网端口。
- 如果无法确定是否清理干净，重装系统更稳妥。重装后从干净镜像恢复业务，恢复用的备份也要先确认没有被感染。
长期防护
挖矿程序能长期存活，往往是因为防护习惯缺失。临时清理只能解决当下的问题，下面几件事才决定以后会不会再次发生。
- 最小化暴露面：安全组只开放业务必需端口，内部服务优先走内网或VPN访问。
- 禁用SSH密码登录，改用密钥登录，并定期轮换。
- 开启阿里云安全中心，关注其对异常进程、挖矿行为和漏洞的检测结果，并把告警配置到真正会看消息的人手里。
- 设置费用告警。账单异常通常比CPU报警更早出现。
- 建立补丁巡检，每月或每季度检查一次系统和组件更新，不要等公告出来后才动手。
阿里云挖矿程序之所以常见，是因为攻击成本低，收益又相对稳定。对用户来说，先把基础安全做好，再定期查看资源和日志，大部分风险都能提前挡住。发现CPU长期异常时尽早排查，比等账单出问题后再补救，省时间，也省钱。
