十字符病毒，杀不死的小强：一次服务器沦陷实录

一、现象

接到客户的电话，说自己的云服务器被提供商禁止访问了，原因是监测到网络流量爆满，服务器不停地向外发包，在确认客户没有业务量突增的情况下，初步判断可能服务器遭受了流量攻击（DDoS）。

不过按照常理来说，客户的业务系统就是一个小的Web系统，平时流量不大，影响力也一般，不至于遭受DDoS，带着这些疑问，要到了客户服务器的登录方式。现在我们废话少说，还是进入系统，一查究竟吧。

二、排查问题

下图是登录系统后，执行top命令的输出结果，综合查看，系统整体负载并不高，但是带宽占用很高，由于云服务器带宽基本耗尽，SSH登录服务器也非常慢，几乎不能执行任何操作。

此外，还发现第一个进程占用很大CPU资源，就是名为apgffcztwi的进程，这个进程名刚好10个字符，这是什么进程，名字相当古怪，肯定有问题，从文件名看出，这不像一个正常的系统进程。

既然有古怪，那就看看这个进程是哪个程序启动的，操作方式见下图：

简单吧，通过刚才那个进程的pid，然后去proc下面查看pid目录下面对应的exe文件，就能找到进程对应的启动程序，Linux就是这么敞亮，一下子找到了这个程序位于/usr/bin目录下。

既然找到了这个程序，那就详细查看下这个程序的属性信息吧，如下图：

看到了吗，第一个文件，文件的读、写和执行属性均没有，相当古怪。好吧，先记录下来这个文件的位置和路径。

下面继续查看系统进程信息，看看有无其它异常，通过ps命令又发现了新的线索，如下图：

在/usr/bin目录下有隐藏的.sshd文件，这个文件是正常系统所没有的，又一个可疑线路，仍然记录下来。

继续查看系统进程，可疑进程还远远不止这些，这不，又发现了一个可疑进程，如下图：

/usr/bin/dpkgd/ps -ef这个进程很明显是个变种的病毒，因为我们指定ps命令肯定不会存在/usr/bin/dpkgd目录下，既然说到/usr/bin/ dpkgd目录，那么就到这个目录下去看个究竟，继续上图：

又发现一些隐藏的病毒文件了，比如lsof ps netstat ss，这些都是变种病毒文件，主要用来替换系统中的一些命令，当看到netstat这个命令时，基本明白了这个病毒的意图，它无非就是发流量包，造成网络瘫痪，病毒替换了系统原有的包，换成自身经过改写的命令包，这样，既隐藏了自己的行为，又不会对服务器造成太大影响，但是它的真正目的就是用咱们的机器做肉鸡啊。真是用心良苦。

记录这个线索，然后继续通过dmesg命令查看系统信息，看看有没有异常，上图：

果然有异常信息，nf_conntrack是iptables里面的连接跟踪模块，它通过哈希表记录已建立的连接，包括其他机器到本机、本机到其他机器、本机到本机的连接，出现dropping packet，就是由于服务器访问量大，内核Netfilter模块conntrack相关参数配置不合理，导致新连接被drop掉。查看nf_conntrack_max，看看设置多大：

[root@server~]# cat /proc/sys/net/netfilter/nf_conntrack_max

2097152

nf_conntrack_max设置200多万，已经设置很大了，看来不是这个参数设置导致的。估计是上面的一些异常进程导致。

三、开始解决问题

通过上面发现的几个线索，为了能快速解决问题，先尝试关闭或删除进程和文件，然后看看网络是否能够恢复正常，一不做二不休，开整吧!

第一步，先删除/usr/bin/.sshd文件，然后关闭此文件对应的进程，看下面的图：

这样先删除进程对应的文件，然后kill掉.sshd进程，那么，进程就无法重新启动了。

第二步，删除/usr/bin/dpkgd目录下所有的变种病毒文件，同时删除/usr/bin/apgffcztwi文件，写个脚本，批量删除如下：

执行删除后，发现ps命令不好使了，可恶啊，不过，这点问题，难不倒俺，重新安装一个ps命令即可，或者从别的机器拷贝一个ps命令过来，这里来个干脆的，重新安装一个，安装过程看下图：

大家能看到这个操作吧，先看看ps命令属于哪个RPM包，然后yum在线安装一个新的包即可。

这个ProcPs包安装完成后，ps命令又可以使用了，现在通过ps命令查看到的系统信息，才是真实的系统啊，刚才那个ps命令是加壳的，屏蔽了很多系统中黑暗的勾当。

还在兴奋中，接着执行了一个lsof命令，又发现新情况了：

