Linux服务器下Linux.BackDoor.Gates.5病毒的简单处理方法

摘要：今年年初的时候，公司负责的项目有相当一批服务器，被病毒侵袭了。。但是只有台服务器上的病毒在发作，已经通过关闭虚拟机的到了抑制，其他的服务器上虽然系统命令被篡改，但是没有达到不能用的地步。

今年年初的时候，公司负责的项目有相当一批Linux服务器，被病毒侵袭了。。
有的人可能会问了，Linux也能被感染病毒？呵呵，答案是可以的。

任何服务器只要把Root或者Administrator权限泄露出去了，对于Hacker来说就拥有无限可能，要知道Hacker就是高级的程序员，呵呵。

记录这篇文章的目的，并不是说按照这篇文章的描述方法，就可以把病毒从服务器上彻底清掉，而是传达给大家一种面对紧急情况时候的应对方法，这个Case归根到底还是要进行服务器的重装的，有人可能会说了，你这不是标题党吗？明明处理不了的东西还要发出来——套用一句老话“就算死也得知道是怎么死的” 。既然搞技术，多钻研一点总是没有错的。

系统弱口令
什么是弱口令？说得简单一点，就是你的密码设定的过于简单了嘛。这个病毒首先就是通过这种方式，来进行暴力破解系统的弱口令，再多说一点什么是暴力？那就是写个程序来回去实验你的密码到底是什么，如果密码比较简单，长度又不够，又不够复杂，基本很短时间内就可以被暴力破解。

问题初期
其实公司负责安全的同事在病毒发现的时候，就已经把这个如何判断是中了这个木马告知了，但是很遗憾的是，给出的解决方法并不能阻止木马继续肆虐。
1.用root 登录系统，分别查看/root、/tmp、/dev/shm执行ls –lrt
凡带有文件：

-rwxrwxrwx 1 oracle oinstall 646674 Mar 10 18:32 .lz1489875542
-rwxrwxrwx 1 oracle oinstall      4 Mar 19 05:40 gates.lod
ZTE
3.22
4.55

均为被攻击。
2.查看/etc/crontab凡带有每三分钟字样的就是被攻击了。
3.用top查看cpu使用情况，受到攻击的系统，cpu会异常的高。

我所看到的现象
跟安全同事发出来的现象不同，我这里看到的现象，有木马的服务器cpu并没有很高，都维持在正常水平，一开始我也没太当回事，因为就1-2台服务器中了，按照安全同事给的操作方法处理了一下，也就没再注意。到后来成片的扩散的时候，这时候意识到问题可能不是那么简单的了。

木马初露锋芒
有句话说得好，永远不要小看你的对手，哪怕他当前非常渺小。
刚才说过了，正是因为我一开始没当回事，所以木马大哥不乐意了，稍微露了两手，直接导致了我将近2天的额外工作量。。。
首先遭殃的是业务系统A，这个系统的实时性很高，用户直接反映功能不好使。
上去一看，程序还在运行，只不过里面日志不刷新了。当时我重启了一下后好了。
不过仅仅好了几个小时，之后又不行了。。当时我的内心有点波澜。。
一波未平一波又起，紧接着业务系统B、C、D...都一样的现象，我当时只想说：我X!

紧急处理过程
当时跟踪了一下午，一直到晚上12点多，最后阻止我不能继续排查问题的原因，还是木马大哥。
这哥们儿的最绝的地方就是，直接把一堆包发到你服务器的网络环境里，直接把你的网络阻塞了。
举个例子：比如有一条马路，有4条车道，现在有6辆车要通过，而且这6辆车很有个性，就是按照6车道的标准去行驶，怎么可能跑的下呢？于是反应到具体现象上，就是我通过crt工具远程到服务器上执行命令，根本没法输入命令，ping了一下，丢包率达到惊人的95%。。。
留一个悬念，放到文章最后说。

那么我之前都做了什么操作呢？
1.执行ps -ef|grep ZTE,用安全同事给的方法进行处理，结果删掉之后马上有新的进程出现，并且木马有很多种展现形式。

