第一次身处黑客入侵的事故现场

774 查看

昨天下午我正在图书馆刷书复习,突然接到同学的电话。同学是学校某个机构的助理。他告诉我他办公室有台Linux服务器出了问题,总是把带宽占满。情况紧急,办公室老师让他赶紧联系认识的同学,看看能不能帮忙处理下。
本来我是拒绝的……因为我虽然日常都使用Linux,但是从来没弄过服务器。把Linux当做主力桌面环境和把Linux当做服务器伺候,两者是有区别的。所以我让同学再找别人。过了一段时间,他又重新打了电话过来,说是找不到别的人了。于是我只有硬着头皮上了>_<
跟他汇合之后,搭上电梯前往服务器所在的机房。好家伙,第一次进机房,感觉来到一个神殿,四处耸立的机柜中供奉着威严的神灵。四周响起低沉的嗡嗡声,就像看不见的怪虫在齐鸣。
当然我不是来参观机房的。已经有一个网管在现场了。看到还有别人在,我内心顿时轻松了些许,看来还至于硬要我来……于是连接显示器,打开有问题的服务器。登录进去后,迎接我们的是一个像爱丽丝漫游的仙境一样怪异的世界:窗口古怪地变形着,你甚至找不到打开软件的菜单,一切无比地陌生,如同突然陷入达利的《记忆的永恒》

这里先打断一下,这个服务器是有桌面环境的……还好它有桌面环境,不然待会我只能通过w3m来上网了(我手上什么都没带)。震惊了一下子后,我们换了另外一种打开方式,退回到登录界面。刚好发现下面有一个设置,可以选择Gnome窗口登入。于是我们来到了熟悉的Gnome世界……

情况紧急,废话不多说,网管说了下他知道的大概的情况,就是服务器会吞掉所有的带宽限额,导致正常的服务无法运行。输入ifconfig命令,我们当时看到发送的数据已经达到了令人咋舌的地步了……

我们折腾了一番,终于看到了嫌疑犯。使用top命令,看到当前运行的进程中,有一个很可疑的进程,叫做sbin。为什么觉得它很可疑呢?原因有三:

  1. 这个进程占有大量的内存和CPU,如果不是第一,那也是前三。
  2. 这个进程不能用ps显示出来,只能通过top才看得到。
  3. sbin不应该是文件夹的名字么?什么时候变成可执行文件了……这也太明显了!

毫无疑问,服务器被入侵了。sbin作为嫌疑犯,自然遭到了我们的“亲切拜访”。which sbin定位sbin的位置,好,找到了:/var/cache/sbin

cd过去,呃,我对这个目录一无所知……还好能够求助于万能的Google。原来var文件夹存储的是临时的变量,不过下面的cache文件夹作用不大,删了也没多大关系。这时我们又注意到,除了sbin之外,我们还看到其他知名可执行文件,比如manps等等。这下终于明白为什么ps没法找到sbin进程了。查一下PATH变量,果不其然。ls -al一下(当然这里开始就使用绝对路径来调用命令了,还测试了几个知名命令,确认没有更多的冒牌货潜伏其中),看看具体信息,这几个文件都是在几个月前的两分钟内放进来的。

接下来就差证据了。查了一下,发现netstat命令有一个-p参数可以显示某个进程的网络连接情况。于是netstat -p | grep sbin,我们看到了令人震惊的真相……

这个sbin进程建立了大量的pptp协议的链接,就是它导致了服务器的流量暴增的情况。可惜我当时没有拍照,不然就拿出来让大家分析好了。

既然已经找到了罪魁祸首,那么把它杀掉,服务器的问题就解决了……不过这个只是解决了表面问题,我们还是不得而知骇客是怎么进来的,不能排除贼惦记的可能。不过因为网管要下班了,催促我们离开,所以准备明天再深究下去。然后我就继续刷我的书去了。直到睡前才码下这篇文章,总结一下。

最后问诸位一个问题:接下来我应该怎么调查呢?

已知疑点:

  1. 这个进程启动的是pptp点对点协议的服务
  2. 黑客把东西都放在/var/cache/文件夹下,时间是几个月前,但是问题是最近才出现的。
  3. 同时我们发现,整个硬盘被撑爆了,不能通过yum来下载任何东西,甚至连用vi编辑文件都不能(无法产生缓冲区)。

不知诸位有何推论?下一步该前往何方?

2014/7/4 更新

今天早上又去看了下……原来是黑客放了一系列脚本到/var/cache下。其中有一个install脚本,一旦执行它,就会添加一个用户到etc/passwdetc/sudoers中,这样黑客就能通过这个用户登录并获得管理员权限了。而且这个脚本还会调用一连串其他脚本,最终在后台执行sbin这个程序。这样一来,把这个用户以及它的相关文件删掉就好了。猜测黑客也没有获得别的账号的密码,否则他就不需要自己弄一个账号出来。

至于为什么硬盘被撑爆了……这个跟黑客无关,是因为服务器长期没有打理,东西堆太多(而且本来硬盘也不大)。我们查了下几个占用空间特别大的文件夹,里面的文件都是黑客袭击之前就有的,而且都是正常的文件。

这次黑客入侵的事件大概可以告一段落了。虽然还是不知道黑客是怎么入侵到var/cache文件夹的,不过好在这个黑客并不高明,留下了太多的证据,让我们毫不费力地找到了真凶。