我(wǒ)接到一(yī)個求助電話(huà)，說他的機器不能上網了。主機所在的虛網和網絡中(zhōng)心不在同一(yī)個虛網中(zhōng)。說5分(fēn)鍾前還能上網），現在不知(zhī)道爲什麽就不好上網了。而且他的機器（安裝的系統爲WindowsXP）最近沒有安裝什麽新的程序，沒有移動過電腦，也沒有拔過網線。
   
    首先，排查網絡客戶端的錯誤配置。進入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
   
    上面顯示的配置是正确的，然後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地址是生(shēng)效的，網卡工(gōng)作正常。
   
    再使用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
   
    ……
   
    從主機向網關發送的數據包全部都得到了回應，線路是連通的。打開(kāi)浏覽器，也能夠正常上網沒問題。現在的網絡是正常的！?忽然,網絡又(yòu)不通了！發現ping出的數據包未能到達網關。難道是網卡或者系統有問題？誰知(zhī)過了一(yī)會兒，發現又(yòu)通了。于是我(wǒ)把台式機上的網線插到自帶的筆記本電腦上，配置好IP地址後ping網關，也出現時斷時續的情況。斷開(kāi)的現象大(dà)概持續了50秒鍾，然後又(yòu)恢複正常。基本排除主機的問題(因爲兩台不相幹主機同時出現同樣此類問題的幾率幾乎爲零)。排除了連接線纜的故障

于是檢查二層交換機上(這是一(yī)個由兩台交換機的堆疊，其中(zhōng)一(yī)台交換機上有一(yī)個上聯的千兆端口),把筆記本接到交換機的其中(zhōng)一(yī)個端口上，再ping網關。故障仍然，而且每過4分(fēn)鍾到 10分(fēn)鍾，網絡就會斷一(yī)次，并且40到50秒後又(yòu)恢複正常。但是沒有發現端口指示燈的異常，說明交換機的各個端口均正常。

重啓交換機，故障依舊(jiù)。忽然另外(wài)一(yī)個又(yòu)報障.他的機器也出現相同的故障現象(前提:他主機在另外(wài)一(yī)個虛網中(zhōng))于是判斷是連接這兩個虛網的路由器出了問題。
    
   從路由器的外(wài)部指示燈上看，沒什麽異常現象。将一(yī)台機器直接連在路由器的百兆模塊上上ping路由器的地址，也是時通時斷。我(wǒ)又(yòu)繼續觀察了一(yī)段時間，發現每過4分(fēn)鍾到10分(fēn)鍾，路由器所有模塊的指示燈都會同時熄滅，接着控制模塊上的 “HBT”燈閃爍，然後“OK”燈亮起，最後所有模塊的指示燈均顯示Online.("HBT"燈閃爍表示路由器正在啓動，也就是說正在自動重啓，而且40秒左右的網絡斷開(kāi)時間正好是路由器的重啓所需的時間。    
    趁着路由器正常工(gōng)作的時候，把筆記本的COM口使用路由器的專用CONSOLE線連接起來，建立超級終端。在管理模式下(xià)使用命令 “systemshowbootlog”查看系統的啓動記錄，發現各個模塊的加載均屬正常。造成路由器重啓的原因，最大(dà)的可能就是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%）
   
    果然，連續使用此命令後得知(zhī)CPU利用率正在逐漸上升，當達到95%的時候路由器便自動重啓。看來路由器的負載太大(dà)了，因爲平時正常情況下(xià)，CPU的使用率僅爲1%-6%左右。當網絡使用高峰期的時候CPU的利用率會稍微高一(yī)點。但到底是什麽讓路由器過載呢？用“system show syslog buffer”命令來查看當前系統緩存中(zhōng)的日志(zhì)記錄：
   
    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協議向其他主機發起攻擊，據此判斷，這台主機要麽是中(zhōng)毒，要麽是被黑客利用了。鑒于當時的情況分(fēn)析，可能是網絡中(zhōng)存在中(zhōng)了“沖擊波殺手”病毒的主機。該病毒使用類型爲echo的ICMP報文來ping根據自身算法得出的ip地址段，以此檢測這些地址段中(zhōng)存活的主機，并發送大(dà)量載荷爲“aa”,填充長度92字節的icmp報文，從而導緻網絡堵塞。而且病毒一(yī)旦發現存活的主機，便試圖使用135端口的 rpc漏洞和80端口的webdav漏洞進行溢出攻擊。溢出成功後會監聽(tīng)69（TFTP專業端口，用于文件下(xià)載）端口和666-765（通常是707端口）範圍中(zhōng)的一(yī)個随機端口等待目标主機回連。
   
    根據該病毒的傳播機理，立刻在路由器上設置訪問控制列表（ACL），以阻塞UDP協議的69端口（用于文件下(xià)載）、TCP的端口135（微軟的DCOM RPC端口）和ICMP協議（用于發現活動主機）。具體(tǐ)的ACL配置如下(xià)：
   
    ! --- 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應用到各虛網的接口上。這時使用再“system showcpu-utilization”查看CPU的使用率，它又(yòu)恢複到正常狀态，等待了一(yī)段時間後，再沒有出現重啓現象。
   
    由于路由器不能自動丢棄這種病毒發出的攻擊數據包，而導緻了路由器重啓。爲了徹底解決問題，還得升級路由器的IOS（可以使用“system showversion”來查看當前使用的IOS的版本）。至此，路由器故障全部解決。