前言

前几天aws的ec2服务器被攻击了，被莫名人士植入了一个minerd的恶意程序，下面简单记录一下对这个恶意程序的处理过程

问题发现

我们使用一台aws的ec2服务器来托管网站，前几天登录网站界面的时候一直在loading界面，死活无法登录。当我想终端登录ec2的时候也是死活登不上去。当时就有种不翔的预感，要GG。稳下来后，查看aws的CloudWatch监控记录，发现近段时间的ec2的CPU利用率一直很稳定的保持在100%。。。原来CPU被用完了，难怪怎么都登不上去，网站也无法运作。

问题解决

登录ec2

先得想办法登录ec2，看看到底发生了什么。注意：登录不上ec2的时候，千万不能随意的重启或者停止ec2；因为这样的话，存储在上面的数据可能会丢失。

但是cpu占用率始终保持在100%，怎么也登不上ec2。只能使用大招了。使用一下步骤曲线救国：

  1. 登录aws控制台。对现在的这台ec2（记为ec2one）的系统盘，也就是根卷创建一份快照
  2. 根据刚创建的快照创建一个卷（也就是：磁盘），这样就复制了ec2one的系统盘
  3. 启用一台全新的ec2（记为ec2two），注意登录密钥和ec2one的相同
  4. 停用ec2two，卸载ec2two的根卷；将2中创建的系统盘绑定到ec2two上，作为它的系统盘（注意：指定为/dev/xvda，不然就被认定是一般磁盘；这时ec2two没有系统盘，无法启动）
  5. 启动ec2two，并终端登录

通过这样的方式就创建了一台和ec2one相同的机器 ec2two，并且登录上去了。

发现问题

登录ec2two之后，使用top指令查看cpu的占用情况。过一段时间后，发现一个minerd的进程占用了90多的cpu，并且居高不下。

minerd virus

google了一下，这是个’挖矿‘的程序，估计是我这台服务器被莫名人士拿来挖比特币了。所以果然是服务器中毒了

解决经过

  1. 先kill这个进程，没用，过一会这个进程又出来了
  2. 使用 ps aux | grep minerd 查看什么程序在运行这个进程，发现了一个 /opt/minerd 的在运行这个进程；进入/opt删掉minerd，没用，多一会，这个minerd的可执行文件又出来了。。。
  3. google，给出的答案居然是安装杀毒软件。还真是头一次在linux上面装杀毒软件。。
  4. 下了一个免费的linux杀毒软件：shopos，官网看上去高大上，整个软件也有个500M左右，应该比较靠谱。
  5. 安装，按照说明扫描杀毒，结果minerd进程还在不说，还把ps等指令给删除了。。。估计是我的打开方式不对，这时候还是很想念360的。你说他怎么就不出一个linux的360安全卫士呢？
  6. 再google，发现一位国内码农遇到的情况和我相同，最后实践下来而确实靠谱，附上链接：阿里云服务器被挖矿minerd入侵的解决办法
  7. 说一下这个最终解决方法
    1. 关闭访问挖矿服务器的访问 iptables -A INPUT -s xmr.crypto-pool.fr -j DROP  和  iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP
    2. chmod -x minerd  ,取消掉执行权限， 在没有找到根源前，千万不要删除 minerd，因为删除了，过一回会自动有生成一个
    3. pkill minerd 杀掉进程
  8. 根据这位高人所说，之说以会被入侵，是因为redis服务器的漏洞。在ec2上面安装了redis，但是没有限制ip访问，开放的还是默认的6379端口，而且还不设置访问redis的密码的话，莫名人士就可以通过redis来进入这台服务器。显然我们之前的redis的访问条件就是这么的宽松。。。 看看如何限制redis的访问
    1. 因为我们网站需要使用redis，才安装的。但是这个redis只会由跑在nginx服务器上的php代码来访问，所以说只有ec2自己才会访问redis。
    2. 所以登录aws的控制台，在安全组中，将之前开放的6379端口关闭
    3. 在redis的配置文件中，限制访问ip只能是 127.0.0.1；并且改变redis的默认的6379的端口号
    4. 在redis的配置文件中，设置redis的访问密码（AUTH）
    5. 重启redis
  9. 为了验证是不是由redis引起的这次事故，进入/opt，root下的/.ssh文件夹中看看，果然在authorized_keys里面发现了redis的一些相关的东西；而且他的密钥居然跟ec2-user的/.ssh中的一样。看来果然是通过redis进到了ec2，并且拿到了登录ec2的密钥。删除这些相关的文件

一波三折

本以为事件就这么顺利的解决了，没想到第二天aws又发来警告，网络输出超过了阈值。。。认真想想，这次的cpu没有报警，但是网络输出报警了。那么应该是挖矿程序没有再跑了，但是还有其他的程序将挖到的数据传输出去。

其实之前的那位高人所说的步骤中的最后一步，我没有去执行，就导致了这个问题。这一步就是使用 service stop crond 或者 crontab -r 删除所有的执行计划，也就是定时计划。

我进入ec2后，切换到root用户，使用 crontab -l查看所有的执行计划，果然有一个是定时执行一个 /tmp文件夹下面的 chongfu.sh 脚本。查看这个脚本，他会定时将所有tmp文件夹里的数据通过wget的方法传输到一个指定ip的机器上面。那么应该就是这个问题了。

先使用 crontab -r 删除这个定时执行 chongfu.sh 脚本的计划，再 pkill chongfu.sh 杀掉所有已经在执行的这个脚本。这个数据传输也就解决了。

查查看这个ip，果然是一个中国的ip，也就不难解释这个脚本为什么叫 chongfu.sh 而不是 repeat.sh。哎，国人何苦为难国人啊

后记

经过这次的事件后，按常理是得总结点什么东西：

  1. 要对aws进行访问限制，之前就是太宽松才被有机可乘。关掉没必要的访问端口，将ssh的端口设置成本机的ip等等
  2. 对aws要做好备份，不然那一天aws又登不上去了。定期对aws的系统盘以及数据盘进行快照备份
  3. 对于aws磁盘的选择，也就是卷的选择，最好是ebs。因为其他类型的卷可能在停止或重启ec2时，会丢失数据
  4. 使用好aws的CloudWatch，可以实时监控aws，发生问题时可以及时收到通知

参考