记一次阿里云linux病毒清理过程
1
起因
因为这台服务器是我们公司内部开发服务器，几乎每个人都有root密码。在两天前突然有同事反馈说偶尔会有ssh连不上，git代码无法提交的问题，刚开始也没有在意，以为是阿里云服务器网络波动的原因。
这天开发又像我反应redis连不上并且ssh也连不上，感觉事情没有想象的那么简单了，还好我在跳板机上能够远程连接上，所以就稍微看了一下。
2
事情并没有那么简单
因为觉得不对劲，所以瞄了一眼监控，发现这台服务器eth0网卡的流量被跑满了，图在下面：
在服务器上通过ifconfig查看，发现eth0这个网卡已经被跑了好几个T的流量了。
知道是因为网卡流量被跑满了，所以要看一下到底是什么进程跑掉的，于是ps -ef看了一下，发现进程真特么多完全没法一眼看出来，想了想既然跑那么多流量那一定也比较吃资源，决定top d1看一眼，不看不知道一看吓一跳，不多说了上图：
这个pid为7796的进程吃了76.2%的CPU，这是要上天啊！！！
3
怎么办？盘它！
二话不说直接kill -9 7796，然后试了一次ssh连接，果然好使，秒秒钟就连上了，然后观察监控，果然流量也下来了。
然而事情并没有这么简单，我还没开始嘚瑟，流量又上去了，ssh也连不上了。
这个还带满血复活的么？事情并不简单，top d1一看，又有一个不认识的进程起来了，还是那么的吃CPU。不管三七二十一又是一顿操作猛如虎秒秒钟杀了它。
满血复活应该是有定时任务啊！！！其实我也不确定有没有，反正有想法总是好的，然后crontab -l看了一眼：
并没有定时任务啊，果然能做这种缺德事的一般脑子都是比较灵光的。还好我看了一眼定时任务的配置文件：
果然是定时任务的原因，然后赶紧把定时任务删了，把定时任务对应目录下的脚本自己down下来，然后删掉。
说了没那么简单，果然真的没那么简单，之前的处理方式太草率了，以为把定时任务删掉之后就万事大吉了，结果没多久又开始了：
这次我觉得慢慢来，看一下这个进程到底是哪里来的，已知进程pid为27894：
查看一下这个进程的具体目录在哪里：
可以看到cwd -> /tmp，进入/tmp目录查看：
该目录下有几个可执行文件，直接删掉！！！
后来还是不放心，参考了网上几篇文章，进行了进一步的检查，将病毒修改过的系统命令从别的正常的服务器上拷贝过来之后重新替换，后期又发现了几个隐藏在系统中的可执行脚本(没来得及把脚本down下来，写这个的时候有点遗憾了！)，都是通过wget去某些服务器上down一些脚本，然后在本地执行的，找到一个删一个，最后终于算是太平了！
然后观察了一段时间，确定没有再次出现redis和ssh连不上之后才算安心了。
4
总结一下
关于这次服务器中病毒的事情个人感觉公司不管是生产还是测试的环境还是要回收root密码，不能以为是测试环境就无所谓，一旦出事情影响还是很大的，毕竟任何服务器只要把Root或者Administrator权限泄露出去了，对于Hacker来说就拥有无限可能，要知道Hacker就是高级的程序员，呵呵。
中病毒很简单，但是要清除病毒真的是很费时费力费脑子还费耐心，所以还是不要把root权限放出去比较安全！
5
参考一下高级程序员写的脚本
最后将down下来的两个脚本放出来，大家参考一下:
#!/bin/sh# Check whether 0anacron was run today alreadyif test -r /var/spool/anacron/cron.daily; then day=`cat /var/spool/anacron/cron.daily`fiif [ `date +%Y%m%d` = $day ]; then exit 0;fi# Do not run jobs when on battery powerif test -x /usr/bin/on_ac_power; then /usr/bin/on_ac_power >/dev/null 2>&1 if test $? -eq 1; then exit 0 fifi/usr/sbin/anacron -s
#!/bin/shPATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/binfor i in `cat /proc/net/dev|grep :|awk -F: {print $1}`; do ifconfig $i up& donecp /lib/udev/udev /lib/udev/debug/lib/udev/debug
