25號晚上朋友突然在QQ上告訴我：“SQL你出名了”，我搞不清楚發生了什么事情后來才明白她指的是這次突然的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計算機就可以完成一個最真實的漏洞環境模擬。

(責任編輯：郁單曰)