阿里云被挖矿后我这样排查补救，实测有效避坑指南

服务器一旦被挖矿，最直观的感受往往不是“系统坏了”，而是CPU持续飙高、带宽异常、业务响应变慢、费用莫名上涨。很多人第一次遇到这种情况时，都会以为只是程序跑飞了，或者某个任务没关掉。可当你登录实例，发现陌生进程反复拉起、定时任务被悄悄篡改、外联地址诡异时，基本就能确认：阿里云被挖矿了。

我自己就处理过一次很典型的案例。那台 ECS 原本只跑一个中小型业务系统，平时负载稳定，CPU长期在 10% 到 20% 之间。某天突然报警，CPU使用率连续数小时超过 90%，系统监控里还有异常出网流量。最开始同事怀疑是活动流量激增，但查看业务日志后发现访问量并无明显变化。进一步排查后，才发现服务器里藏着矿工程序，而且对方还做了持久化和自恢复，普通“kill 掉进程”根本没用。

这篇文章就结合实战过程，讲清楚阿里云被挖矿后到底该怎么排查、怎么止损、怎么补救，以及后续如何避免再次踩坑。

一、先别急着重启，第一步是确认异常来源

很多人的本能反应是重启服务器，觉得重启后负载降下来就没事了。实际上，这么做经常会破坏现场，导致后续很难定位入侵路径。正确做法是先确认异常到底来自业务、脚本失控，还是恶意挖矿。

我通常会按下面的顺序检查：

• 看 CPU、内存、磁盘 IO 是否长期异常，而不是短时波动。
• 看是否存在陌生高占用进程，尤其是伪装成 kworker、sysupdate、networkd、dbused 这类名字的程序。
• 看是否有异常外联连接，特别是持续连接矿池地址或可疑海外 IP。
• 看 crontab、systemd、rc.local、profile 等位置是否被写入启动项。
• 看近期是否开放了高危端口，或者 Web 程序存在上传、命令执行、弱口令问题。

那次排查时，我先用进程查看工具发现一个名称很像系统线程的程序长期占用 300% 以上 CPU。继续追踪进程路径，文件并不在系统标准目录，而是藏在一个临时目录下。再查看网络连接，发现它持续向外建立 TCP 连接，目标地址与公开矿池特征高度吻合。到这一步，基本可以判断是典型的挖矿木马。

二、先止损：隔离、限制、保留证据

确认阿里云被挖矿后，首要目标不是“彻底修复”，而是先止损。因为矿工程序往往只是表象，背后可能还伴随提权、横向移动、后门驻留和敏感数据窃取。

我的建议是分三步做：

1. 立即限制对外访问。通过安全组先收紧入站和出站策略，必要时只保留你的管理 IP 和核心业务访问源。
2. 创建快照或保留现场。如果业务允许，先做磁盘快照，便于后续取证和回溯。
3. 临时隔离受害实例。高风险场景下，直接从公网摘除，避免继续挖矿、继续传播或泄露数据。

这里有个坑很多人会踩：只在系统里删文件、不在云控制台限制网络。这样做的结果是，你刚删掉木马，对方又通过原有入口重新打回来。尤其是弱口令 SSH、Redis 未授权、Docker API 暴露这类问题，如果入口没堵住，清理多少次都白费。

三、真正排查重点，不是矿工本身，而是它怎么进来的

处理阿里云被挖矿，最怕头痛医头、脚痛医脚。把矿工进程清了，只能算完成了 30%。剩下 70% 的关键在于找到入侵入口。

我复盘过多次案例，常见入口主要有以下几类：

• SSH 弱口令或密码泄露。攻击者批量扫描 22 端口，撞库成功后直接植入矿工。
• Web 应用漏洞。比如文件上传漏洞、反序列化漏洞、命令执行漏洞。
• Redis、MongoDB、Elasticsearch 未授权访问。这类配置错误极易被自动化利用。
• Docker/Kubernetes 管理接口暴露。一旦未鉴权暴露公网，常会被秒打。
• 计划任务或第三方组件被投毒。尤其是来路不明的脚本、一键安装包。

我那次遇到的情况，就是运维同事为了方便，把某个服务管理端口临时开放到了公网，且没有做 IP 白名单限制。攻击者利用组件旧版本漏洞拿到执行权限后，下载矿工程序、写入 cron、自建守护脚本，还修改了几个系统文件时间戳，试图掩盖痕迹。

所以排查时一定要反过来问自己：攻击者是通过哪个入口落地的？是否拿到了 root？是否新增了账号？是否留下反弹 shell 或后门？

四、清理时不要只删进程，要连同持久化机制一起处理

很多人处理阿里云被挖矿失败，根本原因在于清理不彻底。你杀掉一个进程，几秒后它又起来了，这通常说明系统里还有守护进程、计划任务或启动项在拉起它。

