内部 OpenStack 云平台被黑了

问题导读
1、 OpenStack 云平台被攻击了，怎么办？
2、怎样做，才能尽可能的使系统安全稳固？

公司内部搞了一台服务器，专门搭建了一个 OpenStack 云平台，做了端口转发，供我哥几个做开发用着玩。刚好这几天搞了一个二手网件路由器，折腾了下 dd-wrt 固件的功能，发现内部网络很不稳定，一开始以为是 dd-wrt 固件的原因，刷回原厂固件后，还是出现这种情况，那就排查呗。换了个 TP 路由器还是一样，确定了不是路由器和固件原因。

发现 OpenStack 云平台网络有延迟现象。查看 syslog 后，出现如下错误：

nf_conntrack: table full, dropping packet
复制代码

看了下连接都到上限了，难怪内核会出现丢包情况：

# wc -l /proc/net/ip_conntrack
65520 /proc/net/ip_conntrack
复制代码

查了下资料，基本上适合我的有两种没有解决方法的方法：

不跟踪连接（添加 iptables 规则后，VM 出不了外网了。）
调整连接上限（不是解决办法的办法）

为什么会有这么多连接呢？

查看了下网络流量、连接，发现有几个进程一直循环发送数据。查到进程后，感觉很奇怪，从来没有见过这些服务，感觉系统被黑了。
备注：这张图使用的是iftop 工具检测。

结果找到了如下几个进程，被人当肉鸡了，因为我的 root 密码是 123123，弱口令阿…

搜索了下系统，发现在 rc.local 中有如下脚本:

Ok，去 /etc/ 删掉这下程序，并 kill 掉进程.

同时在 crontab 里也发现了异常，4000 多行的重复信息:

4000 多行的信息，就为了掩饰 80 多行的脚本:

删掉 Crontab 任务，重启机器，发现没有异常。只能在观察几天看看有没有异常。

无意中发现 /etc/cupsdd /etc/cupsddh 这两个文件还存在，继续删掉。过了一会还有。

root@cloud:~# grep -r cups /etc/rc* 2> /dev/null
/etc/rc1.d/S97DbSecuritySpt:/etc/cupsdd
/etc/rc2.d/S97DbSecuritySpt:/etc/cupsdd
/etc/rc3.d/S97DbSecuritySpt:/etc/cupsdd
/etc/rc4.d/S97DbSecuritySpt:/etc/cupsdd
/etc/rc5.d/S97DbSecuritySpt:/etc/cupsdd
复制代码

好家伙，还搞了一个开机自启动服务：

root@cloud:~# cat /etc/init.d/DbSecuritySpt
#!/bin/bash
/etc/cupsdd
复制代码

移除自启动：

root@cloud:~# update-rc.d -f DbSecuritySpt remove
 Removing any system startup links for /etc/init.d/DbSecuritySpt ...
   /etc/rc1.d/S97DbSecuritySpt
   /etc/rc2.d/S97DbSecuritySpt
   /etc/rc3.d/S97DbSecuritySpt
   /etc/rc4.d/S97DbSecuritySpt
   /etc/rc5.d/S97DbSecuritySpt
复制代码

在删：

killall cupsddh
rm -fr /etc/cupsdd*
复制代码

还有阿：

rm -fr / 7777777 asd csess dlcfg doorn fake.cfg index.html* meis* meiun* nodeJR*
update-rc.d -f DbSecuritySpt remove
rm -f /etc/init.d/DbSecuritySpt
rm -fr /etc/cupsdd*
killall cupsdd cupsddh
rm -fr /var/crash/*
复制代码

OK，没了。