1.现象接到客户电话，说他的云服务器被提供商禁止访问。原因是网络流量爆满，服务器没有停止对外发包，在确认客户没有突然增加业务量后，初步判断服务器可能遭受了流量攻击（DDOS），但是根据按常理来说，客户的业务系统是一个小型的web系统，平时流量不大，影响一般，不会遭受DDO。带着这些疑问，我想去clientserver的login方法。废话不多说，我们进入系统一探究竟。2.问题排查下图是登录系统后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目录下提到了，那就去这个目录看看是怎么回事。继续上图：我发现了一些隐藏的病毒文件，比如lsofpsnetstatss，这些是变种病毒文件，主要用来替换系统中的一些命令，看到netstat命令就基本明白这个的用意了病毒，无非就是发送流量包，造成网络瘫痪，病毒更换系统原有的包，更换为重写的命令包。这样一来，它既隐藏了自己的行为，又不会对服务器造成太大的影响，但它真正的目的是把我们的机器当肉鸡用。真是用心良苦。记录下这条线索，然后继续通过dmesg命令查看系统信息，看是否有异常。上图：果然有异常信息。nf_conntrack是iptables中的连接跟踪模块。它通过哈希表记录已建立的连接，包括其他机器丢包出现在到本机的连接，从本机到其他机器，或从本机到本机的连接。这是因为服务器访问量大，内核netfilter模块conntrack参数配置不当，导致新连接掉线。查看nf_conntrack_max设置有多大：[root@server~]#cat/proc/sys/net/netfilter/nf_conntrack_max2097152nf_conntrack_max设置了200多万，已经设置很大了。好像不是这个参数设置造成的。估计应该是上面的一些异常进程导致的。3、开始工作通过上面发现的蛛丝马迹，为了快速解决问题，先尝试关闭或删除进程和文件，然后看看网络能否恢复正常。如果你什么都不做，那就开始吧！第一步，先删除/usr/bin/.sshd文件，然后关闭这个文件对应的进程，如下图：这样，先删除进程对应的文件，然后kill掉.sshdprocess，则无法重新启动该进程。第二步，删除/usr/bin/dpkgd目录下的所有变种病毒文件，同时删除/usr/bin/apgffcztwi文件，写一个脚本，批量删除如下：执行后删了，发现ps命令不行，可恶啊，不过，这个问题对我来说不难，重新安装一个ps命令，或者从别的机器copy一个ps命令就可以了，这里简单一个，重新安装一、安装过程见下图：大家可以看到这个操作，首先看到ps命令是属于一个rpm包，然后yum在线安装一个新的包。安装好procps包后，就可以再次使用ps命令了。现在通过ps命令查看到的系统信息才是真正的系统。刚才的ps命令是加壳的，屏蔽了系统中的很多暗活动。还是很兴奋，接着执行了一个lsof命令，发现了新东西：刚刚删除了/usr/bin/apgffcztwi文件，但是自动生成了一个新文件，/usr/bin/fhmlrqtqvz，还有一个文件/usr/bin/fgqnvqzzck已删除，但进程依然存在，删除状态为文件。而新生成的文件还是10个字符。看来这个病毒程序被低估了，继续深入研究！考虑到病毒文件会自动生成，感觉应该由linux下的crontab来完成，所以如果病毒篡改了crontab，就去看看吧。切换到系统的/var/log/cron目录下（该目录记录了linux下所有用户的定时任务信息，crontab-u-e方式写入的定时任务会在该目录下生成文件），没有看Anyfiledoesnotseemlynotseemedbytheuser-levelcrontab.然后查看系统级的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–addxxx，修改自启动项/etc/rc.local，使×××程序开机自动运行。这就是杀不死病毒进程的原因。至此，病毒运行的原理就清楚了，接下来的工作就是清除病毒程序了。4、杀毒杀毒也是需要技巧的。如果直接删除kill.sh文件，会发现又自动生成了这个文件，说明病毒程序正在运行。那么如何彻底清除可以通过以下方式实现：通过top或者lsof命令，可以得到自动启动的×××进程的pid为17161，然后执行如下操作：kill-STOP17161注意，这里的-STOP选项的意思不是关闭进程，而是停止进程。进程停止执行后，进程仍然存在，从而绕过了病毒进程的监控。紧接着，一些硬货：chattr+i/etc/crontab这样，首先锁定crontab文件，不让任何进程写入数据。现在你可以悄悄删除之前那些病毒文件了。先删除这个kill.sh文件，让它不再定时执行：[root@server~]#ll/etc/cron.hourly/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一直处于stopped状态的病毒进程：[root@server~]#kill-917161现在可以直接执行kill-9操作，因为病原体已经被删除，定时任务文件也被锁定，定期执行的脚本也被删除，因此病毒无法再恢复。最后看看病毒清除后的系统状态：整个世界都安静了。但是，但是，好像又发现了什么，没错，发现有一个redis进程在运行。瞬间明白了这次事件的原因：估计是Redis未授权访问漏洞导致的。经过验证，确实如此。服务器上的redis没有密码认证机制，可以直接登录，不过这也没什么。最悲催的是redis的6379端口默认是全网开放的。....这里科普一下什么是crossvirus，它是由一个或十几个随机字母组成的木马病毒进程，主要目的是消耗服务的各种资源。属于挂马，这种病毒会自我保护，自我恢复。主要特点是会发出大量的数据包。