我一般会重点检查这些位置：

• /etc/crontab 以及各用户 crontab
• /etc/systemd/system 和相关 service 文件
• /etc/rc.local、/etc/profile、.bashrc、.bash_profile
• /tmp、/var/tmp、/dev/shm 这类容易藏恶意文件的目录
• 新增的可疑用户、SSH 公钥、sudo 配置
• Web 目录下的后门文件、异常 PHP/JS 脚本

实战里我见过一种很隐蔽的方式：矿工本体放在临时目录，守护脚本则藏在计划任务里，每分钟检测一次；如果矿工被删除，就立刻从远程再下载。同时，对方还会修改 DNS 或 hosts，让下载域名看起来像正常更新地址。遇到这种情况，只删矿工文件完全没意义，必须把整个链条都拆掉。

五、能否原地修复？我的建议是看业务重要性决定

很多人都会问：阿里云被挖矿之后，到底要不要重装系统？我的实战建议是：如果是生产环境、涉及核心数据，优先考虑重建实例，而不是迷信“原地修复”。

原因很简单。只要攻击者曾拿到较高权限，你就很难百分之百确认系统里没有残留后门。即使表面上清干净了，也可能还有隐藏账户、篡改过的二进制文件、定制化守护程序没被发现。

相对稳妥的方式是：

1. 先备份业务数据，但要甄别备份内容，避免把恶意文件一起带走。
2. 基于干净镜像重建新的 ECS 实例。
3. 升级系统和组件版本，关闭不必要端口和服务。
4. 更换所有密码、密钥、访问令牌。
5. 将业务逐步迁移到新实例，再观察一段时间。

那次案例里，我们最终没有选择在原机器上硬清，而是新建实例迁移业务。迁移完成后，旧机仅保留镜像和快照做分析。虽然这比直接删进程更花时间，但后续运行稳定，再没有出现异常拉高 CPU 的情况，整体看是值得的。

六、补救之后，必须做的几项加固措施

一次阿里云被挖矿，往往不是偶发事件，而是整体安全习惯出了问题。真正有效的避坑，不在于“出事后会清理”，而在于“平时不容易出事”。

我建议至少补上这些基础动作：

• 关闭密码登录，改用密钥登录 SSH，并限制来源 IP。
• 安全组最小化开放，不用的端口一律关闭，管理端口不暴露公网。
• 系统和中间件定期更新，尤其是 Web 环境、容器组件、数据库。
• 部署云安全告警，对异常进程、暴力破解、异常登录、挖矿行为做实时监测。
• 重要目录做完整性监控，防止脚本、启动项被悄悄篡改。
• 定期检查计划任务和账号权限，避免历史测试配置长期遗留。
• 备份与快照常态化，确保出问题时能快速回滚和迁移。

如果条件允许，还可以把业务拆分到不同实例，不要把数据库、应用、管理入口全堆在一台机器上。权限隔离做得越细，哪怕某个节点失守，影响面也更可控。

七、一个容易被忽视的事实：挖矿只是表象，风险远不止算力损耗

不少人觉得阿里云被挖矿无非就是费点 CPU、费点带宽，把矿工清掉就结束了。其实这是非常危险的误判。挖矿通常只是攻击者变现的一种低门槛方式，真正更值得担心的是：

• 服务器配置和代码是否已被窃取
• 数据库是否被导出或拖库
• 实例是否被当作跳板继续攻击内网
• 云账号 AK/SK、环境变量中的密钥是否泄露
• 后门是否潜伏，等待后续再次利用

所以在补救过程中，不能只盯着系统层面。应用日志、数据库审计、云操作日志、对象存储访问记录，都应该一起复查。特别是云上环境，很多敏感权限并不只存在于服务器本机，泄露一组访问密钥，影响范围可能比实例沦陷更大。

八、最后总结：遇到阿里云被挖矿，正确顺序比“快”更重要

回看整个处置过程，我最深的体会是：阿里云被挖矿不可怕，可怕的是误判、漏判和侥幸心理。真正有效的处理顺序应该是：先确认异常，再止损隔离；接着追查入口和权限范围；然后决定原地清理还是重建迁移；最后完成加固和持续监控。

如果你当前正处在服务器 CPU 飙高、进程异常、自启反复的状态，不要只想着赶紧把那个占资源的程序删掉。请记住，矿工只是最后露出来的结果，前面一定有入口、有落地、有持久化。只有把这条链条完整找出来并切断，问题才算真正解决。

实战证明，面对阿里云被挖矿，最靠谱的方法从来不是临时“打一针止痛药”，而是按步骤排查、彻底补救、顺手完成系统性加固。这样做也许麻烦一点，但能真正避开反复感染、业务中断和更大损失。