刚刚删除了/usr/bin/apgffcztwi文件，但是又自动生成了新的文件，/usr/bin/fhmlrqtqvz，并且还有一个文件/usr/bin/fgqnvqzzck已经被删除了，但是进程仍然存在，那个deleted就是文件的状态。而且新生成的文件，仍然是10个字符。

看来低估这个病毒程序了，继续往下深究。

考虑到会自动产生病毒文件，感觉应该是Linux下的crontab完成的工作，那么是不是病毒在crontab里面做了手脚？

切换到系统的/var/log/cron目录下（此目录记录了Linux下所有用户的计划任务信息，以crontab-u-e方式写入的计划任务都会在此目录下生成文件），没看到任何文件，看来不是用户级别的crontab在作怪，那么再看看系统级别的crontab，就是/etc/crontab文件，贴图如下：

看最后一行，发现了一个定时任务，此任务每三分钟执行一次，任务对应的是个kill.sh脚本，找到脚本就好办了，看看这个脚本的内容：

脚本很简单，但是却是个重大发现。此脚本会自动重启网卡，然后执行一个cp操作，将 /lib/libkill.so文件复制一个/lib/libkill.so.6文件，然后执行这个文件。这个文件是个二进制的文件，无法查看内容，猜想应该就是自动生成那个十个字符文件的病原体。

这里看到的病原体名称是libkill.so，它的名称不是固定的，常见的还有libudev.so、 /lib/udev/udev等类似名称，但是作用应该都是一样的。

到这里为止，思路基本清楚了。

这个×××程序执行的原理应该是这样的：libkill.so是所有进程的病原体，通过kill.sh脚本每隔3分钟自动检测一次，如果发现病毒程序不存在了，就从病原体复制一份儿到/lib/libkill.so.6，病毒副本/lib/libkill.so.6执行后，就会生成一个随机命名（10个字符）的程序，放到/usr/bin/、 /boot，/etc/init.d等目录下。同时还修改了自启动配置chkconfig–add xxx，修改自启动项/etc/rc.local等，让×××程序开机自动运行。

这就是无法杀掉病毒进程的原因。

至此，病毒运行的原理已经清晰了，下面的工作就是清除病毒程序。

四、清除病毒

清除病毒也是需要技巧的，如果直接删除kill.sh文件，你会发现，这个文件又自动生成了，这就是病毒程序在起作用。

那怎么彻底清除呢，可通过下面方式实现：

通过top或者lsof命令可以获取那个自动启动的×××进程的pid为17161，然后执行如下操作：

注意，这里-STOP选项的含义，不是关闭这个进程，而是停止这个进程。停止执行后，进程仍然存在，这样就绕过了病毒进程来监测。紧接着，再来点硬货：

这样，先锁定crontab文件，不让任何进程写入数据。

下面就可以安静地删除之前的那些病毒文件了。先删除这个kill.sh文件，让它不再定期执行：

接着删除/usr/bin下和/etc/init.d下的所有可疑文件：

比如上图中，第1、2、4、5、6都是可疑文件，随便看一个文件：

可以看到，这个文件又指向了/root/xd文件，而这个xd文件肯定也是病毒文件，需要删除。

最后，删除病原体文件：

[root@server ~]# rm -rf /lib/libkill.so.6

[root@server ~]# rm -rf /lib/libkill.so

最最后，别忘了，还要清理现场，关闭一直处于停止状态的那个pid为17161的病毒进程：

现在就可以直接执行kill-9的操作了，因为病原体已经被删除，定时任务文件也被锁定，定时执行的脚本也被删除，所以这个病毒再无回天之力了。

最后，再看下清除病毒后的系统状态：

整个世界清静了。

但是，我突然又好像发现了什么，是的，我发现了一个Redis进程在运行。瞬间，我明白了这个事件发生的原因：估计是Redis未授权访问漏洞导致的。

经过验证，确实如此，服务器上的Redis没有密码验证机制，可直接登录，不过这不算什么，最悲催的是Redis的6379端口默认对全网开放。

这里科普下什么是十字叉病毒，它是一个或者多个十位随机字母组成的木马病毒进程，主要目的是消耗服务各项资源。属于一种挂马，此病毒会自我保护和自我恢复。主要特征是会往外发送大量数据包。

最后，引用别人一句话，安全无小事，防微杜渐是关键。运维人要牢记啊！

原文发布时间为：2018-11-8

本文作者：南非蚂蚁

本文来自云栖社区合作伙伴“DBAplus社群”，了解相关信息可以关注“DBAplus社群”。