使用阿里云监控处理挖矿病毒

使用阿里云监控处理挖矿病毒

一、发现情况

近日我方代运维的某公司收到阿里云云监控发送的告警信息，提示其账户下一台服务器出现了“可疑安全事件：访问恶意域名”。随后登陆阿里云控制台查看到如下提示

按照提示信息，我们登陆到报警服务器查看，发现有一个nexus用户创建的cnrig文件

使用top命令也发现一个nexus用户创建的cnrig进程，根据进程名称和文件时间推断此进程是一个非常规进程。先结束进程再将可疑文件复制到其他隔离环境备份病毒标本，然后将服务器中的病毒文件删除。再查找服务器是否有隐藏或者遗漏的病毒文件，着重[版权所有，禁止复制，www.runyun-tech.com]查看开机启动项。以上步骤处理完成后重启服务器，通过4小时观察发现此服务器挖矿程序已经不再启动。至此，挖矿病毒处理完毕，接下来便是查找病毒来源。

二、追根溯源

我们使用 last -f /var/log/wtmp 命令查看最近登录服务器的情况，发现一条可疑登录记录。这条可疑登录记录有两个可疑点，首先是我们不会用nexus账号直接登陆，其次是凌晨5点我们是不可能登陆服务器的。

为了查看此用户有些什么操作，我们登陆到这个账号看看操作命令。

#su – nexus

$history

日志文件并没有被删除，因此看见了下载挖矿程序的执行指令

目前可以肯定的是本台服务器被10.7.4.77这台计算机在12月25日凌晨5点左右被远程登录并下载了挖矿程序执行。原来这台被攻击的主机是来自另外一台服务器。

10.7.4.77这台主机也是一台服务器，与本次被攻击的服务器不属于同一个局域网，两台主机之前是通过VPN链路联通的。因为此台服务器不由我方直接管理，待向甲方索取登陆方式后登陆到10.7.4.77这台服务器上使用top命令查看资源使用情况，可以看到cpu资源被postgres用户启动的cnrig进程完全占满。

由于之前听说过挖矿病毒设置半载的情况，因此回头查看了云监控的数据，发现在阿里云[版权所有，禁止复制，www.runyun-tech.com]服务器中的挖矿病毒的确将CPU使用率限制在了50%。因此阿里云的那台ecs主机一直没有发生CPU报警，也庆幸购买了阿里云的安全服务，否则可能将会花费更长的时间才能发现。我们在阿里云监控中将CPU报警阈值设置的是：连续30分钟CPU使用率超过80%则报警。通过以下监控图可以看到，在处理挖矿程序前中病毒的服务器CPU一直处于50%的状态。

与阿里云服务器同样的情况，本台服务器也在/var/tmp下面生成了一个cnrig挖矿程序。

按照之前的办法处理病毒并追踪来源。通过last -f /var/log/wtmp命令发现在12月24日下午和12月25日凌晨有一个来自罗马尼亚的IP地址使用postgres账号登陆过服务器，随后查防火墙信息发现此服务器22端口被映射在外网中。

到此为止整个过程应该清楚了，但是还有一个问题就是攻击者如何知道通过10.7.4.77去登陆10.7.6.*和10.7.4.*（调查发现此服务器也沦陷），这两台服务器网段不同，很难联系到一起。同网段（10.7.4.x）还有30台服务器，10.7.6.x网段[版权所有，禁止复制，www.runyun-tech.com]还有100多台服务器，单单对这两台服务器下手是有很大疑问的，而且从执行的两条指令来看，非常精准，应该也不是扫描出来的弱点。

经过漫长的服务器搜索，最终发现作为跳板的服务器上有保存这两台服务器的登陆信息。事后确认，因为这是一台测试和开发服务器，运维人员没有加强管理，开发人员为了方便将部分服务器信息保存在了这台测试服务器上，导致攻击者查阅到了另外两台服务器IP地址，随后发起了攻击。

三、过程回归

我们还原一下本次挖矿病毒的中招过程

1、 攻击者通过扫描工具扫描到服务器A（10.7.4.77）对外暴[版权所有，禁止复制，www.runyun-tech.com]露的端口（防火墙将5432端口映射到了公网）。

