老旧CACTI服务器守卫战之：我不是肉鸡

        最近运维的兄弟反映一台老旧的机器经常发出莫名的流量，甚至堵塞了线路。这是一台许多年前安装的CACTI监控机器，按照运维兄弟的说法，这种CACTI的集成监控环境，开发发布者已经多年没有更新了。在我们的使用中平时业务流量极少，然从运维方提供上看，确实有莫名的业务上无关的流量。

图一：旧机器出现莫名的流量尖峰堵塞线路

        登录上机器一检查，该机器由于几年疏于管理，开放了许多本该限制在内网的端口。包括 161 SNMP端口、3306MYSQL访问端口，7000 CACTI的WEB服务端口（APACHE +PHP），由于机器老旧，并缺乏专门的管理，估计机器成了黑客练手的靶机。了解了一下，该CACTI服务机还在用，不能废掉。于是简单制定了一下策略，（1）确定尖峰流量产生的原因，（2）重装机器 （3）加强对外端口管理的限制策略。

        我并不是专业的运维人员，也不是计算机安全人员，却是网络研发人员，所以，最简单确认攻击的原因是抓包分析流量。直接让运维兄弟从交换机限制流量，然后抓包，静待分析。刚刚开始抓包没多久，管理连接忽然断了，嘿，来了，尖峰流量堵塞了链路，所以，登录的SSH连接断了。马上从另外的端口登录，取回抓包文件分析。作为一个熟手的网络流量分析人员，轻而易举就提取了峰值流量，乖乖，这台机器被当成是DDOS反射放大攻击的肉鸡了。

图二：DDOS反射放大攻击产生的峰值流量

        由于业务上需要向合作伙伴开放SNMP的161端口，但161端口没有进行IP访问限制，恰巧的是，这个CACTI集成机器安装的SNMP版本有个非常适合做DDOS放大攻击的接口，getBulkRequest。于是就顺理成章的被公网上的黑客扫描和利用了。从抓包上看，getBulkRequest有放大系数超过了十倍。

        于是，让运维的兄弟重装机器，然由于种种原因，只能装回CACTI当年的版本和恢复备份的数据，直接对161公网端口进行了访问限制，限制只有合作伙伴的有限几个网段能访问。另外，除了CACTI的服务端口和管理端口，其余端口都不允许公网访问。

        还以为搞完之后，从此过上清静的日子，谁知道，只是清静了一个多星期。之后运维的兄弟又说了，又有有往外发的奇怪的流量，有图为证：

图三：第二种外发尖峰流量

        再次抓包，再次分析，哦哦，老旧CACTI怎么在攻击他人？单向向另一个IP的UDP 80端口不断发包。可以断定，老旧CACTI应该是被远程控制，又一次被用作攻击他人的肉鸡了。

图四：老旧CACTI在攻击他人

        谁在控制老旧CACTI服务器？一个很简单的思路：一定有远程控制的连接，由于非必要的对外访问端口都被封了，也许是服务器被种了反向的连接，主动连接远程控制的服务器。猜测这种远程控制的连接是一种很简单的TCP的明文连接（没什么道理的，就是想这么老旧的CACTI，也许不是顶级高手入侵，一般的黑客只是用最简单的网络连接实现），于是，在抓包文件中的所有报文，寻找TCP的payload(有效载荷)中包含被攻击IP的报文。

        经过一轮分析，还真的发现控制攻击的连接，连接由CACTI服务器主动发起，连接建立后，控制IP下发被攻击的IP，让CACTI服务器发起攻击。

图五：攻击的控制连接

        CACTI服务器主动连接控制IP，说明CACTI服务器上被安装了某种恶意的程序或者插件。顺着连接看发起连接的恶意进程。

图六：发起控制连接的进程

        顺藤摸瓜，发现恶意进程来自CACTI的气象图插件目录，该插件目录被种了一个yyw的恶意执行文件，这个可执行文件发起了攻击的控制连接。

图七：CACTI的气象图插件目录被植入恶意程序

        查询CACTI气象图相关的漏洞，发现这是几年前一个著名的漏洞，是各大网站已经被挖过一轮的老洞，我们的老旧CACTI服务器能存活到今天真不容易。

图八：CVE-2013-2618

        查询APACHE的访问日志，能够清晰的找到入侵的日志，正如漏洞描述，问题出在plugins/weathermap/editor.php的文件中。

图九： weathermap/editor.php  入侵日志

        由于气象图不是我们业务必用的功能，于是，运维的兄弟决定去掉这个plugin和相关的目录。这一次，老旧CACTI的漏洞是不是完全补上了呢？又能清净多久呢？