共找到2條詞條名為ICMP的結果 展開
- Internet控制報文協議
- 網間控制報文協議
ICMP
Internet控制報文協議
ICMP（Internet Control Message Protocol）Internet控制報文協議。它是TCP/IP協議簇的一個子協議，用於在IP主機、路由器之間傳遞控制消息。控制消息是指網路通不通、主機是否可達、路由是否可用等網路本身的消息。這些控制消息雖然並不傳輸用戶數據，但是對於用戶數據的傳遞起著重要的作用。
ICMP使用IP的基本支持，就像它是一個更高級別的協議，但是，ICMP實際上是IP的一個組成部分，必須由每個IP模塊實現。
ICMP協議是一種面向無連接的協議，用於傳輸出錯報告控制信息。它是一個非常重要的協議，它對於網路安全具有極其重要的意義。
它是TCP/IP協議族的一個子協議，屬於網路層協議，主要用於在主機與路由器之間傳遞控制信息，包括報告錯誤、交換受限控制和狀態信息等。當遇到IP數據無法訪問目標、IP路由器無法按當前的傳輸速率轉發數據包等情況時，會自動發送ICMP消息。ICMP報文在IP幀結構的首部協議類型欄位（Protocol 8bit)的值=1.
ICMP 是 TCP/IP 模型中網路層的重要成員，與 IP 協議、ARP 協議、RARP 協議及 IGMP 協議共同構成 TCP/IP 模型中的網路層。ping 和tracert是兩個常用網路管理命令，ping 用來測試網路可達性，tracert 用來顯示到達目的主機的路徑。ping和 tracert 都利用 ICMP 協議來實現網路功能，它們是把網路協議應用到日常網路管理的典型實例。
從技術角度來說，ICMP就是一個“錯誤偵測與回報機制”，其目的就是讓我們能夠檢測網路的連線狀況﹐也能確保連線的準確性。當路由器在處理一個數據包的過程中發生了意外，可以通過ICMP向數據包的源端報告有關事件。
其功能主要有：偵測遠端主機是否存在，建立及維護路由資料，重導資料傳送路徑（ICMP重定向），資料流量控制。ICMP在溝通之中，主要是透過不同的類別(Type)與代碼(Code) 讓機器來識別不同的連線狀況。
ICMP 是個非常有用的協議﹐尤其是當我們要對網路連接狀況進行判斷的時候。
ICMP
ICMP報文格式具體由RFC 777 ，RFC 792 規範。
ICMP提供一致易懂的出錯報告信息。發送的出錯報文返回到發送
原數據的設備，因為只有發送設備才是出錯報文的邏輯接受者。發送設備隨後可根據ICMP報文確定發生錯誤的類型，並確定如何才能更好地重發失敗的數據包。但是ICMP唯一的功能是報告問題而不是糾正錯誤，糾正錯誤的任務由發送方完成。
ICMP
我們在網路中經常會使用到ICMP協議，比如我們經常使用的用於檢查網路通不通的Ping命令（Linux和Windows中均有），這個“Ping”的過程實際上就是ICMP協議工作的過程。還有其他的網路命令如跟蹤路由的Tracert命令也是基於ICMP協議的。
ICMP的全稱是 Internet Control Message Protocol 。從技術角度來說，ICMP就是一個“錯誤偵測與回報機制”，其目的就是讓我們能夠檢測網路的連線狀況﹐也能確保連線的準確性。當路由器在處理一個數據包的過程中發生了意外，可以通過ICMP像數據包的源端報告有關事件。
其功能主要有：偵測遠端主機是否存在，建立及維護路由資料，重導資料傳送路徑（ICMP重定向），資料流量控制。ICMP在溝通之中，主要是透過不同的類別(Type)與代碼(Code) 讓機器來識別不同的連線狀況。
ICMP 是個非常有用的協議﹐尤其是當我們要對網路連接狀況進行判斷的時候。
ICMP 協議應用在許多網路管理命令中，下面以 ping 和 tracert 命令為例詳細介紹 ICMP 協議的應用。
（1） ping 命令使用 ICMP 回送請求和應答報文
在網路可達性測試中使用的分組網間探測命令 ping 能產生 ICMP 回送請求和應答報文。目的主機收到 ICMP 回送請求報文後立刻回送應答報文，若源主機能收到 ICMP 回送應答報文，則說明到達該主機的網路正常。
（2）路由分析診斷程序 tracert 使用了 ICMP時間超過報文
tracert 命令主要用來顯示數據包到達目的主機所經過的路徑。通過執行一個 tracert 到對方主機的命令，返回數據包到達目的主機所經歷的路徑詳細信息，並顯示每個路徑所消耗的時間。
ICMP協議對於網路安全具有極其重要的意義。ICMP協議本身的特點決定了它非常容易被用於攻擊網路上的路由器和主機。例如，在1999年8月海信集團“懸賞”50萬元人民幣測試防火牆的過程中，其防火牆遭受到的ICMP攻擊達334050次之多，占整個攻擊總數的90%以上！可見，ICMP的重要性絕不可以忽視！
比如，可以利用操作系統規定的ICMP數據包最大尺寸不超過64KB這一規定，向主機發起“Ping of Death”（死亡之Ping）攻擊。“Ping of Death”攻擊的原理是：如果ICMP數據包的尺寸超過64KB上限時，主機就會出現內存分配錯誤，導致TCP/IP堆棧崩潰，致使主機死機。（操作系統已經取消了發送ICMP數據包的大小的限制，解決了這個漏洞）
此外，向目標主機長時間、連續、大量地發送ICMP數據包，也會最終使系統癱瘓。大量的ICMP數據包會形成“ICMP風暴”，使得目標主機耗費大量的CPU資源處理，疲於奔命。
雖然ICMP協議給黑客以可乘之機，但是ICMP攻擊也並非無葯可醫。只要在日常網路管理中未雨綢繆，提前做好準備，就可以有效地避免ICMP攻擊造成的損失。
對於“Ping of Death”攻擊，可以採取兩種方法進行防範：第一種方法是在路由器上對ICMP數據包進行帶寬限制，將ICMP佔用的帶寬控制在一定的範圍內，這樣即使有ICMP攻擊，它所佔用的帶寬也是非常有限的，對整個網路的影響非常少；第二種方法就是在主機上設置ICMP數據包的處理規則，最好是設定拒絕所有的ICMP數據包。
設置ICMP數據包處理規則的方法也有兩種，一種是在操作系統上設置包過濾，另一種是在主機上安裝防火牆。通過安裝防火牆抵禦攻擊的方法如下：
選擇合適的防火牆
有效防止ICMP攻擊，防火牆應該具有狀態檢測、細緻的數據包完整性檢查和很好的過濾規則控制功能。
狀態檢測防火牆通過跟蹤它的連接狀態，動態允許外出數據包的響應信息進入防火牆所保護的網路。例如，狀態檢測防火牆可以記錄一個出去的 PING（ICMP Echo Request），在接下來的一個確定的時間段內，允許目標主機響應的ICMP Echo Reply直接發送給前面發出了PING命令的IP，除此之外的其他ICMP Echo Reply消息都會被防火牆阻止。與此形成對比的是，包過濾類型的防火牆允許所有的ICMP Echo Reply消息進入防火牆所保護的網路了。許多路由器和基於Linux內核2.2或以前版本的防火牆系統，都屬於包過濾型，用戶應該避免選擇這些系統。
新的攻擊不斷出現，防火牆僅僅能夠防止已知攻擊是遠遠不夠的。通過對所有數據包進行細緻分析，刪除非法的數據包，防火牆可以防止已知和未知的 DoS攻擊。這就要求防火牆能夠進行數據包一致性檢查。安全策略需要針對ICMP進行細緻的控制。因此防火牆應該允許對ICMP類型、代碼和包大小進行過濾，並且能夠控制連接時間和ICMP包的生成速率。
配置防火牆以預防攻擊
一旦選擇了合適的防火牆，用戶應該配置一個合理的安全策略。以下是被普遍認可的防火牆安全配置慣例，可供管理員在系統安全性和易用性之間作出權衡。
防火牆應該強制執行一個預設的拒絕策略。除了出站的ICMP Echo Request、出站的ICMP Source Quench、進站的TTL Exceeded和進站的ICMP Destination Unreachable之外，所有的ICMP消息類型都應該被阻止。
已經定義的ICMP消息類型大約由10多種，每種ICMP數據類型都被封裝在一個IP數據包中。主要的ICMP消息類型包括一下幾種。
響應請求
我們日常使用最多的ping，就是響應請求（Type=8）和應答（Code=0），一台主機向一個節點發送一個Type=8的ICMP報文，如果途中沒有異常（例如被路由器丟棄、目標不回應ICMP或傳輸失敗），則目標返回Type=0的ICMP報文，說明這台主機存在，更詳細的tracert通過計算ICMP報文通過的節點來確定主機與目標之間的網路距離。
目標不可到達、源抑制和超時報文
這三種報文的格式是一樣的，目標不可到達報文（Type=3）在路由器或主機不能傳遞數據報時使用，例如我們要連接對方一個不存在的系統埠（埠號小於1024）時，將返回Type=3、Code=3的ICMP報文，它要告訴我們：“嘿，別連接了，我不在家的！”，常見的不可到達類型還有網路不可到達（Code=0）、主機不可到達（Code=1）、協議不可到達（Code=2）等。源抑制則充當一個控制流量的角色，它通知主機減少數據報流量，由於ICMP沒有恢復傳輸的報文，所以只要停止該報文，主機就會逐漸恢復傳輸速率。最後，無連接方式網路的問題就是數據報會丟失，或者長時間在網路遊盪而找不到目標，或者擁塞導致主機在規定時間內無法重組數據報分段，這時就要觸發ICMP超時報文的產生。超時報文的代碼域有兩種取值：Code=0表示傳輸超時，Code=1表示重組分段超時。
時間戳
時間戳請求報文（Type=13）和時間戳應答報文（Type=14）用於測試兩台主機之間數據報來回一次的傳輸時間。傳輸時，主機填充原始時間戳，接收方收到請求后填充接收時間戳后以Type=14的報文格式返回，發送方計算這個時間差。一些系統不響應這種報文。
全部消息類型
下表顯示了完整的ICMP類型：
| 表1 ICMP類型 | ||||
|---|---|---|---|---|
| TYPE | CODE | Description | Query | Error |
| Echo Reply——回顯應答（Ping應答） | x | |||
| 3 | Network Unreachable——網路不可達 | x | ||
| 3 | 1 | Host Unreachable——主機不可達 | x | |
| 3 | 2 | Protocol Unreachable——協議不可達 | x | |
| 3 | 3 | Port Unreachable——埠不可達 | x | |
| 3 | 4 | Fragmentation needed but no frag. bit set——需要進行分片但設置不分片比特 | x | |
| 3 | 5 | Source routing failed——源站選路失敗 | x | |
| 3 | 6 | Destination network unknown——目的網路未知 | x | |
| 3 | 7 | Destination host unknown——目的主機未知 | x | |
| 3 | 8 | Source host isolated (obsolete)——源主機被隔離（作廢不用） | x | |
| 3 | 9 | Destination network administratively prohibited——目的網路被強制禁止 | x | |
| 3 | 10 | Destination host administratively prohibited——目的主機被強制禁止 | x | |
| 3 | 11 | Network unreachable for TOS——由於服務類型TOS，網路不可達 | x | |
| 3 | 12 | Host unreachable for TOS——由於服務類型TOS，主機不可達 | x | |
| 3 | 13 | Communication administratively prohibited by filtering——由於過濾，通信被強制禁止 | x | |
| 3 | 14 | Host precedence violation——主機越權 | x | |
| 3 | 15 | Precedence cutoff in effect——優先中止生效 | x | |
| 4 | Source quench——源端被關閉（基本流控制） | |||
| 5 | Redirect for network——對網路重定向 | |||
| 5 | 1 | Redirect for host——對主機重定向 | ||
| 5 | 2 | Redirect for TOS and network——對服務類型和網路重定向 | ||
| 5 | 3 | Redirect for TOS and host——對服務類型和主機重定向 | ||
| 8 | Echo request——回顯請求（Ping請求） | x | ||
| 9 | Router advertisement——路由器通告 | |||
| 10 | Route solicitation——路由器請求 | |||
| 11 | TTL equals 0 during transit——傳輸期間生存時間為0 | x | ||
| 11 | 1 | TTL equals 0 during reassembly——在數據報組裝期間生存時間為0 | x | |
| 12 | IP header bad (catchall error)——壞的IP首部（包括各種差錯） | x | ||
| 12 | 1 | Required options missing——缺少必需的選項 | x | |
| 13 | Timestamp request (obsolete)——時間戳請求（作廢不用） | x | ||
| 14 | Timestamp reply (obsolete)——時間戳應答（作廢不用） | x | ||
| 15 | Information request (obsolete)——信息請求（作廢不用） | x | ||
| 16 | Information reply (obsolete)——信息應答（作廢不用） | x | ||
| 17 | Address mask request——地址掩碼請求 | x | ||
| 18 | Address mask reply——地址掩碼應答 | |||