2.查看/tmp下目录，执行ls -lart: 发现所有感染的机器，/tmp下均有这两个文件：gates.lod 、 moni.lod

3.上网搜索了下这两个文件，查到一篇比较符合的文章，确定病毒为Linux.BackDoor.Gates.5

文章链接：http://blog.clzg.cn/home.php?...

4.尝试着用文章中的方法来删除病毒
看了文章后，可以得出这么一个结论：

这个病毒首先会替换系统中的一些命令，比如lsof ps netstat ss，看到Netstat，可以知道这个病毒大概要干什么了，无非就是发流量包，造成网络瘫痪，病毒替换了系统原有的包，换成自身经过改写的命令包，可能对本身服务器没影响，但是是用咱们的机器做肉鸡。。

执行命令：

删除过后，发现执行ps -ef语句不好用了，同时重新登陆服务器报错。。。
于是将正常机器上的ps命令复制到该机器上，但是没多久又不行了，做到这里，联想到病毒原理，很容易就分析出来情况了：
病毒是反复覆盖掉系统操作命令，将文件删掉后，每次删除病毒进程，病毒都会复制一个新的病原体到/bin下。
经过病毒修改的文件系统是没办法直接用的，这也就解释了为什么放上去新的好使，过一会儿又不好使了的情况。

5.明白了这个道理，我们可以采用接下来的手段:

用chattr命令阻止病毒修改系统正常的命令：
我们首先将正确的系统命令文件，放到对应目录下，并且用chattr命令保护起来，不允许任何操作，比如rm,mv等。这里放一篇文档：

http://www.ha97.com/5172.html

cd /bin  
chattr +i /bin/ps
chattr +i /bin/netstat
cd /usr/sbin
chattr +i /usr/sbin/lsof
chattr +i /usr/sbin/ss

然后执行如下命令：因为病毒可能在的地方很多，所以有些地方需要手动去改一改，我这里列的应该比较全了。

rm -rf /usr/bin/dpkgd
rm -rf /usr/bin/pythno
rm -rf /usr/bin/bsd-port
rm -f /usr/bin/.sshd
rm -f /usr/bin/sshd
rm -fr /root/ZTE
rm -fr /root/ZTE.1
rm -fr /root/Manager
rm -fr /root/Manager.1
rm -fr /root/1
rm -fr /root/jhost
rm -f /usr/local/zabbix/sbin/zabbix_AgentD
rm -f /usr/local/zabbix/sbin/conf.n
rm -f /root/cmd.n
rm -f /root/conf.n
rm -f /root/IP
rm -fr /tmp/ZTE
rm -f /tmp/gates.lod
rm -f /tmp/moni.lod
rm -f /tmp/notify.file
rm -f /tmp/gates.lock
rm -f /etc/rc.d/init.d/DbSecuritySpt
rm -f /etc/rc.d/rc1.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc2.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc3.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc4.d/S97DbSecuritySpt
rm -f /etc/rc.d/rc5.d/S97DbSecuritySpt
rm -f /etc/rc.d/init.d/selinux
rm -f /etc/rc.d/rc1.d/S99selinux
rm -f /etc/rc.d/rc2.d/S99selinux
rm -f /etc/rc.d/rc3.d/S99selinux
rm -f /etc/rc.d/rc4.d/S99selinux
rm -f /etc/rc.d/rc5.d/S99selinux

6.执行ps -ef|grep root命令：
执行此命令的意义是：该病毒会伪装成常用的命令形式，比如：/usr/bin/dpkgd/ps就是一个异常进程。
参照网上的文章，把root用户下有问题的进程，都找出来，并且kill掉：

