打开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计算机就可以完成一个最真实的漏洞环境模拟。