分析負(fù)載過大導(dǎo)致路由器設(shè)置出現(xiàn)問題
路由器設(shè)置還有很多值得我們學(xué)習(xí)的地方,這里我們主要介紹負(fù)載過大導(dǎo)致路由器設(shè)置出現(xiàn)問題,我把筆記本接到交換機(jī)的其中一個(gè)端口上,再ping網(wǎng)關(guān)。還是同樣的故障,而且還發(fā)現(xiàn)每過4分鐘到10分鐘,網(wǎng)絡(luò)就會斷一次,并且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)的路由器設(shè)置出了問題。
這回問題集中到路由器設(shè)置上了。我急忙回到網(wǎng)絡(luò)中心,從路由器的外部指示燈上看,沒什么異?,F(xiàn)象。在我的網(wǎng)管機(jī)上ping路由器的地址(我的網(wǎng)管機(jī)是直接連在路由器的百兆模塊上的),也是時(shí)通時(shí)斷。我又繼續(xù)觀察了一段時(shí)間,發(fā)現(xiàn)每過4分鐘到10分鐘,路由器所有模塊的指示燈都會同時(shí)熄滅,接著控制模塊上的“HBT”燈閃爍,然后“OK”燈亮起,最后所有模塊的指示燈均顯示Online。我解釋一下,“HBT”燈閃爍表示路由器正在啟動,也就是說正在自動重啟,而且40秒左右的網(wǎng)絡(luò)斷開時(shí)間正好是路由器的重啟所需的時(shí)間。現(xiàn)在問題的查找工作已經(jīng)結(jié)束,肯定是路由器出了故障。具體是什么問題,還需要進(jìn)一步的檢測。趁著路由器正常工作的時(shí)候,把筆記本的COM口使用路由器的專用CONSOLE線連接起來,建立超級終端。在管理模式下使用命令“systemshowbootlog”查看系統(tǒng)的啟動記錄,發(fā)現(xiàn)各個(gè)模塊的加載均屬正常。造成路由器設(shè)置中重啟的原因,最大的可能就是CPU的利用率達(dá)到100%。使用“systemshowcpu-utilization”命令查看CPU的使用率:
SSR#systemshowcpu-utilization
CPUUtilization(5seconds):50%
(60seconds):60%(前者是指5秒鐘內(nèi)CPU平均使用率為50%,
后者是60秒鐘內(nèi)CPU平均使用率為60%)
果然,連續(xù)使用此命令后得知CPU利用率正在逐漸上升,當(dāng)達(dá)到95%的時(shí)候路由器設(shè)置自動重啟。看來路由器的負(fù)載太大了,因?yàn)槠綍r(shí)正常情況下,CPU的使用率僅為1%—6%左右。當(dāng)網(wǎng)絡(luò)使用高峰期的時(shí)候CPU的利用率會稍微高一點(diǎn)。但到底是什么讓路由器過載呢?幸好以前曾經(jīng)給路由器設(shè)置過日志記錄,并把日志發(fā)送到一個(gè)日志服務(wù)器上。但是打開這臺服務(wù)器所記錄的日志并未能找到有用的線索。因?yàn)楫?dāng)路由器設(shè)置負(fù)載過大時(shí),它已經(jīng)不能往日志服務(wù)器上發(fā)送日志了,我只能用“systemshowsyslogbuffer”命令來查看當(dāng)前系統(tǒng)緩存中的日志記錄:
SSR#systemshowsyslogbuffer
2003-09-1009:28:32%ACL_LOG-I-DENY,ACL[out]
on"uplink"ICMP210.16.3.82->210.55.37.72
2003-09-1009:28:32%ACL_LOG-I-PERMIT,ACL[out]
on"uplink"ICMP210.16.3.82->61.136.65.13
2003-09-1009:28:32%ACL_LOG-I-DENY,ACL[out]
on"uplink"ICMP210.16.3.82->202.227.100.65
2003-09-1009:28:32%ACL_LOG-I-DENY,ACL[out]
on"uplink"ICMP210.16.3.82->193.210.224.202
2003-09-1009:28:32%ACL_LOG-I-DENY,ACL[out]
on"uplink"ICMP210.16.3.82->218.32.21.101
………………
很明顯,“210.16.3.82”這臺在使用ICMP協(xié)議向其他主機(jī)發(fā)起攻擊,據(jù)此判斷,這臺主機(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)行溢出攻擊。溢出成功后會監(jiān)聽69(TFTP專業(yè)端口,用于文件下載)端口和666-765(通常是707端口)范圍中的一個(gè)隨機(jī)端口等待目標(biāo)主機(jī)回連。
根據(jù)該病毒的傳播機(jī)理,立刻在路由器設(shè)置訪問控制列表(ACL),以阻塞UDP協(xié)議的69端口(用于文件下載)、TCP的端口135(微軟的DCOMRPC端口)和ICMP協(xié)議(用于發(fā)現(xiàn)活動主機(jī))。具體的ACL配置如下:
!---blockICMP
acldeny-virusdenyicmpanyany
!---blockTFTP
acldeny-virusdenyudpanyanyany69
!---blockW32.Blasterrelatedprotocols
acldeny-virusdenytcpanyanyany135
acldeny-viruspermittcpanyanyanyany
acldeny-viruspermitudpanyanyanyany