- 相關推薦
病毒引起路由器過載故障解決方法
一天，接到一個同事的求助電話，說他的機器不能上網了。這個同事的主機所在的虛網和網絡中心不在同一個虛網中。同事介紹說5分鐘前還是好的(能夠上網)，現在不知道為什么就不能上網了。而且他的機器(安裝的系統為Windows XP)最近沒有安裝什么新的程序，沒有移動過電腦，也沒有拔過網線。
首先，排查網絡客戶端的錯誤配置。進入MSDOS方式使用IPCONFIG命令檢查主機的IP地址配置：
|
C:>ipconfig Windows IP Configuration Ethernet adapter 本地連接: Connection-specific DNS Suffix . : IP Address. . . . . . . . . . . . : 210.16.2.30 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . 210.16.2.1 |
C:> ping 210.16.2.30 Reply from 210.16.2.30: bytes=32 time<1ms TTL=128 Reply from 210.16.2.30: bytes=32 time<1ms TTL=128 |
再使用Ping命令，測試從本機到網關的連接情況：
C:> ping 210.16.2.1 –t Reply from 210.16.2.1: bytes=32 time<1ms TTL=128 Reply from 210.16.2.1: bytes=32 time<1ms TTL=128 |
這回問題集中到路由器上了。急忙回到網絡中心，從路由器的外部指示燈上看，沒什么異常現象。在網管機上Ping路由器的地址(網管機是直接連在路由器的百兆模塊上的)，也是時通時斷。又繼續(xù)觀察了一段時間，發(fā)現每過4～10分鐘，路由器所有模塊的指示燈都會同時熄滅，接著控制模塊上的“HBT”燈閃爍，然后“OK”燈亮起，最后所有模塊的指示燈均顯示Online。“HBT”燈閃爍表示路由器正在啟動，也就是說正在自動重啟，而且40秒左右的網絡斷開時間正好是路由器的重啟所需的時間�，F在問題的查找工作已經結束，肯定是路由器出了故障。具體是什么問題，還需要進一步的檢測。
在路由器正常工作的時候，把筆記本電腦的COM口使用路由器的專用CONSOLE線連接起來，建立超級終端。在管理模式下使用命令“system show bootlog”查看系統的啟動記錄，發(fā)現各個模塊的加載均屬正常。造成路由器重啟的原因，最大的可能就是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%。)
果然，連續(xù)使用此命令后得知CPU利用率正在逐漸上升，當達到95%的時候路由器便自動重啟。看來路由器的負載太大了，因為平時正常情況下，CPU的使用率僅為1%～6%左右。當網絡使用高峰期的時候CPU的利用率會稍微高一點。但到底是什么讓路由器過載呢?幸好以前曾經給路由器設置過日志記錄，并把日志發(fā)送到一個日志服務器上。但是打開這臺服務器所記錄的日志并未能找到有用的線索。因為當路由器負載過大時，它已經不能往日志服務器上發(fā)送日志了，只能用“system show syslog buffer”命令來查看當前系統緩存中的日志記錄：
|
SSR# system show syslog buffer 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 210.55.37.72 2003-09-10 09:28:32 %ACL_LOG-I-PERMIT, ACL [out] on "uplink" ICMP 210.16.3.82 -> 61.136.65.13 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 202.227.100.65 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 193.210.224.202 2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out] on "uplink" ICMP 210.16.3.82 -> 218.32.21.101 |
很明顯，“210.16.3.82”這臺在使用ICMP協議向其他主機發(fā)起攻擊。據此判斷，這臺主機要么是中毒，要么是被黑客利用了。鑒于當時的情況分析，可能是網絡中存在中了“沖擊波殺手”病毒的主機。該病毒使用類型為echo的ICMP報文來Ping根據自身算法得出的IP地址段，以此檢測這些地址段中存活的主機，并發(fā)送大量載荷為“aa”，填充長度92字節(jié)的icmp報文，從而導致網絡堵塞。而且病毒一旦發(fā)現存活的主機，便試圖使用135端口的rpc漏洞和80端口的webdav漏洞進行溢出攻擊。溢出成功后會監(jiān)聽69(TFTP專業(yè)端口，用于文件下載)端口和666～765(通常是707端口)范圍中的一個隨機端口等待目標主機回連。
根據該病毒的傳播機理，立刻在路由器上設置訪問控制列表(ACL)，以阻塞UDP協議的69端口(用于文件下載)、TCP的端口135(微軟的DCOM RPC端口)和ICMP協議(用于發(fā)現活動主機)。具體的ACL配置如下：
! --- block ICMP
acl deny-virus deny icmp any any
! --- block TFTP
acl deny-virus deny udp any any any 69
! --- block W32.Blaster 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的使用率，恢復到了正常狀態(tài)，等待一段時間后，沒有出現重啟現象。
由于路由器不能自動丟棄這種病毒發(fā)出的攻擊數據包，而導致了路由器重啟。記得兩年前在“紅色代碼”病毒盛行的時候，也出現過路由器因過載而不斷重啟的現象，升級IOS以后就恢復正常了。為了徹底解決問題，還應升級路由器的IOS(可以使用“system show version”來查看當前使用的IOS的版本)。與設備供應商取得聯系并獲得最新的IOS映像文件。至此，路由器故障全部解決。
從此例故障處理中，我們可以得到這樣的教訓：時刻關注網絡上事態(tài)的發(fā)展，并做出相應的解決方案，而且付諸實施。教育網用戶可以在http://www.ccert.edu.cn網站上訂閱安全公告服務，一旦有新的漏洞出現，CCERT安全響應小組會自動發(fā)送郵件給用戶。該例中由于當時暑假期間得知“沖擊波”后，及時在路由器上做了設置，所以“沖擊波”病毒沒有在網內泛濫，但沒有及時設置相應的ACL，隨后的“沖擊波殺手”導致了這次網絡癱瘓。實際上，在這次“沖擊波”和“沖擊波殺手”的襲擊中，很多城域網也因此陷入癱瘓。這些經歷警告我們：時刻關注網絡安全，及時積極地應對。
【病毒引起路由器過載故障解決方法】相關文章：
軟件系統引起的路由器故障08-28
路由器故障及解決方法06-07
因沖突引起的網絡故障解決方法10-08
路由器物理故障07-25
CPU故障及解決方法10-07
內存引起的故障有哪些08-29
電源引起的內存報警故障05-19
電源故障引起的電腦問題07-14
內存引起故障的原因分析11-06
網卡引起的網絡故障01-05