25号晚上朋友突然在QQ上告诉我：“SQL（SQL Server培训 mySQL培训 ）你出名了”，我搞不清楚发生了什么事情后来才明白她指的是这次突然的SQL蠕虫造成全球网络大规模瘫痪的事件。有关这个蠕虫的新闻后来充斥在所有的网站头条栏目上，我想自己正好也赋闲在家何不也抓一只这个小虫子回来研究看看到底有什么能耐。说做就做其实很简单，我家里是宽带上网自己有一个独立的公网的IP地址，找了一台计算机重新安装了遍系统把SQL SERVER默认安装好确认UDP 1434端口已经打开了，正常来讲到这里一个小蜜罐已经弄好了，不过为了不在病毒发作的时候给小区的交换路由设备造成压力给别人带来不必要的麻烦所以还需要再设置一个地方：
其实很简单就是WIN2000的路由和远程访问限制中的输出筛选器中把本地发送到远程的UDP 1434端口的数据包做一个禁止，防止在自己被感染以后向外发送数据包危害别人。当然如果再考虑周全点的话还应该多做些限制比如仅仅允许UDP 1434端口开放，所有对外访问的数据包应该是全部禁止。这样的话就可以降低在等待蠕虫的过程中被其他真实攻击者利用漏洞做破坏进入系统的可能性了。
打开IRIS监视本地网络数据包的访问行为，为了看起来比较清楚我加了一条过滤规则仅仅捕获UDP 1434端口的数据包。大约7个小时以后第一条小虫子才姗姗爬来，我后来也是从这个时间差上感觉这个蠕虫带来的危害其实很难和去年的红色代码和NIMUDA病毒相比，想当年这两个病毒爆发的时候截获到的速度频率要远远大于它了。
我的SQL SERVER随即被感染，第一反应就是系统速度明显变慢打开任务管理器发现SQL SERVER占用系统资源达到90%以上，有30个线程在运行（这是正常的不用担心），当年的NIMUDA和红色代码线程都在300个左右。
CPU的实际占用效率已经为100%
短暂的去掉对外发包的限制，瞬间的数据量让人吃惊不能不佩服这个蠕虫作者的水平短短的376个字节的程序可以产生这么大的破坏威力。
这是当时用IRIS的监视工具侦测到的网络真实流量，由于这个UDP的数据包本身很小所以简单换算下，真实每秒的发包个数有几千个，这么大的负载我想任何路由和交换设备第一反映就是变慢，如果网络中不幸有几台主机同时感染的话肯定就会失去响应了。
好在这个小蠕虫并不对系统本地的文件进行任何破坏，在感染以后我无法直接停止SQL SERVER的后台服务只有立即重新系统服务器，由于这个蠕虫属于内存性的病毒系统重新启动以后就消失了，上面是正常的SQL SERVER运行的状态显示。5分钟以后我就被第二次重新感染，这次启动以后我第一件事情就是停止SQL SERVER的服务然后安装最新的SP3的补丁包。简单的实验也就到次结束了。
自己做一个小蜜罐去研究真实攻击行为现在很流行，你没必要去购买专门的商业蜜罐设置程序自己用一台PC计算机就可以完成一个最真实的漏洞环境模拟。
(责任编辑：郁单曰) |
