本節書摘來自異步社群《Wireshark資料包分析實戰(第2版)》一書中的第6章6.5節網際網路控制消息協定,作者【美】Chris Sanders,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
6.5 網際網路控制消息協定
網際網路控制消息協定(Internet Control Message Protocol, ICMP)是TCP/IP協定族中的一個效用協定,負責提供在TCP/IP網絡上裝置、服務以及路由器可用性的資訊。大多數網絡檢修技巧和工具都是基于常用的ICMP消息類型。ICMP在RFC792中定義。
6.5.1 ICMP頭
ICMP是IP的一部分并依賴IP來傳遞消息。ICMP頭相對較小并根據用途而改變。如圖6-29所示,ICMP頭包含了以下幾個域。

類型(Type):ICMP消息基于RFC規範的類型或分類。
代碼(Code):ICMP消息基于RFC規範的子類型。
校驗和(Checksum):用來保證ICMP頭和資料在抵達目的地時的完整性。
可變域(Variable):依賴于類型和代碼域的部分。
6.5.2 ICMP類型和消息
正如剛才所說,ICMP資料包的結構取決于它由Type和Code域中的值所定義的用途。
你可以将ICMP的類型域作為資料包的分類,而Code域作為它的子類。舉例來說,Type域的值為3時意味着“目标不可達”。但隻有這個資訊可能不足以發現問題,當如果資料包在Code域中指明值為3,也就是“端口不可達”時,你就可以知道這應該是你試圖進行通信的端口的問題。
注意
6.5.3 Echo請求與響應
ICMP因為其ping功能而聲名大噪。ping用來檢測一個裝置的可連接配接性。大多數資訊技術專家都會對ping很熟悉。
在指令行中輸入ping ,其中将替換為你網絡上的一個實際IP位址,就可以使用ping了。如果目标裝置線上,你的計算機有到達目标的通路,并且沒有防火牆隔離通信的話,你将能夠看到對ping指令的響應。
在圖6-30所示的例子中,給出了4個成功顯示了大小、RTT和TTL的響應。Windows還會提供一個總結資訊,告訴你有多少資料包被發送、接收或者丢失。如果通信失敗,你會看到一條告訴你原因的資訊。
基本上來說,ping指令每次向一個裝置發送一個資料包,并等待回複,以确定裝置是否可連接配接,如圖6-31所示。
盡管ping對于IT業必不可少,但當部署了基于主機的防火牆時,它的結果就可能具有欺騙性了。現在很多的防火牆都限制了裝置去響應ICMP資料包。這樣對于安全性是有幫助的,因為潛在的攻擊者可能會使用ping來判斷主機是否可達,進而放棄進一步的行動。但這樣查找問題時也變得困難起來——當你知道你可以和一台裝置通信時,使用ping檢測連接配接卻收不到任何響應會讓你很抓狂。
ping功能在實際中是很好的簡單ICMP通信的例子。檔案icmp_echo.pcap 中的資料包會告訴你在運作ping時都發生了什麼。
第一個資料包(如圖6-32所示)顯示了主機192.168.100.138在給192.168.100.1發送資料包圖示1。當你展開這個資料包的ICMP區段時,你可以通過檢視類型和代碼域判斷ICMP資料包的類型。在這個例子中,資料包的類型是8圖示2,代碼是0圖示3,意味着這是一個echo請求(Wireshark會告訴你所顯示的類型/代碼究竟是什麼意思)。這個echo(ping)請求是整個過程的前一半。這是一個簡單的ICMP資料
包,使用IP發送,包含了很少的資料。除了指定的類型、代碼以及校驗和,我們還會有一個序列号用來比對請求和響應,還有在ICMP資料包可變域中的一串随機文本字元。
echo和ping經常會被混淆,但記住ping實際上是一個工具的名字。ping工具用于發送ICMP echo請求資料包。
這個序列的第二個資料包是對我們請求的響應(如圖6-33所示)。這個資料包的ICMP區段類型是0圖示1,代碼是0圖示2,表示這是一個echo響應。由于第二個資料包的序列号與第一個的相比對圖示3,我們就知道這個echo響應與之前資料包的echo請求比對。這個響應資料包中有着和初始請求中傳輸的32位字元串一樣的内容圖示4。在這第二個資料包被192.168.100.138成功接收到之後,ping就會報告成功(如圖6-34所示)。
你還可以使用ping的選項,增加它的資料填充,這樣在檢測不同類型網絡時,強制将資料包分片。這在你檢測分片較小的網絡時會用到。
ICMP的echo請求使用的随機文本可能會引起潛在攻擊者的興趣。攻擊者可能會用這段填充的内容來推測裝置所使用的作業系統。并且攻擊者可能在這個域中放置一些資料位作為反向連接配接的手段。
6.5.4 路由跟蹤
路由跟蹤功能用來識别一個裝置到另一個裝置的網絡路徑。在一個簡單的網絡上,這個網絡路徑可能隻經過一個路由器,甚至一個都不經過。但在複雜的網絡中,資料包可能會經過數十個路由器才會到達最終目的地。這就是為什麼确定資料包從一個目的地到另一個的實際路徑對于通信檢修十分重要。
通過使用ICMP(在IP的一些幫助下),路由跟蹤可以畫出資料包的路徑。舉例來說,檔案icmp_traceroute.pcap中的第一個資料包,和我們在上一節中看到的echo請求(如圖6-34所示)很類似。
乍看起來,這個資料包就是一個從192.168.100.138到4.2.2.1圖示2的簡單echo請求圖示1,并且ICMP中的每一部分都與echo請求資料包相同。但是當你展開這個資料包的IP頭時,你可以注意到一個奇怪的數字。這個資料包的TTL被設為了1圖示3,也就意味着這個資料包會在它遇到的第一個路由器處被丢掉。因為目标位址4.2.2.1是一個網際網路位址,我們就會知道源裝置和目的裝置之前至少會有一個路由器,是以這個資料包不會到達目的地。這對我們來說是個好事,因為路由跟蹤正是需要這個資料包隻到達它傳輸的第一個路由器。
第二個資料包正如所期望的那樣,是前往目的地路徑上第一個路由器發回的響應(如圖6-35所示)。這個資料包到達192.168.100.1這個裝置後,它的TTL減為0,是以它不能繼續傳輸,于是路由器回複了一個ICMP響應。這個資料包的類型是11圖示1,代碼是0圖示2,也就是告訴我們由于資料包的TTL在傳輸過程中逾時,是以目的不可達。
這個ICMP資料包有時候被叫做雙頭包,因為這個ICMP的結尾部分包含了原先echo請求的IP頭圖示3和ICMP資料圖示4的拷貝。這個資訊被證明在檢修的時候非常有用。
在第7個資料包前,這樣發送TTL自增資料包的過程又出現了兩次。這次的過程與你在第1個資料包中看到的過程不同,IP頭的TTL值被設為了2,進而保證這個資料包會在被丢棄前到達第二跳路由。和我們所期望的一樣,我們從下一跳的路由12.180.241.1接到了一個有着同樣ICMP目的不可達和TTL逾時消息的響應。這個将TTL自加1的過程一直持續直到到達目的地4.2.2.1。
總體來說,路由跟蹤要與路徑上的每一個路由器進行通信,進而畫出前往目的地的路由圖,如圖6-36所示。
我們這裡所讨論的路由跟蹤主要是基于Windows,因為隻有它在使用ICMP。Linux上的路由跟蹤更複雜一些,并使用了其他的協定來進行路由路徑的跟蹤。
你會在整本書中看到ICMP有着不同的功能。在我們分析更多場景的時候,我們會更頻繁地使用ICMP。
這一章主要向你介紹了資料包分析過程中會經常看到的最重要的幾種協定。IP、TCP、UDP和ICMP是所有網絡通信的基礎,并且對于你每天要進行的工作至關重要。在下一章中,我們将會學習一些常用的應用層協定。
本文僅用于學習和交流目的,不代表異步社群觀點。非商業轉載請注明作譯者、出處,并保留本文的原始連結。