谁动了我的奶酪（数据库）_攻击防范实战记录

转载于：http://blog.csdn.net/ex_net/article/details/7647930

 

最近几个月，开发团队出现了莫名其妙的问题，开发的服务器经常莫名其妙死机，然后无法启动。由于服务器是Windows2003的系统，然后做了RAID1的阵列。每次死机后，用2003启动盘启动电脑后无法看到那个“该死的阵列”。把硬盘拆到别的电脑上看到的是一个超大分区490多GB，根本无法通过简单的办法把数据拿出来。

心想，反正还有备份，直接格式化重装。。。。

就这样，死机一次，重装一次，被折磨了几个月后，我终于忍不住了，一定要把这个问题查清！

到底什么原因导致了“windows2003的服务器莫名奇妙的死掉”。

首先是怀疑服务器里安装的软件有问题，因为大多是D版的，因此很难判断是不是D板软件里有木马、病毒、恶意程序等。

不过用360、瑞星、金山、卡巴，杀（查）一个遍都没有任何异常发现，不过为了安全起见，我还是费了九牛二虎之力把能换的软件都换成了“开源”或“免费”的了。至少这样应该不会下载到“由毒的软件了吧”

软件是换掉了，没过几天，服务器又死了，真是把我们气疯了。 哪里来的问题呢？不过这次好在好点是发现的及时。

开始2~3分钟，团队内部有人报告“数据突然消失了”，我们里面在MSSQL的查询分析器里输入 select * from 查看，果然所有表的数据【意外消失】了。

3~5分钟后，团队有人报告“数据表突然消失了”，我们立即查看，果然“Table表”全部被“干掉了”。

在接下来的几分钟内，数据库的存储过程、视图、函数、。。。。反正能“消失的”的都消失了。。。。

。。。。慢慢的。。。开始发现D盘、E盘、C盘的文件开始“消失了”。。。。

终于。。。服务器黑屏了。。。。

oh my god!

上帝召唤了。。。。

又一次中招了。。。

我们在一个月内就这样被折腾了几次，结果仔细分析。首先可以排除是自己人干的，比较我对团队所有的成员都是非常的信任，相信他们没有必要这么做。

那么，攻击可能是外部的了。但是我们团队采用的是NAT上网，也就是外面的“黑客”不可能进入到服务器攻击的。

那么，只可能是内部有“肉鸡了”。

想到这里，突然间对所有的杀毒软件、安全助手失望了，，，，，，“枉我那么信任你们，你们居然没有发现------木马、僵尸、病毒。。。。”

因此，我们开始对服务器进行了简单改造，安装了“网络数据包抓包工具”。。。怀着侥幸的心理，希望可以抓到点什么。。。

抓包程序安装完毕了，时间1分钟1分钟的过去了。。。。团队成员还是一如既往的开发着程序。。。。。。

1个小时过去了，大约快到10:30 左右， 我的预感告诉我，【它】可能要来了。。。。突然间，“数据表消失了”。。。。。。。

团队成员异常振奋，【它】来了。。

我以最快的速度把“Capture的数据文件”复制到U盘里，迅速拔离服务器。在1分钟之内完成了，Capture的数据文件复制到我早已经准备好的“笔记本”电脑上了。

就像实验室里发现了新元素，马上开始化学分析一样。。。。

上图是2012年5月2日的那天，劳动节刚刚收假。。

通过“问题的迹象”，我们初步判断，可能和MSSQL数据库的漏洞有关。。。顺着这个思路，我们开始对“样本”进行了分析。果然在13000多行的访问记录里找到“蛛丝马迹”。

通过【发现问题的时间】对应了数据包的日志，我们初步判断，在一时间段与服务打交道的是“TDS协议”，因此进行了tds过滤，把范围缩小。

用tds进行过滤。。。（通过查询相关文档得知的，MSSQL的数据传输协议是tds协议，微软自家的标准）

通过抓包工具，我们深切的发现了MS SQL2005 数据库是相当的不安全，所有的SQL语句在网络上居然是“明文传输”

当然，既然在网络数据包里发现了“sql语句执行的痕迹”，那么会不会有其他发现呢？追随这个思路，我们对数据包记录1行1行的进行查阅。

终于被我们发现了以下内容：

在这1时间段， 192.168.0.20的电脑在发广播，询问 201在哪里。 而201正是我们的“MSSQL服务器”

当然，询问201在哪里，并能作为是“犯罪的证据”。。。

在接下来的数据包分析中， 取得了重大突破。

我们在192.168.0.20 这个电脑上发现了这3个文件，打开后。内容令我们震惊。。。。它居然就是“干掉数据库的”“傻瓜脚本”。

其次，在对数据包的分析中，我们也发现了这个脚本执行的痕迹。。。

上面的系列截图没有贴出，具有破坏力的那3个数据包的截图， 感兴趣的朋友可以自己做实验抓图试试！

结果了1早上的折腾，基本查到了“对方”是怎么攻击我的服务器了。 也知道他耍了什么手段。

不过遗憾的是，没有办法追溯到源头。。。。因为网络里还缺少了“网络日志”服务器。

通过这一次事件，我们吸取到了很多经验、教训！

不过，最最重要的还是“经常做数据备份”！并且“数据备份最好备份到【其它地方】，不要备份在同一个地方”。