1. 警报响起：CPU爆满，阿里云短信突袭

那天下午，我正在悠闲地喝着咖啡，突然手机连续震动，收到了好几条阿里云的短信和站内信。内容大意是：“您的ECS实例CPU使用率持续超过90%，请及时排查。”我心里咯噔一下，这台服务器上只跑着一个内部测试用的网站，平时CPU占用率连5%都不到，怎么会突然爆满？

我赶紧登录阿里云控制台，点开云监控，CPU使用率的曲线图让我倒吸一口凉气——一条笔直的100%红线，已经持续了快一个小时。这绝对不是正常业务负载，服务器肯定出问题了。这种场景很多运维朋友都遇到过，表面风平浪静，后台早已“矿”潮汹涌。攻击者不会打招呼，他们只会默默地把你的服务器变成他们的“矿机”，直到你的业务卡死、账单飙升才会被发现。

我第一时间通过SSH连接服务器，手指敲下 top 命令的回车键时，心里已经做好了最坏的打算。果然，在进程列表的最顶端，一个名为 [crypto] 的进程赫然在目，CPU占用率稳稳地钉在99.9%。这几乎就是挖矿病毒的“标准名片”。我尝试用 kill -9 PID 命令结束它，但几秒钟后，它就像幽灵一样重新出现在进程列表里，CPU占用率再次拉满。这说明病毒不仅有守护进程，还很可能修改了系统定时任务或服务，具备了顽固的“复活”能力。真正的战斗，这才刚刚开始。

2. 深入敌后：定位病毒进程与隐藏文件

面对这种会“复活”的病毒，简单粗暴的 kill 命令是无效的。我们必须找到它的老巢，把它连同窝点一起端掉。我的排查思路很清晰：先定位进程，再顺藤摸瓜找到所有相关文件，最后清理它的所有启动项。

2.1 揪出元凶：不止一个 [crypto]

首先，我再次使用 top 命令，确认了主要消耗CPU的进程名和PID（进程ID）。为了看得更清楚，我用了 top -c 命令，这样可以显示完整的命令行。果然，除了 [crypto]，我还发现了一个叫 pnscan 的进程也占用了不少CPU。pnscan 是一个网络扫描工具，攻击者很可能用它来扫描内网或其他服务器，寻找新的感染目标。这说明病毒具备横向移动的能力，威胁更大。

仅仅看 top 还不够，我用 ps auxf 命令以树状结构查看所有进程，希望能发现病毒进程的父进程，也就是那个“守护者”。果然，我发现 [crypto] 进程是由一个非常隐蔽的、名字像随机字符串的进程 ./config.json 拉起的。这个伪装成配置文件的家伙，才是幕后黑手。

2.2 顺藤摸瓜：找到病毒文件藏身之处

知道了PID，下一步就是找到这个进程对应的可执行文件藏在哪。这里我用了两个非常实用的命令：

# 方法一：通过 /proc 文件系统查找
ls -l /proc/<PID>/exe

这个命令会显示一个符号链接，直接指向进程运行的实际程序文件。执行后，我发现 [crypto] 的文件路径是 /usr/share/.crypto/crypto。这个路径非常可疑，正常程序很少会藏在 /usr/share 目录下，还以一个点号开头（.）创建隐藏目录。

# 方法二：使用 pwdx 命令
pwdx <PID>

这个命令直接告诉我进程的工作目录，同样指向了 /usr/share/.crypto。我 cd 到这个目录，用 ls -la 一看，果然发现了几个鬼鬼祟祟的文件：

• crypto：主要的挖矿程序
• config.json：挖矿配置，里面包含了攻击者的钱包地址和矿池地址
• watchdog 或 guard：看门狗程序，负责监控挖矿进程，一旦被结束就立即重启
• 一些以 .sh 结尾的脚本：用于下载、更新病毒和设置持久化

2.3 检查定时任务：斩断“复活”的根源

病毒能复活，十有八九是设置了定时任务（cron job）。我立刻检查了系统级和用户级的定时任务：

# 查看系统定时任务
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.hourly/ /etc/cron.daily/ ...

# 查看当前用户的定时任务（root用户）
crontab -l

# 查看所有用户的定时任务（需要root权限）
for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done

不出所料，在 /etc/cron.d/ 目录下，我发现了一个名为 sysguard 的文件，里面写着每隔一分钟就去检查并启动 /usr/share/.crypto 下的挖矿程序。这就是病毒“春风吹又生”的秘密。同时，在 root 用户的 crontab 里也发现了类似的恶意任务。

3. 彻底清剿：手动清除病毒全记录

找到了所有病毒组件，接下来就是干净、彻底地清除它们。顺序很重要：先停掉自启动，再杀进程，最后删文件。如果先杀进程，定时任务可能立刻又把它拉起来；如果先删文件，进程还在运行，可能会报错但无法彻底清除。

3.1 第一步：清除定时任务，防止复活

我直接删除了发现的恶意定时任务文件，并清空了 crontab 中的可疑行。

# 删除系统cron文件
rm -f /etc/cron.d/sysguard

# 编辑root用户的crontab，删除恶意行
crontab -e
# 在编辑器里找到类似 */1 * * * * /usr/share/.crypto/guard.sh 的行，删除并保存

3.2 第二步：终止所有相关进程

这次，我使用 pkill 命令，根据进程名批量结束它们，确保没有漏网之鱼。

# 结束挖矿主进程和看门狗进程
pkill -9 crypto
pkill -9 pnscan
pkill -f config.json  # 结束使用该配置的进程

