網絡網絡層之(6)ICMPv4協議
Author: Once Day Date: 2024年6月2日
一位熱衷于Linux學習和開發的菜鳥，試圖譜寫一場冒險之旅，也許終點只是一場白日夢…
漫漫長路，有人對你微笑過嘛…
全系列文章可參考專欄: 通信網絡技術_Once-Day的博客-CSDN博客。
參考文章:
- 《TCP/IP詳解卷一》
- RFC 792 - Internet Control Message Protocol (ietf.org)
- RFC 4884 - Extended ICMP to Support Multi-Part Messages (ietf.org)
- TCP/IP 筆記 - ICMPv4和ICMPv6 : Internet控制報文協議 - 野獸’ - 博客園 (cnblogs.com)
- 5.ICMPv4協議分析與實踐_icmp v4-CSDN博客
- ICMP Echo Request/Reply消息格式 - IP報文格式大全(html) - 華為 (huawei.com)
- TCP/IP卷一:44—ICMP之（ICMP(控制報文協議)簡介、ICMPv4、ICMPv6報文格式/報文處理）_大量的icmpv6報文-CSDN博客
文章目錄
- 網絡網絡層之(6)ICMPv4協議
- 1. 概述
- 1.1 ICMPv4介紹
- 1.2 相關RFC文檔
- 2. 報文格式
- 2.1 ICMPv4首部
- 2.2 ICMPv4報文類型
- 2.3 ICMPv4常見代碼
- 2.4 ICMPv4差錯報文限制
- 2.5 ICMPv4目的不可達(類型3)
- 2.6 ICMPv4重定向(類型5)
- 2.7 ICMPv4超時(類型11)
- 2.8 ICMPv4參數問題(類型12)
- 2.9 ICMPv4回顯請求/應答(類型0/8)
- 2.10 ICMPv4路由器請求和通告(類型9/10)
- 3. ICMP攻擊
- 3.1 洪泛攻擊
1. 概述
1.1 ICMPv4介紹
ICMPv4是IPv4協議族中的一個重要協議，它主要用于傳遞網絡層的控制和錯誤信息。與IP數據報不同，ICMPv4報文并不直接用于傳輸用戶數據，而是輔助IP協議更好地完成數據傳輸任務。
ICMPv4報文封裝在IP數據報中進行傳輸。報文主要由兩部分組成:報頭和數據部分。報頭包含了類型、代碼和校驗和等重要信息，用于識別報文的類型和檢測傳輸錯誤，數據部分攜帶了與具體報文類型相關的信息。
根據功能，ICMPv4報文可以分為兩大類：差錯報告報文和查詢報文。
(1) 差錯報告報文用于告知源主機在數據傳輸過程中遇到的各種錯誤情況:
- 目標不可達，數據包無法送達目標地址。
- 超時，數據包在網絡中存在的時間超過限制。
- 重定向，通知源主機有更優的路由路徑。
（2) 查詢報文則用于網絡探測和管理:
- 回顯請求和應答，對應ping工具,用于連通性測試。
- 時間戳請求和應答，用于進行時間同步。
常用的網絡診斷工具如ping、traceroute都是基于ICMPv4實現的，可以利用它們快速判斷網絡狀態，定位故障點。
1.2 相關RFC文檔
以下是與ICMPv4相關的主要RFC文檔列表:
- RFC 792 - Internet Control Message Protocol (1981)，定義了ICMPv4協議的基本規范,包括報文格式、類型和代碼等。
- RFC 950 - Internet Standard Subnetting Procedure (1985)，引入了子網編址的概念，通過子網掩碼實現IP地址的劃分。
- RFC 1122 - Requirements for Internet Hosts – Communication Layers (1989)，定義了互聯網主機在實現TCP/IP協議棧時需要遵循的各項要求。
- RFC 1191 - Path MTU Discovery (1990)，提出了路徑MTU發現機制，用于確定到達目標主機路徑上的最小MTU。
- RFC 1256 - ICMP Router Discovery Messages (1991)，引入了ICMPv4路由器發現報文，用于主機動態地發現本地網絡上的路由器。
- RFC 1393 - Traceroute Using an IP Option (1993)，描述了使用IP選項實現traceroute的方法。
- RFC 1812 - Requirements for IP Version 4 Routers (1995)，定義了IPv4路由器的各項需求，其中包括對ICMPv4的處理要求。
- RFC 2463 - Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (1998)，定義了ICMPv6協議，作為IPv6協議族中與ICMPv4相對應的協議。
- RFC 4443 - Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (2006)，更新了ICMPv6協議的規范，取代了RFC 2463。
- RFC 4884 - Extended ICMP to Support Multi-Part Messages (2007)，擴展了ICMPv4和ICMPv6,支持多部分消息，增加了對大型診斷消息的傳輸能力。
- RFC 5837 - ICMP Extensions for Multiprotocol Label Switching (2010)，定義了用于MPLS的ICMPv4和ICMPv6擴展，支持MPLS網絡的錯誤報告和診斷。
- RFC 5508 - NAT Behavioral Requirements for ICMP (2009)，定義了網絡地址轉換(NAT)設備處理ICMPv4報文的行為要求，以保證NAT環境下ICMP的正確工作。
2. 報文格式
2.1 ICMPv4首部
ICMPv4報文格式由類型、代碼和校驗和三個固定字段組成，后面緊跟與具體報文類型相關的數據部分。
字段說明:
-
IPv4報文首部協議(proto)字段值為1，表示其攜帶了ICMPv4報文數據。
-
Type(類型，8位)標識ICMPv4報文的類型，不同的類型對應不同的報文格式和用途，如0表示回顯應答，8表示回顯請求等。
-
Code(代碼，8位)與類型字段一起標識ICMPv4報文的具體含義，同一類型的報文可能有多個代碼值，表示不同的錯誤原因或附加信息。
-
Checksum(校驗和，16位)用于檢測報文在傳輸過程中是否出現錯誤，計算時需要將校驗和字段置零，然后對整個ICMP報文進行16位二進制反碼求和。
-
Message Body(消息體，長度可變)攜帶與具體報文類型相關的數據，如錯誤信息、回顯數據等，不同類型的報文有不同的消息體格式。
2.2 ICMPv4報文類型
常見的ICMPv4報文類型如下:
| 類型 | 名稱 | RFC文檔 | 差錯or查詢 | 用途描述 |
|---|---|---|---|---|
| 0 | Echo Reply | RFC792 | 查詢 | 響應Echo Request，用于確認連通性和RTT測量 |
| 3 | Destination Unreachable | RFC792 | 差錯 | 通知源主機目標不可達，具體原因在Code字段中說明 |
| 4 | Source Quench | RFC792 | 差錯 | 通知源主機降低發送速率，避免擁塞(已廢棄) |
| 5 | Redirect | RFC792 | 差錯 | 通知源主機有更好的路由，優化路由路徑 |
| 8 | Echo Request | RFC792 | 查詢 | 請求目標主機回應，用于確認連通性和RTT測量 |
| 9 | Router Advertisement | RFC1256 | 查詢 | 路由器定期或應請求發送,公告自身作為默認網關的可用性 |
| 10 | Router Solicitation | RFC1256 | 查詢 | 主機發送該報文,請求路由器立即發送Router Advertisement |
| 11 | Time Exceeded | RFC792 | 差錯 | 當TTL耗盡或分片重組超時時，告知源主機 |
| 12 | Parameter Problem | RFC792 | 差錯 | IP首部存在問題導致無法處理時，告知源主機 |
| 13 | Timestamp | RFC792 | 查詢 | 請求目標主機回送時間戳，用于時間同步(已廢棄) |
| 14 | Timestamp Reply | RFC792 | 查詢 | Timestamp查詢的應答報文(已廢棄) |
| 15 | Information Request | RFC792 | 查詢 | 請求目標主機提供IP地址信息(已廢棄) |
| 16 | Information Reply | RFC792 | 查詢 | Information Request的應答報文(已廢棄) |
| 17 | Address Mask Request | RFC1256 | 查詢 | 請求子網掩碼信息(已廢棄) |
| 18 | Address Mask Reply | RFC1256 | 查詢 | Address Mask Request的應答報文(已廢棄) |
類型3、4、5、11、12屬于差錯報文，用于通知源主機存在的問題。
類型0、8、13、14、15、16屬于查詢報文，用于診斷連通性、測量時延等。
有些類型如Source Quench、Timestamp等已經被廢棄不再使用。
2.3 ICMPv4常見代碼
ICMPv4中類型3、5、9、11、12的常見代碼號如下:
| 類型 | 代碼 | 名稱 | 描述 |
|---|---|---|---|
| 3 | 0 | Net Unreachable | 目標網絡不可達 |
| 3 | 1 | Host Unreachable | 目標主機不可達 |
| 3 | 2 | Protocol Unreachable | 目標協議不可達 |
| 3 | 3 | Port Unreachable | 目標端口不可達 |
| 3 | 4 | Fragmentation Needed and Don’t Fragment was Set | 需要分片但設置了不分片位 |
| 3 | 5 | Source Route Failed | 源路由失敗 |
| 3 | 6 | Destination Network Unknown | 目標網絡未知 |
| 3 | 7 | Destination Host Unknown | 目標主機未知 |
| 3 | 8 | Source Host Isolated | 源主機被隔離 |
| 3 | 9 | Communication with Destination Network is Administratively Prohibited | 與目標網絡的通信被管理員禁止 |
| 3 | 10 | Communication with Destination Host is Administratively Prohibited | 與目標主機的通信被管理員禁止 |
| 3 | 11 | Destination Network Unreachable for Type of Service | 對于此類服務,目標網絡不可達 |
| 3 | 12 | Destination Host Unreachable for Type of Service | 對于此類服務,目標主機不可達 |
| 3 | 13 | 管理禁止通信 | 被過濾策略禁止的通信 |
| 3 | 14 | 違反主機優先級 | src/dest/port不準許的優先級 |
| 3 | 15 | 優先級終止生效 | 在最小Tos之下(RFC1812) |
| 5 | 0 | Redirect Datagram for the Network | 對特定網絡重定向 |
| 5 | 1 | Redirect Datagram for the Host | 對特定主機重定向 |
| 5 | 2 | Redirect Datagram for the Type of Service and Network | 對特定類型服務和網絡重定向 |
| 5 | 3 | Redirect Datagram for the Type of Service and Host | 對特定類型服務和主機重定向 |
| 9 | 0 | Normal Router Advertisement | 正常路由器通告 |
| 9 | 16 | Does Not Route Common Traffic | 不路由普通流量 |
| 11 | 0 | Time to Live exceeded in Transit | 傳輸過程中超過生存時間 |
| 11 | 1 | Fragment Reassembly Time Exceeded | 分片重組超時 |
| 12 | 0 | Pointer indicates the error | 參數問題,錯誤由指針指出 |
| 12 | 1 | Missing a Required Option | 缺少必需的選項 |
| 12 | 2 | Bad Length | 長度錯誤 |
2.4 ICMPv4差錯報文限制
在某些情況下，網絡設備不會產生ICMPv4差錯報文，以避免網絡擁塞、安全問題或無用的錯誤報告：
-
廣播或組播地址，當IP數據報的目標地址是廣播或組播地址時，通常不會產生ICMPv4差錯報文，如"目標不可達"或"超時"等。
-
分片，當接收到IP分片時，如果出現錯誤(如超時、目標不可達等)，通常不會為每個分片生成單獨的ICMPv4差錯報文，而是等到全部分片到達后再生成一個差錯報文。
-
ICMP差錯報文，為了避免無限循環，當一個ICMP差錯報文觸發另一個差錯時，通常不會再生成新的ICMP差錯報文。
-
源地址不可達，當源IP地址不可達時(零地址、環回地址、廣播地址或組播地址)，通常不會生成ICMPv4差錯報文，以避免網絡擁塞和廣播風暴。
-
作為鏈路層廣播的數據報，避免產生大量的差錯報文。
-
安全策略，根據網絡管理員的安全策略，某些類型的ICMPv4報文可能會被禁用或過濾，如ping請求、重定向等。
2.5 ICMPv4目的不可達(類型3)
ICMPv4的目的不可達報文(Destination Unreachable Message)是類型3的差錯報文，用于在數據包無法送達目標時，由路由器或主機向源端發送，告知其發生了不可達的情況。
RFC 792報文的格式如下:
Destination Unreachable Message(RFC 792)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| unused |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Internet Header + 64 bits of Original Data Datagram |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
字段說明如下:
- Type(8位)，值為3，表示目的不可達報文。
- Code(8位)，表示不可達的具體原因，取值范圍0~15。
- Checksum(16位)，ICMPv4頭部和數據部分的校驗和。
- unused(32位)，未使用字段，必須置0。
- Internet Header + 64 bits of Original Data Datagram，數據部分，包含引發差錯報文的原始IP數據報的IP頭部和至少64位數據。在不超過576字節的情況下，應盡量的多包涵原始數據。
RFC 4884報文格式如下(支持擴展數據結構):
Destination Unreachable Message(RFC 4884)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| unused | Length | Next-Hop MTU* |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Internet Header + leading octets of original datagram || || // || |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| ICMP擴展頭部以及零個或多個關聯對象 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type、Code、Checksum、unused字段與原有格式相同。
- Original IPv4 Header + data，數據部分，包含引發差錯報文的原始IP數據報的IP頭部和數據。與原有格式不同，該字段長度可變，不再限于64位，至少應包含128字節。
- Length，指示Original IPv4 Header + data字段的長度，單位為4字節(IPv4和IPv6單位不一樣)。
- 代碼為4(報文太大)時，
Next-Hop MTU字段用于記錄下一跳的MTU，并被PMTUD使用。
當路由器或主機無法轉發或處理接收到的數據包時，就會向源端發送一個相應的目的不可達報文。源端收到該報文后，可以根據Code值判斷具體的不可達原因，并結合數據部分攜帶的原始報文信息進行問題的定位和調整。
Code字段表示不可達的具體原因，常見取值如下:
- Net Unreachable(0)，網絡不可達。
- Host Unreachable(1)，主機不可達。
- Protocol Unreachable(2)，協議不可達。
- Port Unreachable(3)，端口不可達。
- Fragmentation Needed and Don’t Fragment was Set(4)，需要分片但禁止分片。
- Source Route Failed(5)，源路由失敗。
- Destination Network Unknown(6)，目標網絡未知。
- Destination Host Unknown(7)，目標主機未知。
- Source Host Isolated(8)，源主機被隔離。
- Communication with Destination Network Administratively Prohibited(9)，目標網絡通信被管理員禁止。
- Communication with Destination Host Administratively Prohibited(10)，目標主機通信被管理員禁止。
- Destination Network Unreachable for Type of Service(11)，對于當前服務類型，目標網絡不可達。
- Destination Host Unreachable for Type of Service(12)，對于當前服務類型，目標主機不可達。
數據部分包含了引發該差錯報文的原始IP數據報的IP頭部和前64位數據，用于幫助源端定位和診斷問題。如果原始數據報小于64位,則截斷后填充0。
ICMPv4定義了"Packet Too Big"(PTB)報文，用于在網絡中發現和調整數據包的大小，以適應不同鏈路的MTU限制，這種機制稱為"Path MTU Discovery"(PMTUD)，對于優化網絡性能和避免分片非常重要。
在ICMPv4中，PTB報文屬于目的不可達報文(類型3)的一種特例，使用代碼4表示。當一個路由器收到一個數據包，其大小超過了下一跳鏈路的MTU，且該數據包設置了"Don’t Fragment"(DF)標志時，路由器會丟棄該數據包，并向源主機發送一個PTB報文。
PTB報文的格式與普通的目的不可達報文類似，但在未使用字段中攜帶了下一跳鏈路的MTU值。源主機收到PTB報文后，會將該報文中指示的MTU值作為目標地址的Path MTU(PMTU)，并據此調整后續數據包的大小。
如果源主機無法縮減數據包大小，則會中止發送并向上層應用報告錯誤。
2.6 ICMPv4重定向(類型5)
ICMPv4的重定向報文(Redirect Message)是一種特殊的ICMP報文，用于通知主機更優的路由路徑。當主機發送數據包時，如果路由器發現主機使用了次優的路由路徑，則會向主機發送重定向報文，建議主機更新其路由表，以便后續數據包可以直接發送到更優的下一跳路由器。
Redirect Message(5)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Gateway Internet Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Internet Header + 64 bits of Original Data Datagram |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Type(8位)，值為5，表示重定向報文。
- Code(8位)，表示重定向的具體原因，取值范圍0~3。
- Checksum(16位)，ICMP報文的校驗和。
- Gateway Internet Address(32位)，建議的更優下一跳路由器的IP地址。
- Internet Header + 64 bits of Original Data Datagram，觸發重定向報文的原始IP數據報的IP頭部和前64位數據。
重定向類型(Code):
- Network Redirect(0)，表示對特定網絡的重定向。
- Host Redirect(1)，表示對特定主機的重定向。
- Network Redirect for TOS(2)，表示對特定網絡和服務類型(TOS)的重定向。
- Host Redirect for TOS(3)，表示對特定主機和服務類型(TOS)的重定向。
2.7 ICMPv4超時(類型11)
ICMPv4的超時報文(Time Exceeded Message)是一種重要的差錯報文，用于通知源主機在數據包傳輸過程中發生了超時。這種超時通常分為兩種情況：
- 傳輸過程中超過了IP頭部中的生存時間(TTL)。
- 分片重組超時，相當于整個數據報被丟棄。
下面是ICMPv4超時報文的格式:
Time Exceeded Message(11)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| unused |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Internet Header + 64 bits of Original Data Datagram |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
字段說明:
- Type(8位)，值為11，表示超時報文。
- Code(8位)，表示超時的具體原因，取值范圍0~1。
- Checksum(16位)，ICMP報文的校驗和。
- unused(32位)，未使用字段，置0。
- Internet Header + 64 bits of Original Data Datagram，觸發超時報文的原始IP數據報的IP頭部和前64位數據。
超時代碼(Code):
- Time to Live exceeded in Transit(0)，表示數據包在傳輸過程中超過了IP頭部中的TTL值。每經過一個路由器，IP頭部的TTL值就會減1，當TTL減為0時，路由器會丟棄該數據包，并向源主機發送一個Code 0的超時報文。
- Fragment Reassembly Time Exceeded(1)，表示分片重組超時。當一個數據包被分片傳輸時，目標主機需要在一定時間內收到所有分片并重組，如果超過了設定的時間閾值，就會觸發Code 1的超時報文。
超時報文用于通知源主機在數據包傳輸過程中發生了異常，幫助源主機診斷和調試網絡問題:
- Code 0的超時報文通常表明網絡路徑過長或存在路由環路，源主機可以據此調整TTL值或檢查路由配置。Code 0的超時報文也被用于traceroute等網絡診斷工具，以發現網絡路徑上的路由器。
- Code 1的超時報文提示分片重組過程出現了問題，可能是因為網絡擁塞、分片丟失或目標主機資源不足等原因。
2.8 ICMPv4參數問題(類型12)
ICMPv4的參數問題報文(Parameter Problem Message)是一種重要的差錯報文，用于通知源主機在數據包的首部中發現了錯誤或不完整的信息。當路由器或主機在處理數據包時檢測到頭部字段存在問題,無法正確解析或處理時,就會向源主機發送參數問題報文。
Parameter Problem Message(12)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Pointer | unused |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Internet Header + 64 bits of Original Data Datagram |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
字段說明:
- Type(8位)，值為12，表示參數問題報文。
- Code(8位)，表示錯誤的具體原因，取值范圍0~2。
- Checksum(16位)，ICMP報文的校驗和。
- Pointer(8位)，指向數據包首部中發生錯誤的字節位置。
- unused(24位)，未使用字段，置0。
- Internet Header + 64 bits of Original Data Datagram，觸發參數問題報文的原始IP數據報的IP頭部和前64位數據。
錯誤代碼(Code):
- Pointer indicates the error(0)，表示Pointer字段指向了數據包首部中發生錯誤的具體位置。
- Missing a Required Option(1)，表示數據包缺少了某個必需的選項。
- Bad Length(2)，表示數據包的長度存在問題，可能是總長度與首部長度和數據長度之和不一致，或者超過了網絡的MTU限制。
參數問題報文用于通知源主機在發送數據包時出現了首部錯誤，幫助源主機診斷和調試網絡問題：
- Code 0的參數問題報文通常表明數據包的某個首部字段存在無法識別或不合法的值，Pointer字段會指明具體的錯誤位置，源主機可以據此檢查和修正數據包的構造過程。
- Code 1的參數問題報文提示數據包缺少了某個必需的首部選項，例如安全選項、源路由選項等，源主機需要檢查上層協議和應用的設置，確保包含所有必需的選項。
- Code 2的參數問題報文表示數據包的長度字段存在問題，可能是上層協議計算錯誤或者數據包在傳輸過程中被截斷，源主機需要檢查數據包的封裝和傳輸過程。
2.9 ICMPv4回顯請求/應答(類型0/8)
ICMP回顯請求和應答是我們日常網絡應用中最常見的兩種ICMP報文。它們構成了Ping程序的基礎,讓我們能夠方便地檢測網絡的連通性和延遲。
Echo(8) or Echo Reply(0) Message0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Identifier | Sequence Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Data ...+-+-+-+-+-
一個完整的ICMP回顯請求或應答報文由以下幾個字段依次組成:
- 類型(Type，8位)，回顯請求的類型值為8，而回顯應答的類型值則為0。
- 代碼(Code，8位)，對于回顯請求和應答報文，代碼字段的值通常都為0，表示這是一個標準的查詢和響應過程。
- 校驗和(Checksum，16位)，ICMP報文的前4個字節和數據部分一起被用于計算校驗和。
- 標識符(Identifier)和序號(Sequence Number)，這兩個字段各占2字節，它們的值由發送方任意指定，但在請求和應答報文中必須保持一致。
- 數據部分，在回顯請求和應答中，這部分內容是完全一樣的。數據的具體內容由請求方定義，應答方只需原封不動地返回即可。
最常見的應用莫過于Ping程序了。當我們在命令行中輸入"ping 目標IP地址"時，源主機就會構造一系列ICMP回顯請求報文，填入適當的標識符和序號，然后連續發送給目標主機。
目標主機收到請求后，會提取報文中的標識符和序號，構造對應的ICMP回顯應答報文，再發送回源主機。源主機根據收到的ICMP應答，計算往返時間和丟包率，評估與目標主機之間的網絡質量。
另一個常見的應用是traceroute程序，它通過逐步增加IP包的生存時間(TTL)，結合ICMP超時錯誤和到達目標時的ICMP端口不可達錯誤，一跳一跳地探測到目標主機的網絡路徑。
2.10 ICMPv4路由器請求和通告(類型9/10)
ICMPv4 路由器請求和通告報文幫助主機自動發現附近的路由器，獲取必要的配置信息。
路由器請求報文的ICMP類型值為 9，當一臺主機希望自動獲取路由器的信息時，它會在本地網絡上廣播一個路由器請求報文。這個報文的目標地址通常為受限廣播地址255.255.255.255或本地網段的廣播地址。
路由器請求報文的格式非常簡潔，除了公共的 ICMP 報頭外，沒有其他特殊字段：
ICMP Router Solicitation Message(9)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Reserved |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
路由器通告報文的ICMP類型值為10，當路由器收到一個路由器請求報文或者自身的通告時間間隔到期時，它就會主動向本地網絡發送一個路由器通告報文。這個報文通常以組播的形式發送，目標地址為 224.0.0.1。
ICMP Router Advertisement Message(10)0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Num Addrs |Addr Entry Size| Lifetime |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Router Address[1] |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Preference Level[1] |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Router Address[2] |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Preference Level[2] |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| . || . || . |
相比請求報文，通告報文的內容就豐富多了，除了ICMP報頭，它還包含以下重要信息:
- 地址數(Num Addrs)，表示通告報文中包含的路由地址條目數量，每個塊包含一個IPv4地址和相應的優先水平(Preference level)。
- 地址條目大小(Addr Entry Size)，說明每個地址條目的大小，以 32 位字為單位。
- 生存周期(Lifetime)，告知主機在收到下一個通告報文之前，本報文中的信息有效的時間，單位為秒。
- 路由器地址(Router Address)，路由器擁有的一個或多個 IP 地址。
- 優先水平(Preference level)，一個32位的有符號二進制補碼整數，其值越大代表優先級越高。默認的優先水平是0，特殊值0x80000000表示這個地址不應該作為有效的默認路由。
主機收到路由器通告報文后，會提取出路由器的IP地址，并根據報文中的生存時間設置老化定時器。在定時器到期之前，主機就可以使用通告的路由器地址作為默認網關，將目標不在本地網段的數據報文轉發給路由器處理。
3. ICMP攻擊
3.1 洪泛攻擊
ICMP協議作為網絡層的重要協議之一，在網絡管理、故障診斷等方面發揮著關鍵作用。然而，由于其設計的開放性和靈活性，ICMP也常常被惡意利用，成為網絡攻擊的工具。
(1) ICMP洪泛攻擊(ICMP Flood)是一種典型的拒絕服務(DoS)攻擊方式。攻擊者通過向目標主機或網絡發送大量的ICMP請求報文(如Echo請求、時間戳請求等)，耗盡目標的網絡帶寬和系統資源，導致其無法正常提供服務。
攻擊者通常采用偽造源IP地址的方式，隱藏自己的真實身份，并利用僵尸網絡放大攻擊流量。當大量的ICMP請求同時到達目標時，網絡設備的處理能力和帶寬很快被耗盡，合法用戶的請求無法得到及時響應，網絡服務質量嚴重下降。
(2) **ICMP路由重定向攻擊(ICMP Redirect)**用于路由器通知主機更優的路由路徑。然而，惡意攻擊者可以偽造ICMP重定向報文，引誘主機將數據報文發送到錯誤的路由器或惡意主機，造成數據泄露或中間人攻擊。
攻擊者通常在與目標主機相同的本地網絡內，偽裝成合法的路由器，向目標主機發送虛假的ICMP重定向報文。如果主機沒有對報文來源進行嚴格驗證，就可能誤認為攻擊者是可信的路由器，從而將敏感數據發送給攻擊者，或者陷入惡意主機設置的"陷阱"。
(3) **ICMP目的不可達攻擊(ICMP Destination Unreachable)**用于告知源主機目標主機或端口無法到達。攻擊者可以利用這一機制，向目標主機發送偽造的目的不可達報文，導致目標主機錯誤地中斷與合法主機的通信。
例如，攻擊者監聽到目標主機與某個合法服務器之間的通信后，就偽造一個源IP為該服務器、目標IP為目標主機的ICMP目的不可達報文，并聲稱服務器的某個端口不可達。目標主機收到報文后，可能會誤認為服務器主動斷開了連接，從而中斷與服務器的通信。當攻擊者持續發送這類報文時，目標主機與合法服務器之間的通信就會不斷受到干擾。
(4) Ping of Death攻擊，早期的一些操作系統和網絡設備在處理超大的ICMP回顯請求報文時存在緩沖區溢出漏洞。攻擊者利用這一漏洞，構造一個超過最大允許長度(65535字節)的ICMP請求報文，在目標主機上引發系統崩潰或重啟，造成拒絕服務。
為了防范ICMP報文攻擊，網絡管理員可以采取以下措施:
- 在網絡邊界和主機上啟用ICMP報文過濾，僅允許必要的ICMP報文通過。
- 對ICMP報文進行速率限制，避免少量主機占用過多網絡資源。
- 對ICMP報文的合法性進行驗證，丟棄可疑的偽造報文。
- 及時更新系統和設備，修復已知的ICMP相關漏洞。
- 部署抗DDoS設備，實時監測和清洗惡意ICMP流量。
ICMP報文攻擊是網絡安全領域的一大挑戰，攻擊者利用ICMP的開放性和靈活性，通過多種手段破壞網絡通信和服務。
Once Day
也信美人終作土，不堪幽夢太匆匆......
如果這篇文章為您帶來了幫助或啟發，不妨點個贊👍和關注，再加上一個小小的收藏?！
(｡???｡)感謝您的閱讀與支持~~~
