病毒引起路由器過載故障解決方法

一天，接到一個同事的求助電話，說他的機器不能上網了。這個同事的主機所在的虛網和網路中心不在同一個虛網中。同事介紹說5分鐘前還是好的(能夠上網)，現在不知道為什麼就不能上網了。而且他的機器(安裝的系統為Windows XP)最近沒有安裝什麼新的程式，沒有移動過電腦，也沒有拔過網線。

首先，排查網路客戶端的錯誤配置。進入MSDOS方式使用IPCONFIG命令檢查主機的IP地址配置：

 C:> ping Reply from : bytes=32 time<1ms TTL=128Reply from : bytes=32 time<1ms TTL=128

再使用Ping命令，測試從本機到閘道器的連線情況：

C:> ping  –tReply from : bytes=32 time<1ms TTL=128Reply from : bytes=32 time<1ms TTL=128

這回問題集中到路由器上了。急忙回到網路中心，從路由器的外部指示燈上看，沒什麼異常現象。在網管機上Ping路由器的地址(網管機是直接連在路由器的百兆模組上的)，也是時通時斷。又繼續觀察了一段時間，發現每過4～10分鐘，路由器所有模組的指示燈都會同時熄滅，接著控制模組上的“HBT”燈閃爍，然後“OK”燈亮起，最後所有模組的指示燈均顯示Online。“HBT”燈閃爍表示路由器正在啟動，也就是說正在自動重啟，而且40秒左右的網路斷開時間正好是路由器的重啟所需的時間。現在問題的查詢工作已經結束，肯定是路由器出了故障。具體是什麼問題，還需要進一步的檢測。

在路由器正常工作的時候，把膝上型電腦的COM口使用路由器的專用CONSOLE線連線起來，建立超級終端。在管理模式下使用命令“system show bootlog”檢視系統的啟動記錄，發現各個模組的載入均屬正常。造成路由器重啟的原因，最大的可能就是CPU的利用率達到100%。使用“system show cpu-utilization”命令檢視CPU的使用率：

SSR# system show cpu-utilization

CPU Utilization (5 seconds): 50%(60 seconds): 60%(前者是指5秒鐘內CPU平均使用率為50%，後者是60秒鐘內CPU平均使用率為60%。)

果然，連續使用此命令後得知CPU利用率正在逐漸上升，當達到95%的時候路由器便自動重啟。看來路由器的負載太大了，因為平時正常情況下，CPU的使用率僅為1%～6%左右。當網路使用高峰期的時候CPU的利用率會稍微高一點。但到底是什麼讓路由器過載呢?幸好以前曾經給路由器設定過日誌記錄，並把日誌傳送到一個日誌伺服器上。但是開啟這臺伺服器所記錄的日誌並未能找到有用的線索。因為當路由器負載過大時，它已經不能往日誌伺服器上傳送日誌了，只能用“system show syslog buffer”命令來檢視當前系統快取中的日誌記錄：

很明顯，“”這臺在使用ICMP協議向其他主機發起攻擊。據此判斷，這臺主機要麼是中毒，要麼是被黑客利用了。鑑於當時的情況分析，可能是網路中存在中了“衝擊波殺手”病毒的主機。該病毒使用型別為echo的ICMP報文來Ping根據自身演算法得出的IP地址段，以此檢測這些地址段中存活的主機，併發送大量載荷為“aa”，填充長度92位元組的報文，從而導致網路堵塞。而且病毒一旦發現存活的主機，便試圖使用135埠的rpc漏洞和80埠的webdav漏洞進行溢位攻擊。溢位成功後會監聽69(TFTP專業埠，用於檔案下載)埠和666～765(通常是707埠)範圍中的一個隨機埠等待目標主機回連。

根據該病毒的傳播機理，立刻在路由器上設定訪問控制列表(ACL)，以阻塞UDP協議的69埠(用於檔案下載)、TCP的埠135(微軟的DCOM RPC埠)和ICMP協議(用於發現活動主機)。具體的ACL配置如下：

! --- block ICMP

acl deny-virus deny icmp any any

! --- block TFTP

acl deny-virus deny udp any any any 69

! --- block ter related protocols

acl deny-virus deny tcp any any any 135

acl deny-virus permit tcp any any any any

acl deny-virus permit udp any any any any

最後再把deny-virus這個ACL應用到上連線口(uplink)上：

acl deny-virus apply interface uplink input output

這樣就可以把“衝擊波殺手”從網路的出口處堵截住。為了防止已經感染“衝擊波殺手”的主機在校內各個虛網之間傳播，還要把這個ACL應用到校內各虛網的介面上。這時使用並檢視CPU的使用率，恢復到了正常狀態，等待一段時間後，沒有出現重啟現象。

由於路由器不能自動丟棄這種病毒發出的攻擊資料包，而導致了路由器重啟。記得兩年前在“紅色程式碼”病毒盛行的時候，也出現過路由器因過載而不斷重啟的現象，升級IOS以後就恢復正常了。為了徹底解決問題，還應升級路由器的IOS(可以使用“system show version”來檢視當前使用的IOS的版本)。與裝置供應商取得聯絡並獲得最新的IOS映像檔案。至此，路由器故障全部解決。

從此例故障處理中，我們可以得到這樣的教訓：時刻關注網路上事態的發展，並做出相應的解決方案，而且付諸實施。教育網使用者可以在網站上訂閱安全公告服務，一旦有新的漏洞出現，CCERT安全響應小組會自動傳送郵件給使用者。該例中由於當時暑假期間得知“衝擊波”後，及時在路由器上做了設定，所以“衝擊波”病毒沒有在網內氾濫，但沒有及時設定相應的ACL，隨後的“衝擊波殺手”導致了這次網路癱瘓。實際上，在這次“衝擊波”和“衝擊波殺手”的襲擊中，很多都會網路也因此陷入癱瘓。這些經歷警告我們：時刻關注網路安全，及時積極地應對。