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

昨天下午我正在图书馆刷书复习，突然接到同学的电话。同学是学校某个机构的助理。他告诉我他办公室有台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之外，我们还看到其他知名可执行文件，比如man，ps等等。这下终于明白为什么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/passwd和etc/sudoers中，这样黑客就能通过这个用户登录并获得管理员权限了。而且这个脚本还会调用一连串其他脚本，最终在后台执行sbin这个程序。这样一来，把这个用户以及它的相关文件删掉就好了。猜测黑客也没有获得别的账号的密码，否则他就不需要自己弄一个账号出来。

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

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