kill -9  5663      1  0 Apr21 ?        00:04:55 /usr/bin/bsd-port/getty
kill -9  5698      1  0 Apr21 ?        00:00:00 /usr/bin/.sshd
kill -9 14913      1  0 Mar23 ?        00:00:02 /usr/bin/.sshd
kill -9 25423      1  0 13:15 ?        00:00:00 /usr/bin/pythno
kill -9 30589      1  0 Apr26 ?        00:02:18 /usr/bin/bsd-port/knerl           
kill -9 47879      1  0 13:35 ?        00:00:01 /usr/bin/bsd-port/knerl
kill -9 65205      1  0 14:08 ?        00:00:00 /usr/bin/bsd-port/getty
kill -9 65240      1  0 14:08 ?        00:00:00 /usr/bin/.sshd
kill -9 67423      1  0 14:12 ?        00:00:00 /usr/bin/bsd-port/getty
kill -9 67466      1  0 14:12 ?        00:00:00 /usr/bin/.sshd
kill -9 71342      1  0 Apr10 ?        00:00:01 /usr/bin/pythno
kill -9 71468      1  0 Apr10 ?        00:00:01 /usr/bin/.sshd
kill -9 71873      1  0 14:20 ?        00:00:00 /usr/bin/dpkgd/ps
kill -9 71985      1  0 14:20 ?        00:00:00 /usr/bin/pythno
kill -9 72062      1  0 14:20 ?        00:00:00 /usr/bin/dpkgd/ps
kill -9 72116      1  0 14:20 ?        00:00:00 /usr/bin/pythno
kill -9 72568      1  0 14:21 ?        00:00:00 /usr/bin/dpkgd/ps
kill -9 72626      1  0 14:21 ?        00:00:00 /usr/bin/bsd-port/knerl
kill -9 72631      1  0 14:21 ?        00:00:00 /usr/bin/pythno
kill -9 74582      1  0 Apr10 ?        00:10:44 /usr/bin/bsd-port/getty
kill -9 74615      1  0 Apr10 ?        00:00:01 /usr/bin/.sshd
kill -9 76088      1  0 Apr10 ?        00:00:01 /usr/bin/.sshd

7.进行观察，ps -ef|grep ZTE ， 发现没有该进程再重复产生了，查看 /usr/bin下，之前的病毒本体，主程序也都没有了。

8.延迟一小时后再验证，还是没有病毒进程及病毒本体文件产生，只是在/user/bin下会产生下图的文件：看起来也像个异常的东西，但是因为没有进程跟随，可以忽略了。随后又试验了一台机器，另外一台就没有这个随机文件，猜想可能跟病毒发布者的实际用途有关。

9.手动清理 .conf文件和 /bin下的 lsof ss文件
/bin下的ss 和lsof是病毒自己复制过去的，真正的文件在/usr/sbin下，这两个可以删掉。
.conf文件可能在/tmp或者/root下，根据实际情况删除一下即可。

以上就是我对此问题的思路及全过程，从系统层面上，将该病毒暂时抑制掉了。
要注意我说的，是从操作系统层面上。呵呵。我上面留的悬念，crt都没法操作了，到最后怎么办呢？

用户紧急找了硬件厂商，去机房里实际观测端口的网络流量情况，因为是虚拟机，观测到异常后，直接将虚拟机关闭，因为中木马这事是很严重的问题，没法考虑什么业务不业务的了，必须停掉进行处理。
之后又开始将一台未中毒的虚拟机的系统二进制码拿出来，跟问题服务器做对比，一对比发现。。整个操作系统，文件被篡改了90%以上。。。我们刚才做的那些只不过是九牛一毛而已。
但是只有3台服务器上的病毒在发作，已经通过关闭虚拟机的到了抑制，其他的服务器上虽然系统命令被篡改，但是没有达到不能用的地步。并且通过咱们刚才的初步处理方法，保证了病毒源不再生成，通过限制ip访问，也保证了病毒源不再扩散。

分享这篇文章的目的是，如果你的root密码管理不规范，那么真中了木马，没人能帮得到你了，其他用户中了的话，直接删除用户就可以了，但是root权限是打开一台服务器的大门，这个Case最完美的同时也是最残酷的处理方式，就是重装系统，这样的话安全合规、漏扫的重要性就体现出来了，呵呵。