2、 使用字典、社工等对此服务器账号和密码进行尝试并获取到了postgres账号口令。

3、 登陆到服务器A执行挖矿程序，并通过查看服务器A保存的B、C服务器连接信息将病毒也植入到B（部署在阿里云的ECS）、C服务器上。

4、 对服务器进行分别对待，线下的服务器使用100%的CPU资源挖矿，阿里云机房使用50%的CPU资源挖矿。

四、解决方法

1、 杀掉挖矿进程、删除挖矿程序、重启服务器并观察。

2、 删掉服务器上的公钥，防止直接登陆其余服务器。

3、 删除对外映射的服务器端口。

4、 加强端口管理，并将ssh将端口暴露范围从10.7.0.0/16降低到10.7.6.*（堡垒机的IP地址），数据库等端口只允许应用服务器访问。

5、 加强服务器管理，严格区分服务器用途并做好互访策略，加强程序开发人员安全意识培训，要求加强密码强度。

五、经验总结：

1、 服务器必须安装监控软件用于实时监控服务器状态

本次病毒处理是基于阿里云的报警信息，然后顺藤摸瓜排查出的三[版权所有，禁止复制，www.runyun-tech.com]台中挖矿病毒的服务器，其中后面的两台服务器由于是线下IDC机房中的服务器，当时并没有安装监控程序，因此中病毒时并未察觉。推荐使用阿里云的云监控服务器，相对准确、及时，并且简单的报警也是免费的。生产服务器一定使用安全手段、安装安全程序（比如阿里云的事态感知），阿里云的事态感知的不同版本有不同的功能，大家可以根据自己的情况选择。Linux服务器最大的麻烦是挖矿病毒，阿里云的云监控可以察觉，势态感知也会报警。Windows服务器最担心的勒索病毒，可以购买阿里云的势态感知，也可以在云监控中定义磁盘繁忙程度。因为勒索病毒会对硬盘加密，加密是磁盘处于非常繁忙的状态，可以设置IOPS和读写速度报警阈值。这样在病毒爆发时可以抢救一部分数据。阿里云的事态感知也有“防勒索”功能，可以根据自身情况选择是否开启，其余的云厂商或者线下机房也要有对应的解决方案。

2、 遇到系统报警需要立刻查看，一般比较准确

本次从接到阿里云报警信息到处理花了大概一周时间，由于运维人员人手不够，而报警的服务器也并不是核心服务器，因此并未引起重视，一周后才开始着手处理。更因为阿里对挖矿只是报警而不像华为云会断网，心想反正不影响业务，因此一直搁置在那里。

3、 服务器端口需要严格管控，登陆范围也需要合理设置

阿里云可以使用安全组的方式来进行端口隔离和访问，本次阿[版权所有，禁止复制，www.runyun-tech.com]里云机房中病毒的服务器因为刚刚上线，还有一部分资料需要迁移，因此端口开放程度较高（10.7.0.0/16），开放了整个服务器网段，麻痹大意和疏忽给了攻击者可乘之机，我们在实践中也要注意，在业务系统部署过程中应该将安全因素也考虑其中。

4、 公网端口映射相当危险，非必要情况不能开启，开启后要及时关闭

本次病毒入口是一台测试环境的postgresql数据库服务器，在这台服务器上开发人员还安装了nacos、zipkin、Sentinel等多种应用，为了方便管理开发人员申请了外网ssh的权限，并且将各种账号和服务器信息保留在了服务器上。

5、 密码必须有强度，账号和密码不能相同

本次排查中发现，开发人员为了方便，使用了非常简单的密码，违反了密码安全大忌，账号和密码相同且使用的默认账号。

6、 服务器要提前规划，设计和部署，服务器要专人专管

由于预算原因，很多公司都会将服务器资源“最大化”利用，从稳定性[版权所有，禁止复制，www.runyun-tech.com]上来说却不是最优的选择。此次最先中病毒的服务器之前仅仅是一台postgresql数据库测试服务器，在业务新增过程中，各种应用越来越多，操作人员越来越多。各种水平的人员都在同一台服务器上操作，管理非常混乱。