也許很多人對路由器設置還不是特別的了解，于是我研究了一下路由器中過載而不斷重啟問題，在這里拿出來和大家分享一下，希望對大家有用。把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數據包的可能，那問題就可能出現在上聯接口上，而日志記錄只能記錄到協議層的信息，不能記錄更深層次的數據包。如何查看上聯接口的數據包呢，比較方便的方法就是使用端口鏡像功能，利用連接在鏡像端口上的計算機來抓取和分析數據包。