记一次aws-ec2杀毒经历

前言

前几天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 DROPiptables -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,发生问题时可以及时收到通知

参考

当前网速较慢或者你使用的浏览器不支持博客特定功能,请尝试刷新或换用Chrome、Firefox等现代浏览器