路由器設置經典實例 徹底解決過載而不斷重啟問題
也許很多人對路由器設置還不是特別的了解,于是我研究了一下路由器中過載而不斷重啟問題,在這里拿出來和大家分享一下,希望對大家有用。把deny-virus這個ACL應用到上聯接口(uplink)上:acl deny-virus apply interface uplink input output。
這樣就可以把“沖擊波殺手”從網絡的出口處堵截住。為了防止已經感染“沖擊波殺手”的主機在校內各個虛網之間傳播,還得把這個ACL應用到校內各虛網的接口上。這時使用再“system show cpu-utilization”查看CPU的使用率,它又恢復到正常狀態,等待了一段時間后,再沒有出現重啟現象。
由于路由器設置不能自動丟棄這種病毒發出的攻擊數據包,而導致了路由器重啟。為了徹底解決問題,還得升級路由器的IOS(可以使用“system show version”來查看當前使用的IOS的版本)。記得兩年前在“紅色代碼”病毒盛行的時候,也出現過路由器設置因過載而不斷重啟的現象,升級IOS以后就恢復正常了。于是立刻和設備供應商取得聯系并獲得最新的IOS映像文件。至此,路由器故障全部解決。
從這場故障處理中,我們可以得到這樣的教訓:時刻關注網絡上事態的發展,并作出相應的解決方案,而且付諸實施。一旦有新的漏洞出現,CCERT安全響應小組會自動發送郵件給你。當時暑假期間得知“沖擊波”后,由于及時在路由器設置,所以“沖擊波”病毒沒有在網內泛濫,但隨后的“沖擊波殺手”沒有及時設置相應的ACL,所以才導致這次的網絡癱瘓。實際上,在這次的“沖擊波”和“沖擊波殺手”的襲擊中,很多城域網也因此陷入癱瘓。這些經歷一次又一次的警告我們:時刻關注網絡安全,及時積極的應對。
故障:ICMP Redirect
這是個什么問題呢?首先給大家描述一下。雖然路由器設置在運行時沒有出現明顯的異常現象,但是卻經常看到這樣的日志:
Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 219.157.38.52
Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 219.167.139.16
Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 61.132.1.43
Jul 09 15:54:23 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 24.232.18.109
Jul 09 15:54:23 %ACL_LOG-I-PERMIT, ACL [out]
on "uplink" ICMP 209.24.79.200 -> 211.146.112.211
…………………….
其中“209.24.79.200”是路由器設置的上聯接口地址,我不知道為什么會出現這么多從路由器設置發到這些沒有規律的IP的ICMP數據包。查查這些IP,有的來自國內各省,有的來自日本,有的來自美國、阿根廷、新加坡,毫無規律。難道是有人在攻擊路由器?或者是內部有肉機被人用來攻擊?而且奇怪的是只有出去的數據包的記錄,卻沒有記錄進入的數據包?
說起ICMP,大家肯定是熟悉不過的了。最常見的ping命令就是使用ICMP的。ICMP的全稱是Internet Control Message Protocol(網間報文控制協議),它是IP不可分割的一部分,用來提供錯誤報告。一旦發現各種錯誤類型就將其返回原主機,基于ICMP的攻擊方法也多種多樣。到底是什么原因導致生成這樣的日志?讓我帶大家一起來查一查。
我校的拓撲結構是一個簡單的星型結構,中心節點就是一臺三層交換式路由器設置(Enterasys 公司的SSR8000)。其中一個端口上聯到CERNET,其他端口都是內部連接,且為內部網絡基于端口劃分了多個VLAN。為了查看該信息是否從網絡內部發出,又給內部VLAN的各個接口設置了日志,還是沒有相關的ICMP記錄(原先的日志只是記錄上聯接口的數據)。排除了內部計算機發出ICMP數據包的可能,那問題就可能出現在上聯接口上,而日志記錄只能記錄到協議層的信息,不能記錄更深層次的數據包。如何查看上聯接口的數據包呢,比較方便的方法就是使用端口鏡像功能,利用連接在鏡像端口上的計算機來抓取和分析數據包。

















