處理「紅色代碼」蠕蟲引起的mallocfail和CPU使用率高問題
目錄
簡介
本文檔介紹「紅色代碼」蠕蟲及其在Cisco路由環境中可能引起的問題。本檔案也說明防止蠕蟲感染的技術，並提供相關建議的連結，這些建議的說明針對蠕蟲相關問題的解決方案。
「紅色代碼」蠕蟲利用Microsoft Internet Information Server (IIS) 5.0版的Index Service中的漏洞。當「紅色代碼」蠕蟲感染主機時，它會導致主機探測並感染一系列隨機的IP地址，從而導致網路流量急劇增加。如果網路中有備援連結和/或未使用思科快速轉送(CEF)來交換封包，則問題尤其嚴重。
必要條件
需求
本文件沒有特定需求。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。
慣例
如需文件慣例的詳細資訊，請參閱思科技術提示慣例。
「紅色代碼」蠕蟲如何感染其他系統
「紅色代碼」蠕蟲會嘗試連線到隨機生成的IP地址。每個受感染的IIS伺服器都可以嘗試感染同一組裝置。您可以追蹤蠕蟲的來源IP位址和TCP連線埠，因為它沒有被偽裝。單播反向路徑轉發(URPF)無法抑制蠕蟲攻擊，因為源地址是合法的。
討論「紅色代碼」蠕蟲的公告
以下建議說明「紅色代碼」蠕蟲，並說明如何修補受蠕蟲影響的軟體：
症狀
以下症狀表示Cisco路由器受到「紅色代碼」蠕蟲的影響：
-
NAT或PAT表中的大量流（如果使用NAT或PAT）。
-
網路中存在大量ARP請求或ARP風暴（由IP地址掃描引起）。
-
IP Input、ARP Input、IP Cache Ager和CEF進程佔用過多記憶體。
-
ARP、IP輸入、CEF和IPC中的CPU使用率較高。
-
如果使用NAT，則在低流量速率下的中斷級別上的CPU使用率較高，或者在IP輸入中的進程級別上的CPU使用率較高。
記憶體不足或中斷層級的CPU使用率持續過高(100%)，可能會導致Cisco IOS®路由器重新載入。重新載入是由因應力條件而造成行為不當的處理序所造成。
如果您不懷疑站點中的裝置受到「紅色代碼」蠕蟲的感染或目標，請參閱相關資訊部分以瞭解有關如何解決您遇到的任何問題的附加URL。
辨識受感染的裝置
使用流交換確定受影響裝置的源IP地址。在所有介面上配置ip route-cache flow，以記錄路由器交換的所有資料流。
幾分鐘之後，發出show ip cache flow命令以檢視所記錄的條目。在「紅色代碼」蠕蟲感染的初始階段，蠕蟲會嘗試自我複製。蠕蟲向隨機IP地址傳送HT請求時，就會發生複製。因此，必須查詢目標埠為80(HT.， 0050（以十六進位制表示）的快取流條目。
show ip cache flow | include 0050命令顯示TCP埠為80（0050以十六進位制表示）的所有快取條目：
Router#show ip cache flow | include 0050 ... scram scrappers dative DstIPaddress Pr SrcP DstP Pkts Vl1 193.23.45.35 Vl3 2.34.56.12 06 0F9F 0050 2 Vl1 211.101.189.208 Null 158.36.179.59 06 0457 0050 1 Vl1 193.23.45.35 Vl3 34.56.233.233 06 3000 0050 1 Vl1 61.146.138.212 Null 158.36.175.45 06 B301 0050 1 Vl1 193.23.45.35 Vl3 98.64.167.174 06 0EED 0050 1 Vl1 202.96.242.110 Null 158.36.171.82 06 0E71 0050 1 Vl1 193.23.45.35 Vl3 123.231.23.45 06 121F 0050 1 Vl1 193.23.45.35 Vl3 9.54.33.121 06 1000 0050 1 Vl1 193.23.45.35 Vl3 78.124.65.32 06 09B6 0050 1 Vl1 24.180.26.253 Null 158.36.179.166 06 1132 0050 1
如果您發現具有同一源IP地址、隨機目標IP地址1、DstP = 0050 (HTTP)和Pr = 06 (TCP)的條目數量異常大，則可能找到感染病毒的裝置。在此輸出範例中，來源IP位址是193.23.45.35，且來自VLAN1。
1「紅色代碼」蠕蟲的另一個版本（稱為「紅色代碼II」）不選擇完全隨機目標IP地址。相反，「紅色代碼II」保留IP地址的網路部分，並選擇隨機主機部分的IP地址以便傳播。這使得蠕蟲可以在同一網路中更快速地自我傳播。
「紅色代碼II」使用以下網路和掩碼：
Mask Probability of Infection 0.0.0.0 12.5% (random) 255.0.0.0 50.0% (same class A) 255.255.0.0 37.5% (same class B)
排除的目標IP地址為127.X.X.X和224.X.X.X，並且不允許二進位制八位數是0或255。此外，宿主不會嘗試再次感染自己。
有關詳細資訊，請參閱紅色代碼(II) 
。
有時，您無法運行netflow來檢測「紅色代碼」感染嘗試。這可能是因為您執行的程式碼版本不支援netflow，或是因為路由器沒有足夠的記憶體或過於分散的記憶體來啟用netflow。Cisco建議您在路由器上有多個輸入介面且只有一個輸出介面時不要啟用netflow，因為netflow記帳是在輸入路徑上執行的。在這種情況下，最好在單一輸出介面上啟用IP計量。
注意： ip accounting 命令停用DCEF。請勿在您要使用DCEF交換的任何平台上啟用IP記帳。
Router(config)#interface vlan 1000 Router(config-if)#ip accounting Router#show ip accounting Source Destination Packets Bytes 20.1.145.49 75.246.253.88 2 96 20.1.145.43 17.152.178.57 1 48 20.1.145.49 20.1.49.132 1 48 20.1.104.194 169.187.190.170 2 96 20.1.196.207 20.1.1.11 3 213 20.1.145.43 43.129.220.118 1 48 20.1.25.73 43.209.226.231 1 48 20.1.104.194 169.45.103.230 2 96 20.1.25.73 223.179.8.154 2 96 20.1.104.194 169.85.92.164 2 96 20.1.81.88 20.1.1.11 3 204 20.1.104.194 169.252.106.60 2 96 20.1.145.43 126.60.86.19 2 96 20.1.145.49 43.134.116.199 2 96 20.1.104.194 169.234.36.102 2 96 20.1.145.49 15.159.146.29 2 96
在show ip accounting 命令輸出中，查詢嘗試向多個目標地址傳送資料包的源地址。如果受感染的主機處於掃描階段，它會嘗試建立到其他路由器的HTTP連線。您將看到嘗試訪問多個IP地址。大多數連線嘗試通常都會失敗。因此，您只看到傳輸了少量資料包，每個資料包的位元組數都很少。在本示例中，20.1.145.49和20.1.104.194可能被感染。
在Catalyst 5000系列和Catalyst 6000系列上運行多層交換(MLS)時，必須執行不同的步驟以啟用NetFlow記賬並跟蹤感染。在配備Supervisor 1多層次交換功能卡(MSFC1)或SUP I/MSFC2的Cat6000交換器中，預設會啟用基於NetFlow的MLS，但流量模式是僅目的地模式。因此，源IP地址不會快取。借助於Supervisor上的set mls flow full 命令，可以啟用「full-flow」模式以跟蹤受感染的主機。
對於混合模式，請使用set mls flow full命令：
6500-sup(enable)set mls flow full Configured IP flowmask is set to full flow. Warning: Configuring more specific flow mask may dramatically increase the number of MLS entries.
對於本地IOS模式，請使用mls flow ip full 命令：
Router(config)#mls flow ip full
啟用「全流」模式時，將顯示一條警告，指示MLS條目大幅增加。如果您的網路已受到「紅色代碼」蠕蟲的感染，增加MLS條目對短時間內的影響是合理的。該蠕蟲會導致您的MLS條目過多，並呈上升趨勢。
要檢視收集的資訊，請使用以下命令：
對於混合模式，請使用set mls flow full命令：
6500-sup(enable)set mls flow full Configured IP flowmask is set to full flow. Warning: Configuring more specific flow mask may dramatically increase the number of MLS entries.
對於本地IOS模式，請使用mls flow ip full命令：
Router(config)#mls flow ip full
啟用「全流」模式時，將顯示一條警告，指示MLS條目大幅增加。如果您的網路已受到「紅色代碼」蠕蟲的感染，增加MLS條目對短時間內的影響是合理的。該蠕蟲會導致您的MLS條目過多，並呈上升趨勢。
要檢視收集的資訊，請使用以下命令：
對於混合模式，請使用show mls ent 命令：
6500-sup(enable)show mls ent Destination-IP Source-IP Prot DstPrt SrcPrt Destination-Mac Vlan EDst ESrc DPort SPort Stat-Pkts Stat-Bytes Uptime Age -------------- --------------- ----- ------ ------ ----------------- ---- ---- ---- --------- --------- ---------- ----------- -------- --------
注意：當這些欄位處於「全流程」模式時，它們都會填入。
對於本地IOS模式，請使用show mls ip命令：
Router#show mls ip DstIP SrcIP Prot:SrcPort:DstPort Dst i/f:DstMAC -------------------------------------------------------------------- Pkts Bytes SrcDstPorts SrcDstEncap Age LastSeen --------------------------------------------------------------------
當您確定攻擊所涉及的源IP地址和目標埠時，可以將MLS設定回「僅目標」模式。
對於混合模式，請使用set mls flow destination命令：
6500-sup(enable) set mls flow destination Usage: set mls flow <destination|destination-source|full>
對於本地IOS模式，請使用mls flow ip destination命令：
Router(config)#mls flow ip destination
Supervisor (SUP) II/MSFC2組合在硬體中執行CEF交換，並且維護netflow統計資訊，因此可免受攻擊。因此，即使在「紅色代碼」攻擊期間，如果啟用全流模式，路由器也不會被淹沒，因為交換機制更快。在SUP I/MFSC1和SUP II/MSFC2上啟用全流模式和顯示統計資訊的命令相同。
預防技術
使用本節所列的技術，將「紅色代碼」蠕蟲對路由器的影響降至最低。
阻止流向埠80的流量
如果它在您的網路中可行，防止「紅色代碼」攻擊的最簡單方法是阻止發往WWW公認埠80的所有流量。建立訪問清單以拒絕發往埠80的IP資料包，並將其應用到面向感染源的介面的入站方向。
減少ARP輸入記憶體使用
當靜態路由指向廣播介面時，ARP輸入會消耗大量記憶體，如下所示：
ip route 0.0.0.0 0.0.0.0 Vlan3
預設路由的每個資料包都傳送到VLAN3。但是，沒有指定下一跳IP地址，因此，路由器會傳送目的IP地址的ARP請求。除非停用了代理ARP，否則該目標的下一跳路由器將使用自己的MAC地址進行應答。來自路由器的回覆會在ARP表中建立一個附加條目，其中資料包的目的IP地址對映到下一跳MAC地址。「紅色代碼」蠕蟲將資料包傳送到隨機IP地址，為每個隨機目標地址增加一個新的ARP條目。在ARP輸入過程中，每個新的ARP條目會佔用越來越多的記憶體。
請勿建立到介面的靜態預設路由，尤其是當介面為廣播（乙太網/快速乙太網/GE/SMDS）或多點（幀中繼/ATM）時。任何靜態預設路由都必須指向下一跳路由器的IP地址。更改預設路由以指向下一跳IP地址後，使用clear arp-cache命令清除所有ARP條目。此命令可解決記憶體利用率問題。
使用Cisco Express Forwarding (CEF)交換
為了降低IOS路由器上的CPU使用率，請從「快速/最佳/Netflow」交換更改為「CEF交換」。啟用CEF時需要注意以下幾點。下一節討論CEF和快速交換之間的區別，並解釋啟用CEF時的含義。
Cisco Express Forwarding與快速交換
啟用CEF以緩解「紅色代碼」蠕蟲導致的流量負載增加。Cisco IOS®軟體版本11.1()CC、12.0和更高版本支援Cisco 7200/7500/GSR平台上的CEF。Cisco IOS軟體版本12.0或更高版本支援其他平台上的CEF。您可以使用Software Advisor工具進行進一步檢查。
有時，由於以下原因之一，您不能在所有的路由器上啟用CEF：
-
記憶體不足
-
不受支援的平台體系結構
-
不支援的介面封裝
快速交換行為及其影響
以下是使用快速交換時的含義：
-
流量驅動快取-快取為空，直到路由器交換資料包並填充快取。
-
第一個資料包是進程交換的-第一個資料包是進程交換的，因為快取最初是空的。
-
粒度快取-快取建立在主網最具體的路由資訊庫(RIB)條目部分的粒度上。如果RIB有/24s代表主網131.108.0.0，則快取將使用/24s代表此主網。
-
使用/32快取記憶體—/32快取記憶體用於平衡每個目的地的負載。當快取記憶體平衡負載時，該主網的快取記憶體是使用/32s構建的。
注意：後面兩個問題可能會導致佔用所有記憶體的快取記憶體過大。
-
在主網路邊界快取-使用預設路由，在主網路邊界執行快取。
-
快取記憶體管理員—快取記憶體管理員每分鐘執行一次，並檢查第1/20 (5%)的快取記憶體是否未使用專案，以及在記憶體不足的情況下(200k)檢查第1/4 (25%)的快取記憶體。
為了更改上述值，請使用ip cache-ager-interval X Y Z命令，其中：
-
X是<0-2147483>Ager運行之間的秒數。預設值= 60秒。
-
Y是<2-50> 1/(Y+1)的快取記憶體，每次執行都會老化（記憶體不足）。預設值= 4。
-
Z是<3-100> 1/(Z+1)的快取記憶體，每次執行都會過期（正常）。預設值= 20。
以下是使用ip cache-ager 60 5 25的配置示例。
Router#show ip cache
IP routing cache 2 entries, 332 bytes
27 adds, 25 invalidates, 0 refcounts
Cache aged by 1/25 every 60 seconds (1/5 when memory is low).
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 03:55:12 ago
Prefix/Length Age Interface Next Hop
4.4.4.1/32 03:44:53 Serial1 4.4.4.1
192.168.9.0/24 00:03:15 Ethernet1 20.4.4.1
Router#show ip cache verbose
IP routing cache 2 entries, 332 bytes
27 adds, 25 invalidates, 0 refcounts
Cache aged by 1/25 every 60 seconds (1/5 when memory is low).
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 03:57:31 ago
Prefix/Length Age Interface Next Hop
4.4.4.1/32-24 03:47:13 Serial1 4.4.4.1
4 0F000800
192.168.9.0/24-0 00:05:35 Ethernet1 20.4.4.1
14 00000C34A7FC00000C13DBA90800
根據快取記憶體的設定，快取記憶體表格中會有部分快取記憶體專案過期。當條目快速老化時，快速快取表中的較大比例會老化，並且快取表會變小。因此，路由器上的記憶體消耗會降低。缺點是快取表中過時的條目流量會持續流動。初始資料包是進程交換的，這會導致IP輸入中的CPU使用率出現短暫峰值，直到為流構建新的快取條目。
從Cisco IOS軟體版本10.3(8)、11.0(3)及更高版本開始，對IP快取管理器的處理方式有所不同，如下所示：
-
僅當配置中定義了service internal命令時，ip cache-ager-interval和ip cache-invalidate-delay命令才可用。
-
如果介於無效驗證執行之間的期間設為0，則會完全停用ager處理作業。
-
時間以秒表示。
注意：執行這些命令時，路由器的CPU使用率會增加。僅在絕對必要時才使用這些命令。
Router#clear ip cache ? A.B.C.D Address prefix <CR>--> will clear the entire cache and free the memory used by it! Router#debug ip cache IP cache debugging is on
CEF的優點
-
轉發資訊庫(FIB)表基於路由表構建。因此，轉發第一個資料包之前存在轉發資訊。FIB還包含直連LAN主機的/32條目。
-
鄰接關係(ADJ)表包含下一跳和直連主機的第2層重寫資訊（ARP條目建立CEF鄰接關係）。
-
CEF沒有快取記憶體管理程式概念，不會增加CPU使用率。如果刪除路由表條目，則刪除FIB條目。
注意：同樣，指向廣播或多點介面的預設路由意味著路由器為每個新目標傳送ARP請求。來自路由器的ARP請求可能會建立巨大的鄰接表，直到路由器記憶體耗盡。如果CEF無法分配記憶體，CEF/DCEF將停用自身。您將需要再次手動啟用CEF/DCEF。
示例輸出：CEF
以下是show ip cef summary命令的一些示例輸出，其中顯示記憶體使用情況。此輸出是使用Cisco IOS軟體版本12.0的Cisco 7200路由伺服器的快照。
Router>show ip cef summary IP CEF with switching (Table Version 2620746) 109212 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 84625 109212 leaves, 8000 nodes, 22299136 bytes, 2620745 inserts, 2511533 invalidations 17 load sharing elements, 5712 bytes, 109202 references universal per-destination load sharing algorithm, id 6886D006 1 CEF resets, 1 revisions of existing leaves 1 in-place/0 aborted modifications Resolution Timer: Exponential (currently 1s, peak 16s) refcounts: 2258679 leaf, 2048256 node Adjacency Table has 16 adjacencies Router>show processes memory | include CEF PID TTY Allocated Freed Holding Getbufs Retbufs Process 73 0 147300 1700 146708 0 0 CEF process 84 0 608 0 7404 0 0 CEF Scanner Router>show processes memory | include BGP 2 0 6891444 6891444 6864 0 0 BGP Open 80 0 3444 2296 8028 0 0 BGP Open 86 0 477568 476420 7944 0 0 BGP Open 87 0 2969013892 102734200 338145696 0 0 BGP Router 88 0 56693560 2517286276 7440 131160 4954624 BGP I/O 89 0 69280 68633812 75308 0 0 BGP Scanner 91 0 6564264 6564264 6876 0 0 BGP Open 101 0 7635944 7633052 6796 780 0 BGP Open 104 0 7591724 7591724 6796 0 0 BGP Open 105 0 7269732 7266840 6796 780 0 BGP Open 109 0 7600908 7600908 6796 0 0 BGP Open 110 0 7268584 7265692 6796 780 0 BGP Open Router>show memory summary | include FIB Alloc PC Size Blocks Bytes What 0x60B8821C 448 7 3136 FIB: FIBIDB 0x60B88610 12000 1 12000 FIB: HWIDB MAP TABLE 0x60B88780 472 6 2832 FIB: FIBHWIDB 0x60B88780 508 1 508 FIB: FIBHWIDB 0x60B8CF9C 1904 1 1904 FIB 1 path chunk pool 0x60B8CF9C 65540 1 65540 FIB 1 path chunk pool 0x60BAC004 1904 252 479808 FIB 1 path chun 0x60BAC004 65540 252 16516080 FIB 1 path chun Router>show memory summary | include CEF 0x60B8CD84 4884 1 4884 CEF traffic info 0x60B8CF7C 44 1 44 CEF process 0x60B9D12C 14084 1 14084 CEF arp throttle chunk 0x60B9D158 828 1 828 CEF loadinfo chunk 0x60B9D158 65540 1 65540 CEF loadinfo chunk 0x60B9D180 128 1 128 CEF walker chunk 0x60B9D180 368 1 368 CEF walker chunk 0x60BA139C 24 5 120 CEF process 0x60BA139C 40 1 40 CEF process 0x60BA13A8 24 4 96 CEF process 0x60BA13A8 40 1 40 CEF process 0x60BA13A8 72 1 72 CEF process 0x60BA245C 80 1 80 CEF process 0x60BA2468 60 1 60 CEF process 0x60BA65A8 65488 1 65488 CEF up event chunk Router>show memory summary | include adj 0x60B9F6C0 280 1 280 NULL adjacency 0x60B9F734 280 1 280 PUNT adjacency 0x60B9F7A4 280 1 280 DROP adjacency 0x60B9F814 280 1 280 Glean adjacency 0x60B9F884 280 1 280 Discard adjacency 0x60B9F9F8 65488 1 65488 Protocol adjacency chunk
需要考慮的事項
當流量數量較大時，CEF通常比快速交換消耗更少的記憶體。如果快速交換快取已佔用記憶體，您必須在啟用CEF之前清除ARP快取(透過clear ip arp命令)。
注意：清除快取時，路由器的CPU使用率會出現峰值。
「紅色代碼」常見問題及其解答
問：我使用NAT，並且在IP輸入中體驗到100%的CPU使用率。當我執行show proc cpu時，我的CPU利用率在中斷級別-100/99或99/98很高。這是否與「紅色代碼」有關？
答：最近修復了一個NAT思科漏洞(CSCdu63623(僅限註冊客戶))，該漏洞涉及可擴充性。當有數以萬計的NAT流（根據平台型別）時，Bug會導致進程或中斷級別的CPU利用率達到100%。
要確定原因是否是此Bug，請發出show align命令，並驗證路由器是否面臨校準錯誤。如果您確實看到了校驗錯誤或欺騙記憶體訪問，發出幾次show align命令，並且檢查錯誤是否增加。如果錯誤數量在上升，校準錯誤可能是導致中斷級別CPU使用率較高的原因，而不是導致Cisco錯誤CSCdu63623(僅限註冊客戶)。有關詳細資訊，請參閱欺騙性訪問和校正錯誤故障排除。
show ip nat translation命令顯示活動轉換的數量。NPE-300級處理器的熔毀點大約是20,000到40,000個翻譯。此數字隨平台而異。
此熔毀問題以前曾被一些客戶發現，但在「紅色代碼」之後，更多客戶遇到過此問題。唯一的解決方法是運行NAT（而不是PAT），這樣可以減少活動轉換。如果有7200，請使用NSE-1，然後降低NAT超時值。
問：我運行IRB，在HyBridge輸入過程中遇到高CPU使用率。為什麼會發生這種情況？跟「紅色代碼」有關嗎？
A. HyBridge輸入進程處理任何無法由IRB進程快速交換的資料包。IRB程式無法快速交換封包的原因可能是：
-
該資料包是廣播資料包。
-
該資料包是組播資料包。
-
目的地未知，需要觸發ARP。
-
存在生成樹BPDU。
如果同一網橋組中有數千個點對點介面，HyBridge輸入會遇到問題。如果同一多點介面中有數千個VS，HyBridge輸入也會遇到問題（但程度較輕）。
IRB出現問題的可能原因是什麼？假設感染了「紅色代碼」的裝置掃描IP地址。
-
路由器需要為每個目的IP地址傳送ARP請求。網橋組中的每條VC上都會產生大量的ARP請求，用於掃描每個地址。正常的ARP進程不會導致CPU問題。但是，如果存在沒有網橋條目的ARP條目，路由器會向已存在ARP條目的地址泛洪資料包。這可能會導致CPU使用率過高，因為流量是進程交換的。要避免此問題，請增加網橋老化時間（預設值為300秒或5分鐘）以匹配或超過ARP超時（預設值為4小時），從而使兩個計時器同步。
-
終端主機嘗試感染的地址是廣播地址。路由器執行的子網廣播相當於HyBridge輸入進程需要複製的子網廣播。如果配置了no ip directed-broadcast命令，則不會發生這種情況。從Cisco IOS軟體版本12.0，預設情況下ip directed-broadcast命令處於停用狀態，這將導致丟棄所有IP定向廣播。
-
下面是與「紅色代碼」無關並與IRB架構相關的旁註：
需要複製第2層組播和廣播資料包。因此，在廣播網段上運行的IPX伺服器發生問題可能會使鏈路斷開。您可以使用訂戶策略來避免此問題。有關詳細資訊，請參閱x數字使用者線路(xDSL)網橋支援。您還必須考慮網橋訪問清單，這些清單會限制允許透過路由器的流量型別。
-
為了緩解此IRB問題，您可以使用多個網橋組，並確保為BVI、子介面和VC提供一對一的對映。
-
RBE優於IRB，因為它完全避免了橋接堆疊。您可以從IRB移轉到RBE。這些思科漏洞會促使進行此類遷移：
-
CSCdr11146(僅限註冊客戶)
-
CSCdp18572(僅限註冊客戶)
-
CSCds40806(僅限註冊客戶)
-
問：我的CPU利用率在中斷級別很高，如果嘗試顯示日誌，我會收到刷新資訊。流量速率也只是略高於正常速率。原因何在？
A.以下是show logging命令輸出的示例：
Router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
^
this value is non-zero
Console logging: level debugging, 9 messages logged
檢查您是否登入到控制檯。如果是，請檢查是否有流量HTTP要求。接下來，檢查是否有任何包含log關鍵字的訪問清單或監控特定IP流的調試。如果流量增加，可能是因為控制檯（通常是9600波特裝置）無法處理收到的資訊量。在這種情況下，路由器會停用中斷，而只處理控制檯消息。解決方案是停用控制檯日誌記錄或刪除您執行的任何型別的日誌記錄。
問：我可以在運行ip http-server的IOS路由器上看到許多HTTP連線嘗試。這是因為「紅色代碼」蠕蟲掃描嗎？
A. 「紅色代碼」可能是原因。Cisco建議您在IOS路由器上停用ip http server命令，這樣它就不需要處理來自受感染主機的多次連線嘗試。
因應措施
討論「紅色代碼」蠕蟲的建議部分討論了各種解決方法。請參考建議以瞭解解決方法。
另一種在網路入口點阻止「紅色代碼」蠕蟲的方法使用思科路由器上IOS軟體中的基於網路的應用辨識(NBAR)和訪問控制清單(ACL)。請將此方法與Microsoft IIS伺服器的建議修補程式搭配使用。有關此方法的詳細資訊，請參閱使用NBAR和ACL在網路入口點攔截「紅色代碼」蠕蟲。
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
10-Dec-2001 |
初始版本 |
意見