亚洲国产日韩欧美在线a乱码,国产精品路线1路线2路线,亚洲视频一区,精品国产自,www狠狠,国产情侣激情在线视频免费看,亚洲成年网站在线观看

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

時(shí)間:2020-08-10 12:31:43 網(wǎng)絡(luò)診斷 我要投稿

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

  一天,接到一個(gè)同事的求助電話,說他的機(jī)器不能上網(wǎng)了。這個(gè)同事的主機(jī)所在的虛網(wǎng)和網(wǎng)絡(luò)中心不在同一個(gè)虛網(wǎng)中。同事介紹說5分鐘前還是好的(能夠上網(wǎng)),現(xiàn)在不知道為什么就不能上網(wǎng)了。而且他的機(jī)器(安裝的系統(tǒng)為Windows XP)最近沒有安裝什么新的程序,沒有移動(dòng)過電腦,也沒有拔過網(wǎng)線。

  首先,排查網(wǎng)絡(luò)客戶端的錯(cuò)誤配置。進(jìn)入MSDOS方式使用IPCONFIG命令檢查主機(jī)的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

上面顯示的配置是正確的,然后Ping自己的IP地址:
 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
這說明IP地址是生效的,網(wǎng)卡工作正常。

  再使用Ping命令,測試從本機(jī)到網(wǎng)關(guān)的連接情況:

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
從主機(jī)向網(wǎng)關(guān)發(fā)送的數(shù)據(jù)包,全部都得到了回應(yīng),線路是連通的。打開瀏覽器,也能夠正常上網(wǎng),一點(diǎn)兒都沒問題,F(xiàn)在的網(wǎng)絡(luò)是正常的。正在懷疑的時(shí)候,發(fā)現(xiàn)網(wǎng)絡(luò)又不通了。發(fā)現(xiàn)Ping出的數(shù)據(jù)包未能到達(dá)網(wǎng)關(guān)。難道是網(wǎng)卡或者系統(tǒng)有問題?誰知過了一會(huì)兒,發(fā)現(xiàn)又通了。把臺(tái)式機(jī)上的網(wǎng)線插到筆記本電腦上,配置好IP地址后Ping網(wǎng)關(guān),也出現(xiàn)時(shí)斷時(shí)續(xù)的情況。斷開的現(xiàn)象大概持續(xù)了50秒鐘,然后又恢復(fù)正常。這基本可以排除是主機(jī)存在問題了,因?yàn)閮膳_(tái)不相干主機(jī)同時(shí)出現(xiàn)此類問題的幾率幾乎為零。鑒于此現(xiàn)象,首先排除了連接線纜的故障,因?yàn)檫B接的線纜不可能出現(xiàn)這種時(shí)斷時(shí)續(xù)的情況,故障最有可能出在線纜的.另一端——二層交換機(jī)上。于是來到這棟樓的設(shè)備間,查看交換機(jī)的狀態(tài),這是一個(gè)由兩臺(tái)交換機(jī)進(jìn)行的堆疊,其中一臺(tái)交換機(jī)上有一個(gè)上連的千兆端口。把筆記本電腦接到交換機(jī)的其中一個(gè)端口上,再Ping網(wǎng)關(guān)。還是同樣的故障,而且還發(fā)現(xiàn)每過4~10分鐘,網(wǎng)絡(luò)就會(huì)斷一次,并且40~50秒后又恢復(fù)正常。經(jīng)過觀察發(fā)現(xiàn):沒有發(fā)現(xiàn)端口指示燈的異常情況,說明交換機(jī)的各個(gè)端口均正常。難道真是交換機(jī)的內(nèi)部系統(tǒng)出現(xiàn)故障了?索性把交換機(jī)重啟一下。重啟后,故障依舊?赡芙粨Q機(jī)真的出了問題,正想是否要把堆疊模塊換到另外一個(gè)交換機(jī)上的時(shí)候,手機(jī)響了,又一個(gè)同事告訴他的機(jī)器也出現(xiàn)相同的故障現(xiàn)象。而這個(gè)同事的主機(jī)在另外一個(gè)虛網(wǎng)中,同時(shí)出現(xiàn)相同的時(shí)通時(shí)斷情況。看來極有可能是連接這兩個(gè)虛網(wǎng)的路由器出了問題。

  這回問題集中到路由器上了。急忙回到網(wǎng)絡(luò)中心,從路由器的外部指示燈上看,沒什么異,F(xiàn)象。在網(wǎng)管機(jī)上Ping路由器的地址(網(wǎng)管機(jī)是直接連在路由器的百兆模塊上的),也是時(shí)通時(shí)斷。又繼續(xù)觀察了一段時(shí)間,發(fā)現(xiàn)每過4~10分鐘,路由器所有模塊的指示燈都會(huì)同時(shí)熄滅,接著控制模塊上的“HBT”燈閃爍,然后“OK”燈亮起,最后所有模塊的指示燈均顯示Online。“HBT”燈閃爍表示路由器正在啟動(dòng),也就是說正在自動(dòng)重啟,而且40秒左右的網(wǎng)絡(luò)斷開時(shí)間正好是路由器的重啟所需的時(shí)間,F(xiàn)在問題的查找工作已經(jīng)結(jié)束,肯定是路由器出了故障。具體是什么問題,還需要進(jìn)一步的檢測。

  在路由器正常工作的時(shí)候,把筆記本電腦的COM口使用路由器的專用CONSOLE線連接起來,建立超級(jí)終端。在管理模式下使用命令“system show bootlog”查看系統(tǒng)的啟動(dòng)記錄,發(fā)現(xiàn)各個(gè)模塊的加載均屬正常。造成路由器重啟的原因,最大的可能就是CPU的利用率達(dá)到100%。使用“system show cpu-utilization”命令查看CPU的使用率:

  SSR# system show cpu-utilization

  CPU Utilization (5 seconds): 50%(60 seconds): 60%(前者是指5秒鐘內(nèi)CPU平均使用率為50%,后者是60秒鐘內(nèi)CPU平均使用率為60%。)

  果然,連續(xù)使用此命令后得知CPU利用率正在逐漸上升,當(dāng)達(dá)到95%的時(shí)候路由器便自動(dòng)重啟?磥砺酚善鞯呢(fù)載太大了,因?yàn)槠綍r(shí)正常情況下,CPU的使用率僅為1%~6%左右。當(dāng)網(wǎng)絡(luò)使用高峰期的時(shí)候CPU的利用率會(huì)稍微高一點(diǎn)。但到底是什么讓路由器過載呢?幸好以前曾經(jīng)給路由器設(shè)置過日志記錄,并把日志發(fā)送到一個(gè)日志服務(wù)器上。但是打開這臺(tái)服務(wù)器所記錄的日志并未能找到有用的線索。因?yàn)楫?dāng)路由器負(fù)載過大時(shí),它已經(jīng)不能往日志服務(wù)器上發(fā)送日志了,只能用“system show syslog buffer”命令來查看當(dāng)前系統(tǒng)緩存中的日志記錄:


				

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”這臺(tái)在使用ICMP協(xié)議向其他主機(jī)發(fā)起攻擊。據(jù)此判斷,這臺(tái)主機(jī)要么是中毒,要么是被黑客利用了。鑒于當(dāng)時(shí)的情況分析,可能是網(wǎng)絡(luò)中存在中了“沖擊波殺手”病毒的主機(jī)。該病毒使用類型為echo的ICMP報(bào)文來Ping根據(jù)自身算法得出的IP地址段,以此檢測這些地址段中存活的主機(jī),并發(fā)送大量載荷為“aa”,填充長度92字節(jié)的icmp報(bào)文,從而導(dǎo)致網(wǎng)絡(luò)堵塞。而且病毒一旦發(fā)現(xiàn)存活的主機(jī),便試圖使用135端口的rpc漏洞和80端口的webdav漏洞進(jìn)行溢出攻擊。溢出成功后會(huì)監(jiān)聽69(TFTP專業(yè)端口,用于文件下載)端口和666~765(通常是707端口)范圍中的一個(gè)隨機(jī)端口等待目標(biāo)主機(jī)回連。

  根據(jù)該病毒的傳播機(jī)理,立刻在路由器上設(shè)置訪問控制列表(ACL),以阻塞UDP協(xié)議的69端口(用于文件下載)、TCP的端口135(微軟的DCOM RPC端口)和ICMP協(xié)議(用于發(fā)現(xiàn)活動(dòng)主機(jī))。具體的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這個(gè)ACL應(yīng)用到上連接口(uplink)上:

  acl deny-virus apply interface uplink input output

  這樣就可以把“沖擊波殺手”從網(wǎng)絡(luò)的出口處堵截住。為了防止已經(jīng)感染“沖擊波殺手”的主機(jī)在校內(nèi)各個(gè)虛網(wǎng)之間傳播,還要把這個(gè)ACL應(yīng)用到校內(nèi)各虛網(wǎng)的接口上。這時(shí)使用并查看CPU的使用率,恢復(fù)到了正常狀態(tài),等待一段時(shí)間后,沒有出現(xiàn)重啟現(xiàn)象。

  由于路由器不能自動(dòng)丟棄這種病毒發(fā)出的攻擊數(shù)據(jù)包,而導(dǎo)致了路由器重啟。記得兩年前在“紅色代碼”病毒盛行的時(shí)候,也出現(xiàn)過路由器因過載而不斷重啟的現(xiàn)象,升級(jí)IOS以后就恢復(fù)正常了。為了徹底解決問題,還應(yīng)升級(jí)路由器的IOS(可以使用“system show version”來查看當(dāng)前使用的IOS的版本)。與設(shè)備供應(yīng)商取得聯(lián)系并獲得最新的IOS映像文件。至此,路由器故障全部解決。

  從此例故障處理中,我們可以得到這樣的教訓(xùn):時(shí)刻關(guān)注網(wǎng)絡(luò)上事態(tài)的發(fā)展,并做出相應(yīng)的解決方案,而且付諸實(shí)施。教育網(wǎng)用戶可以在http://www.ccert.edu.cn網(wǎng)站上訂閱安全公告服務(wù),一旦有新的漏洞出現(xiàn),CCERT安全響應(yīng)小組會(huì)自動(dòng)發(fā)送郵件給用戶。該例中由于當(dāng)時(shí)暑假期間得知“沖擊波”后,及時(shí)在路由器上做了設(shè)置,所以“沖擊波”病毒沒有在網(wǎng)內(nèi)泛濫,但沒有及時(shí)設(shè)置相應(yīng)的ACL,隨后的“沖擊波殺手”導(dǎo)致了這次網(wǎng)絡(luò)癱瘓。實(shí)際上,在這次“沖擊波”和“沖擊波殺手”的襲擊中,很多城域網(wǎng)也因此陷入癱瘓。這些經(jīng)歷警告我們:時(shí)刻關(guān)注網(wǎng)絡(luò)安全,及時(shí)積極地應(yīng)對。

【病毒引起路由器過載故障解決方法】相關(guān)文章:

軟件系統(tǒng)引起的路由器故障08-15

路由器故障及解決方法11-11

因沖突引起的網(wǎng)絡(luò)故障解決方法11-12

網(wǎng)吧路由器接口故障的解決方法08-15

路由器物理故障08-20

內(nèi)存引起故障的原因分析10-09

氧化引起的故障硬盤電極07-04

網(wǎng)卡引起的網(wǎng)絡(luò)故障05-19

路由器故障解決思路08-18