局域網癱瘓 源自傀儡主機DDoS攻擊
接到客戶求助，最近進行了一次網絡“出診”。這是一個由傀儡主機的DDos攻擊引發的網絡故障，案例比較典型，排錯過程也頗曲折。筆者就還原其過程，與大家分享。
1.網絡環境
這個客戶是一家化工企業，網絡規模不大。十多臺交換機組成的局域網，節點大約150個左右。沒有劃分VLAN，—部分主機運行IPX協議，另一部分運行TCP/IP協議。其中只有少數主機可以訪問Internet，接入模式為ADSL路由器直接連接網絡中的一臺交換機。ADSL路由器中啟用了其自帶防火墻功能，所有可以上網的主機安裝了防病毒軟件。
2.故障描述
最近的某一天，整個網絡突然癱瘓。可以看到所有交換機端口指示燈急速閃爍，測試得知網絡中任意兩臺主機之間不能相互ping通，所有網絡應用均不能正常進行。在拔掉部分網線(交換機之間的級連線)后，癥狀有所減緩，最后恢復正常。將拔掉的網線逐一插回原位，故障現象未重新出現。此后這種現象不定時、無規律地出現。
3.故障分析
基于故障發生時交換機端口指示燈急速閃爍、網絡中任意兩臺主機之間相互不能ping通這一現象，初步斷定此時網絡中充斥了大量的廣播包，耗盡了網絡資源。那么這些突然出現的巨量廣播包是哪里來的呢?為查找廣播源，在故障出現時，使用Sninffer軟件捕捉數據包。結果發現，網絡中并沒有出現原來估計的廣播包，卻有大量的不正常單目IP數據包。
4.排除故障
通過分析發現，這些數據包是主機172.*.*.1l發送給主機219.*.*.88的，發送速度不小于每秒l萬5千個。詢問管理員得知，172.*.*.1l是內網的一臺可以訪問Internet的主機。這明顯是不正常的，將該可疑主機斷開后，問題解決。
5.深入分析
網絡故障雖然排錯，但筆者感覺一切并沒有這么簡單。因為按常理，發送給主機219.*.*.88的數據包不是廣播包，不應該被發送到運行Sniffer主機所在的交換機端口。很明顯，這些數據包在網絡中以廣播的形式被發送了。如此數量的廣播包充斥網絡，正是造成網絡癱瘓的罪魁禍首。
(1).局域網主機成了傀儡
為搞清故障原因，在可疑主機上安裝Sniffer，分析網絡行為。通過抓包分析發現，一旦連接Internet，該主機主動連接到外網中一FTP服務器，并下載文本文件ddos.txt。那么，ddos.txt文件內容中有什么呢?原來是一個IP地址和8O端口。然后，對數據包進一步分析發現所有數據包的目標主機正好是ddos.txt中指定的IP地址。這些無意義的數據包之所以使用8O端口，是為了突破防火墻的限制。原來，這臺主機“有幸”成了一次分布式拒絕服務攻擊(DDoS)的傀儡機。每次連接E互連網，自動到一個FTP服務器下載文件ddos.txt，如果該文件為空，則繼續以一定時間間隔下載文件，直到獲得的文件中有目標主機的IP地址和端口后，即開始向目標主機展開DoS攻擊。這正是網絡故障現象不定時、無規律地出現的原因。
(2).ADSL路由器被“淹沒”
另一個問題是，這些攻擊包應該是從傀儡機發送到ADSL路由器，然后到Internet中目標主機的，并不是通常所說的廣播包，為什么交換機以廣播的形式發送這些廣播包呢?分析可能原因只有一個：此時交換機的地址轉發表(CAM)中沒有ADSL路由器內網接口的物理地址，引起交換機將單目包廣播到所有交換機端口。
開始時，交換機地址轉發表中包含ADSL路由器的物理地址。那么，傀儡機開始攻擊后，網絡中形成一個穩定的攻擊數據流：傀儡機→若干交換機→ADSL路由器→被攻擊的目標主機。此時對內網的影響僅僅是某些交換機的端口和ADSL路由器，ADSL路由器因為忙于處理大量的攻擊包而被“淹沒”，會導致內網中主機訪問互連網出現問題。
(3).交互導致的廣播風暴
什么原因導致交換機的地址轉發表丟棄了ADSL路由器內網接口的物理地址昵?有兩種情況：一是缺省情況下，5分鐘內，如果交換機沒有接到某個設備發送的數據幀，則認為該設備已經宕機，為節省資源，將從CAM表中刪除該地址。二是當STP協議探測到網絡拓撲有改變時，將清空所有未刷新的CAM表項。假定此時有人因為不能上網而重新啟動主機，或插撥網線，則會引起交換機端口狀態發生變化。此時，交換機認為網絡拓撲發生了變化，它的下—個動作是通知所有交換機，15秒內清除未被刷新的地址轉發表表項。
這里的“未被刷新”是指，交換機沒有收到以該物理地址為源地址的數據幀，也就是說，該設備沒有發送數據幀經過交換機到其他設備，那么該設備的物理地址在交換機的地址轉發表中將被清除。以后，所有以該設備物理地址為目的地址的數據幀，雖然不是廣播幀，也將被發送到交換機的所有端口，這就是平時所說的廣播風暴。
(4).故障形成過程
通過上面的分析，最后回到我們的例子理一理這次故障形成的過程。在傀儡機的攻擊行為開始后，小小的ADSL路由器每秒要接收、處理不少于l5o00個數據包，它縱然是有三頭六臂，也沒機會向交換機發送數據包了。也就是說，它現在是只有接受沒有發送，沒辦法刷新交換機cAM表中的相關表項。那么，快的話15秒后，慢的話5分鐘，交換機就會清除ADSL路由器的物理地址記錄。別忘了，此時攻擊數據流并沒有停止，而這些攻擊數據幀恰恰是以ADSL路由器物理地址為目的地址的，這樣，災難發生了，所有數據幀被廣播到網絡中每臺交換機中的每—個端口。
6.解決方案
這此網絡故障從表面上看是由一臺傀儡主機引起的，具有一定的偶然性。但從根本上來說是必然，不合理的網絡結構是造成這次故障的關鍵因素。筆者給出的解決方案是：
(1).將充當傀儡機的電腦從網絡中斷開后，重新安裝系統，徹底杜絕隱患。
(2).加強本地網絡安全防范措施的同時，對原網絡結構進行調整：據不同應用分成幾個VLAN，將可以上網的機劃分到某個特定VLAN中，限定此類故障的影響范圍。
(3).將連接主機的端口配置為STP速端口，不參與STP協議，可以減少網絡中交換機不
必要的拓撲改變操作。
就這次網絡排錯筆者的啟示是：網絡排錯類同于醫生治病，庸醫往往是“頭痛醫頭，腳痛醫教”不會從根上進行醫治，而高明的醫生卻往往是治本。網絡排錯何嘗不是呢?
【編輯推薦】