# 再次用top确认，进程是否已经消失
top

3.3 第三步：彻底删除病毒文件

在确保进程都被杀死后，我果断删除了整个病毒目录和所有相关文件。

# 进入目录，查看并删除所有文件
cd /usr/share
ls -la .crypto/  # 确认要删除的内容
rm -rf .crypto/   # 强制递归删除整个目录

# 此外，还需要检查一些病毒常用的其他藏身地点
find / -name "*crypto*" -type f 2>/dev/null | grep -v /proc | grep -v /sys
find / -name "*.minerd*" -type f 2>/dev/null
find / -name "*pnscan*" -type f 2>/dev/null
# 将搜索到的可疑文件一并删除

这里有个重要提示：在删除前，我顺手用 cat 命令看了一眼 config.json 里的矿池地址和钱包地址，并记录下来。这倒不是想去举报（通常也很难追查），而是为了后续在防火墙层面封禁这个地址，防止服务器再次被同一批攻击者盯上。

3.4 第四步：检查系统服务与启动项

Linux系统除了cron，还可以通过系统服务（systemd service）实现自启动。我必须检查一下。

# 查看所有系统服务，寻找可疑项
systemctl list-unit-files --type=service | grep -E '(crypto|miner|guard|watchdog)'

# 检查是否有以随机字符串命名的服务
systemctl list-unit-files --type=service | grep -vE '\.service$' | head -20

# 如果发现可疑服务，立即停止并禁用
systemctl stop suspicious_service_name
systemctl disable suspicious_service_name
rm -f /etc/systemd/system/suspicious_service_name.service
rm -f /usr/lib/systemd/system/suspicious_service_name.service
systemctl daemon-reload

4. 亡羊补牢：安全加固与防御建议

清除病毒只是治标，找出入侵根源并加固安全才是治本。我的服务器是怎么被攻破的？回顾了一下，这台服务器为了测试方便，Redis数据库用了默认端口6379，并且没有设置密码，防火墙也只开了80和443端口。这很可能就是漏洞所在——攻击者利用Redis未授权访问漏洞，直接在我的服务器上写入SSH公钥或者上传了病毒脚本。

4.1 立即修复已发现的安全漏洞

1. 加固Redis：这是最可能的入口。我立刻修改了Redis配置。

   vim /etc/redis.conf
   # 找到并修改以下几项：
   # bind 127.0.0.1  # 只允许本地连接
   # requirepass YourStrongPasswordHere  # 设置强密码
   # rename-command FLUSHALL ""  # 禁用危险命令（可选）
   # rename-command CONFIG ""     # 禁用CONFIG命令（可选）
   systemctl restart redis
   

2. 检查SSH授权密钥：攻击者可能植入了后门。

   cat ~/.ssh/authorized_keys
   

   仔细检查里面每一个公钥，确保都是你自己添加的。删除任何不认识的密钥。

3. 检查系统用户：查看是否有陌生的用户被创建。

   cat /etc/passwd
   

   关注UID为0（root）的用户以及最近创建的用户。

4.2 构建基础安全防线

1. 配置阿里云安全组（防火墙）：遵循最小权限原则。

   • 关闭所有不必要的入方向端口，比如Redis的6379、MySQL的3306等，除非业务必需。
   • SSH端口（22）：不要对所有IP开放（0.0.0.0/0）。建议改为非标准端口，并只允许办公网络IP或通过跳板机访问。
   • 在安全组中，可以添加规则，拒绝服务器访问已知的恶意矿池IP或域名（虽然域名会变，但封一批是一批）。

2. 使用强密码与密钥对：

   • 禁用root用户的密码登录，强制使用SSH密钥对。
   • 为所有系统用户设置复杂密码，并定期更换。

3. 保持系统和软件更新：

   # CentOS/RHEL
   yum update -y --security
   # Ubuntu/Debian
   apt update && apt upgrade -y
   

   定期更新可以修复已知的安全漏洞。

4.3 部署主动监控与防护

1. 安装阿里云安骑士（云安全中心）：这是阿里云提供的免费主机安全防护软件。它能提供漏洞预警、基线检查、异常登录报警和病毒查杀功能。安装后，它可以帮助你发现之前忽略的安全隐患。

   # 安装安骑士Agent
   wget http://update.aegis.aliyun.com/download/install.sh
   chmod +x install.sh
   ./install.sh
   

2. 配置自定义监控报警：在阿里云云监控中，为CPU使用率、网络流出流量（挖矿会持续外联）设置报警阈值。例如，CPU持续5分钟超过80%就发短信告警，让你能第一时间响应。

3. 定期审计与备份：

   • 定期使用 rpm -Va 或 debsums 检查系统关键文件是否被篡改。
   • 最重要的：为你的业务数据和关键配置定期制作快照或备份。一旦系统被彻底破坏，你可以快速回滚到一个干净的状态，这是最后的防线。

这次与 [crypto] 挖矿病毒的遭遇战，花了我大半天的时间。从最初的警报、手忙脚乱的排查，到步步为营的清剿，再到事后的深度复盘和加固，整个过程就像一次紧张的安全演练。对于运维人员来说，服务器安全没有一劳永逸，它是一场持续的攻防战。攻击者的手段在进化，我们的防御意识和措施也必须随之升级。经过这次教训，我把手上所有服务器的安全配置都重新过了一遍，该加固的加固，该关的端口坚决关掉。希望我的这次实战记录，能帮你下次遇到类似问题时，能更快地定位问题、更彻底地清除威胁，更重要的是，建立起防患于未然的安全体系。