前言：
之前一直认为放在公网的机器一定要开iptables，放在内网的是比较安全的，这次事件教会我：内网机器、该开iptables也得开！你无法保证内网其他机器不会被攻击进而成为攻击者！
起因：
从2017年12月19日开始，我们发现服务器上的程序运行缓慢，开始我们以为是hadoop本身的问题，于是针对Hadoop进行优化，在20日开始，服务器开始出现反复的重启。针对重启原因我们排除了CPU温度原因、电源管理程序兼容性的原因，并且机房的工作人员也到机房确认了硬件无故障。在后续工作中我们发现top命令和ambari监控提供的CPU占用情况有极大的出入。
问题描述：
CPU占用高，top命令显示CPU使用正常，可用vmstat查看到，后续有ambari metrics和monitorix证明top显示有问题。
下图为其中一台机器的monitorix监控信息
image.png
其中24日至26日空白部分为该机器宕机未记录
可以看出CPU实际使用率是非常高的。（下图为一台正常的没什么操作的机器的监控情况）
image.png
问题分析：
top命令显示的不正常可能是由于遭到了rootkit攻击，ps和top等系统文件被替换，CPU占用率异可能是被植入了挖矿程序，结合阿里给出的解决方案进行检查（链接地址： https://helpcdn.aliyun.com/knowledge_detail/41206.html ）
image.png
image.png
检查结果如下：
image.png
删除掉被隐藏的恶意模块后重启机器、检查CPU运行情况，发现下降至正常水平。
image.png
后续处理：
分析造成本次感染的原因可能是由于其中一台服务器的redis-server的漏洞导致。考虑到是内网环境，仅开放了公网的22端口访问，从公网感染的可能性极低，可能是从内网进行的入侵。我们将针对iptables策略进行更细化的制定，增强对服务器的安全维护，避免因程序漏洞导致的被入侵。
后记：
以上处理仅仅是去除了病毒的挖矿模块，接下来就是分析病毒的入侵方法，经过检查，我在一台装有redis的机器上的/root/.ssh/目录下找到了dump.rdb文件，这是典型的redis入侵的特征，打开后内容如下：
乱码+秘钥
image.png
对这个ID进行baidu
image.png
恶贯满盈的对手！
接下来还发现Iptables修改后重启被自动被加入一些output chain，均为一些莫名其妙的IP
image.png
考虑是被加入了开机启动项和定时任务，定时任务之前被我清理过、开机启动项中我找到了一个wipefs的目录，随手百度一下就发现问题也是命大
image.png
按照如下网页操作
https://www.cnblogs.com/liuchuyu/p/7490338.html
rm -rf /bin/wipefs
rm -rf /etc/init.d/wipefs
rm -rf /bin/ddus-uidgen
rm -rf /etc/init.d/acpidtd
rm -rf /etc/rc0.d/S01wipefs
rm -rf /etc/rc1.d/S01wipefs
rm -rf /etc/rc2.d/S01wipefs
rm -rf /etc/rc3.d/S01wipefs
rm -rf /etc/rc4.d/S01wipefs
rm -rf /etc/rc5.d/S01wipefs
rm -rf /etc/rc6.d/S01wipefs
rm -rf /etc/rc.d/rc0.d/S01wipefs
rm -rf /etc/rc.d/rc1.d/S01wipefs
rm -rf /etc/rc.d/rc2.d/S01wipefs
rm -rf /etc/rc.d/rc3.d/S01wipefs
rm -rf /etc/rc.d/rc4.d/S01wipefs
rm -rf /etc/rc.d/rc5.d/S01wipefs
rm -rf /etc/rc.d/rc6.d/S01wipefs
rm -rf /etc/rc0.d/acpidtd
rm -rf /etc/rc1.d/acpidtd
rm -rf /etc/rc2.d/acpidtd
rm -rf /etc/rc3.d/acpidtd
rm -rf /etc/rc4.d/acpidtd
rm -rf /etc/rc5.d/acpidtd
rm -rf /etc/rc6.d/acpidtd
rm -rf /etc/rc.d/rc0.d/acpidtd
rm -rf /etc/rc.d/rc1.d/acpidtd
rm -rf /etc/rc.d/rc2.d/acpidtd
rm -rf /etc/rc.d/rc3.d/acpidtd
rm -rf /etc/rc.d/rc4.d/acpidtd
rm -rf /etc/rc.d/rc5.d/acpidtd
rm -rf /etc/rc.d/rc6.d/acpidtd
再重启、发现没问题了。但是到这里还需要考虑系统的 ps top等命令是否被替换了，我们还需要进行恢复，这是后话了。
