病毒路由器故障 路由器過載解決方案，病毒路由器故障是一個很普通的問題，但我們如何對病毒路由器故障進行更精確的解決，給我們的使用到來方便呢？

此次故障發生地的拓撲結構是這樣的：使用一臺EnterasysSSR8000作為邊界路由器，同時也用它把校園內部劃分為8個虛網，每個虛網各有一個堆疊的二層交換機作為臺式機和筆記本的接入設備，主干為千兆，百兆到桌面。

那天，我接到一個同事的求助電話，說他的機器不能上網了。這個同事的主機所在的虛網和網絡中心不在同一個虛網中。聽同事介紹說5分鐘前還好的（能夠上網），現在不知道為什么就不好上網了。而且他的機器（安裝的系統為WindowsXP）最近沒有安裝什么新的程序，沒有移動過電腦，也沒有拔過網線。

首先，排查網絡客戶端的錯誤配置。進入MSDOS方式使用IPCONFIG命令檢查主機的IP地址配置：上面顯示的配置是正確的，然后ping自己的IP地址這說明IP地址是生效的，網卡工作正常。再使用PING命令，測試從本機到網關的連接情況：

從主機向網關發送的數據包，全部都得到了回應，線路是連通的。打開瀏覽器，也能夠正常上網，一點兒都沒問題。現在的網絡是正常的！？正在懷疑的時候，發現網絡又不通了！發現ping出的數據包未能到達網關。

奇怪，剛才還好的，怎么現在又不通了呢？難道是網卡或者系統有問題？誰知過了一會兒，發現又通了。幸虧那天帶了筆記本，于是我把臺式機上的網線插到我的電腦上，配置好IP地址后ping網關，也出現時斷時續的情況。

斷開的現象大概持續了50秒鐘，然后又恢復正常。這回可以基本排除主機的問題了，因為兩臺不相干主機同時出現同樣此類問題的幾率幾乎為零。鑒于此現象，我首先排除了連接線纜的病毒路由器故障，因為連接的線纜不可能出現這種時斷時續的情況，病毒路由器故障最有可能會出在線纜的另一端——二層交換機上。

于是來到這棟樓的設備間，查看交換機的狀態，這是一個由兩臺交換機的堆疊，其中一臺交換機上有一個上聯的千兆端口。我把筆記本接到交換機的其中一個端口上，再ping網關。還是同樣的病毒路由器故障，而且還發現每過4分鐘到10分鐘，網絡就會斷一次，并且40到50秒后又恢復正常。

經過觀察發現：沒有發現端口指示燈的異常情況，說明交換機的各個端口均正常。難道真是交換機的內部系統出現故障了？算了，索性把交換機重啟一下。誰知重啟后，病毒路由器故障依舊。可能交換機真的出了問題，我正想是否要把堆疊模塊換到另外一個交換機上的時候，我的手機響了，又一個同事告訴我他的機器也出現相同的故障現象。

而這個同事的主機在另外一個虛網中，同時出現相同的時通時斷情況，那極有可能是連接這兩個虛網的路由器出了問題。這回問題集中到路由器上了。我急忙回到網絡中心，從路由器的外部指示燈上看，沒什么異常現象。在我的網管機上ping路由器的地址（我的網管機是直接連在路由器的百兆模塊上的），也是時通時斷。

我又繼續觀察了一段時間，發現每過4分鐘到10分鐘，路由器所有模塊的指示燈都會同時熄滅，接著控制模塊上的“HBT”燈閃爍，然后“OK”燈亮起，最后所有模塊的指示燈均顯示Online。

我解釋一下，“HBT”燈閃爍表示路由器正在啟動，也就是說正在自動重啟，而且40秒左右的網絡斷開時間正好是路由器的重啟所需的時間。現在問題的查找工作已經結束，肯定是路由器出了病毒路由器故障。具體是什么問題，還需要進一步的檢測。

趁著路由器正常工作的時候，把筆記本的COM口使用路由器的專用CONSOLE線連接起來，建立超級終端。在管理模式下使用命令“system show bootlog”查看系統的啟動記錄，發現各個模塊的加載均屬正常。造成路由器重啟的原因，最大的可能就是CPU的利用率達到100％。使用“system show cpu-utilization”命令查看CPU的使用率：

果然，連續使用此命令后得知CPU利用率正在逐漸上升，當達到95％的時候路由器便自動重啟。看來路由器的負載太大了，因為平時正常情況下，CPU的使用率僅為1％—6％左右。當網絡使用高峰期的時候CPU的利用率會稍微高一點。

但到底是什么讓路由器過載呢？幸好以前曾經給路由器設置過日志記錄，并把日志發送到一個日志服務器上。但是打開這臺服務器所記錄的日志并未能找到有用的線索。因為當路由器負載過大時，它已經不能往日志服務器上發送日志了，我只能用“system show syslog buffer”命令來查看當前系統緩存中的日志記錄：

很明顯，“210.16.3.82”這臺在使用ICMP協議向其他主機發起攻擊，據此判斷，這臺主機要么是中毒，要么是被黑客利用了。鑒于當時的情況分析，可能是網絡中存在中了“沖擊波殺手”病毒的主機。

該病毒使用類型為echo的ICMP報文來ping根據自身算法得出的ip地址段，以此檢測這些地址段中存活的主機，并發送大量載荷為“aa”，填充長度92字節的icmp報文，從而導致網絡堵塞。而且病毒一旦發現存活的主機，便試圖使用135端口的rpc漏洞和80端口的webdav漏洞進行溢出攻擊。

溢出成功后會監聽69（TFTP專業端口，用于文件下載）端口和666-765（通常是707端口）范圍中的一個隨機端口等待目標主機回連。根據該病毒的傳播機理，立刻在路由器上設置訪問控制列表（ACL），以阻塞UDP協議的69端口（用于文件下載）、TCP的端口135（微軟的DCOM RPC端口）和ICMP協議（用于發現活動主機）。具體的ACL配置如下：

最后再把deny-virus這個ACL應用到上聯接口（uplink）上：這樣就可以把“沖擊波殺手”從網絡的出口處堵截住。為了防止已經感染“沖擊波殺手”的主機在校內各個虛網之間傳播，還得把這個ACL應用到校內各虛網的接口上。這時使用再“system show cpu-utilization”查看CPU的使用率，它又恢復到正常狀態，等待了一段時間后，再沒有出現重啟現象。

由于路由器不能自動丟棄這種病毒發出的攻擊數據包，而導致了路由器重啟。為了徹底解決問題，還得升級路由器的IOS（可以使用“system show version”來查看當前使用的IOS的版本）。記得兩年前在“紅色代碼”病毒盛行的時候，也出現過路由器因過載而不斷重啟的現象，升級IOS以后就恢復正常了。于是立刻和設備供應商取得聯系并獲得最新的IOS映像文件。至此，病毒路由器故障全部解決。

從這場故障處理中，我們可以得到這樣的教訓：時刻關注網絡上事態的發展，并作出相應的解決方案，而且付諸實施。教育網用戶可以在http://www.ccert.edu.cn網站上訂閱安全公告服務，一旦有新的漏洞出現，CCERT安全響應小組會自動發送郵件給你。

當時暑假期間得知“沖擊波”后，由于及時在路由器上做了設置，所以“沖擊波”病毒沒有在網內泛濫，但隨后的“沖擊波殺手”沒有及時設置相應的ACL，所以才導致這次的網絡癱瘓。實際上，在這次的“沖擊波”和“沖擊波殺手”的襲擊中，很多城域網也因此陷入癱瘓。這些經歷一次又一次的警告我們：時刻關注網絡安全，及時積極的應對。