【文章內(nèi)容簡介】 的 TCP 或 UDP 報(bào)文首部中的 TCP 或 UDP 端口號來判斷 )聯(lián)系起來。 下面各種情況都不會導(dǎo)致產(chǎn)生 ICMP 差錯(cuò)報(bào)文： 1)ICMP 差錯(cuò)報(bào)文 (但是， ICMP 查詢 報(bào)文可能會產(chǎn)生 ICMP 差錯(cuò)報(bào)文 )。 2)目的地址是廣播地址或多播地址的 IP 數(shù)據(jù)報(bào)。 3)作為鏈路層廣播的數(shù)據(jù)報(bào)。 4)不是 IP 分片的第一片。 5)源地址不是單個(gè)主機(jī)的數(shù)據(jù)報(bào)。這就是說，源地址不能為零地址、環(huán)回地址、廣播地址或多播地址。這些規(guī)則是為了防止過去允許 ICMP 差錯(cuò)報(bào)文廣播分組響應(yīng)所帶來的廣播風(fēng)暴。 ICMP 的重要性簡介 ICMP 協(xié)議對于網(wǎng)絡(luò)安全具有極其重要的意義。 ICMP 協(xié)議本身的特點(diǎn)決定了它非常容易被用于攻擊網(wǎng)絡(luò)上的路由器和主機(jī)。例如，在 1999 年 8 月海信集團(tuán)“懸賞” 50 萬元人民幣測試防火墻的過程 中，其防火墻遭受到的 ICMP 攻擊達(dá) 334050 次之多，占整個(gè)攻擊總數(shù)的 90%以上！可見， ICMP 的重要性絕不可以忽視。比如，可以利用操作系統(tǒng)規(guī)定的 ICMP 數(shù)據(jù)包的最大尺寸不超過 64KB這一規(guī)定，向主機(jī)發(fā)起“ Ping of Death” (死亡之 Ping)攻擊?！?Ping of Death”攻擊的原理是：如果 ICMP 數(shù)據(jù)包的尺寸超過 64KB 上限時(shí)，主機(jī)就會出現(xiàn)內(nèi)存分配錯(cuò)誤，導(dǎo)致 TCP/IP 堆棧崩潰，致使主機(jī)死機(jī)。此外，向目標(biāo)主機(jī)長時(shí)間、連續(xù)、大量地發(fā)送 ICMP 數(shù)據(jù)包，也會最終使系統(tǒng)癱瘓。大量的 ICMP 數(shù)據(jù)包會形成“ ICMP”風(fēng)暴，使得目標(biāo)主機(jī)耗費(fèi)大量的 CPU 資源，疲于奔命。 4 網(wǎng)絡(luò)套接字 套接字概述 網(wǎng)絡(luò)通信是以套接字為基礎(chǔ)的，一個(gè)套接字就是通信的一端。在通信的每一端，都可以找到與其對應(yīng)的一個(gè)套接字。每當(dāng)一臺主機(jī)要與另一臺機(jī)器對話時(shí)，它首先就要?jiǎng)?chuàng)建一對套接字，即使它正在使用著一對套接字與那臺計(jì)算機(jī)通信，因?yàn)檫@次又開始了一次新的對話。通常所說的網(wǎng)絡(luò)通信，實(shí)際上是兩臺計(jì)算機(jī)通過一對套接字相互傳輸數(shù)據(jù)的過程。一個(gè)正在被使用的套接字有著它的類型與其相關(guān)的進(jìn)程。最早使用套接字編程的是 Berkeley分校的研究人員們，他們在 UNIX平臺上開發(fā)了 Berkeley 套接字方案，使得通過這種接口能實(shí)現(xiàn)多種網(wǎng)絡(luò)協(xié)議之間 第 8 頁 共 24 頁 的連接。 套接字可以根據(jù)通信任務(wù)的性質(zhì)分類。用戶可以覺察出它們的區(qū)別。應(yīng)用程序一般僅在同一類的套接字間通信。目前可以使用三種套接字，即流套接字、數(shù)據(jù)報(bào)套接字和原始套接字。下面簡單介紹三種套接字的特點(diǎn)。 1)流套接字，提供了雙向的、有序的、無重復(fù)并且無記錄邊界的數(shù)據(jù)流服務(wù)，它適用于處理大量數(shù)據(jù)。網(wǎng)絡(luò)傳輸層可以將數(shù)據(jù)分散或集中到合適尺寸的數(shù)據(jù)報(bào)中。 流套接字是面向連接的，通信雙方進(jìn)行數(shù)據(jù)交換之前，必須建立一條路徑，這樣既確定了 它們之間存在的路由，又保證了雙方都是活動(dòng)的、可彼此響應(yīng)的，但在通信雙方之間建立一個(gè)通信信道需要很多開支。除此以外，大部分面向連接的協(xié)議為保證發(fā)送無誤，可能會需要執(zhí)行額外的計(jì)算來驗(yàn)證正確性，因此會進(jìn)一步增加開銷。 2)數(shù)據(jù)報(bào)套接字，支持雙向的數(shù)據(jù)流，但并不保證數(shù)據(jù)是可靠、有序和無重復(fù)的。也就是說，一個(gè)從數(shù)據(jù)報(bào)套接字中接收信息的進(jìn)程有可能發(fā)現(xiàn)信息重復(fù)或者和發(fā)出時(shí)的順序不同。此外，數(shù)據(jù)報(bào)套接字的一個(gè)重要特點(diǎn)是它保留了記錄邊界。對于這一特點(diǎn)，數(shù)據(jù)報(bào)套接口采用了與現(xiàn)在許多包交換網(wǎng)絡(luò) (例如以太網(wǎng) )非常類似的模型。 數(shù)據(jù) 報(bào)套接字是無連接的，它不保證接收端是否正在偵聽，類似與郵政服務(wù)：發(fā)信人把信裝入郵箱即可，至于收信人是否能收到這封信或郵局是否能按時(shí)將信件投遞到收信人處等，發(fā)信人都不得而知。因此，數(shù)據(jù)報(bào)并不可靠，需由程序員負(fù)責(zé)管理數(shù)據(jù)報(bào)的排序和可靠性。 應(yīng)用程序一般僅在同一類的套接口間通信，不過只要底層的通信協(xié)議允許，不同類型的套接口間也照樣可以通信。 3)原始套接字，從用戶的角度看， SOCK_STREAM、 SOCK_DGRAM 這兩類套接字似乎的確涵蓋了 TCP/IP 應(yīng)用的全部，因?yàn)榛?TCP/IP 的應(yīng)用，從協(xié)議棧的層次上講， 在傳輸層的確只可能建立于 TCP 或 UDP 協(xié)議之上，而SOCK_STREAM、 SOCK_DGRAM 又分別對應(yīng)于 TCP 和 UDP，所以幾乎所有的應(yīng)用都可以用這兩類套接字實(shí)現(xiàn)。但是，當(dāng)我們面對如下問題時(shí)，SOCK_STREAM、 SOCK_DGRAM 將顯得這樣無助： (1)怎樣發(fā)送一個(gè)自定義的 IP 包？ (2)怎樣發(fā)送一個(gè) ICMP 協(xié)議包？ (3)怎樣分析所有經(jīng)過網(wǎng)絡(luò)的包，而不管這包是否是發(fā)給自己的？ Raw Socket 與標(biāo)準(zhǔn)套接字 (SCCK_STREAM、 SOCK_DGRAM)的區(qū)別在于前者直接置“根”與操作系統(tǒng)網(wǎng)絡(luò)核 心 (Network Core)，而 SOCK_STREAM、 第 9 頁 共 24 頁 SOCK_DGRAM“懸浮”與 TCP 和 UDP 協(xié)議的外圍。當(dāng)我們使用 Raw Socket的時(shí)候，可以完全自定義 IP 包，一切形式的包都可以“制造”出來。 Winsock 中的幾個(gè)基本概念 Winsock Windows 下網(wǎng)絡(luò)編程的規(guī)范 —— Windows Sockets 是得到廣泛應(yīng)用的、開放的、支持多種協(xié)議的網(wǎng)絡(luò)編程接口。該規(guī)范以 大學(xué) BSD UNIX 中流行的 Socket 接口為范例定義了一套 Microsoft Windows 下網(wǎng)絡(luò)編程接 口。它不僅包含了人們所熟悉的 Berkeley Socket 風(fēng)格的庫函數(shù)，也包含了一組針對Windows 的擴(kuò)展函數(shù)，以使程序員能充分利用 Windows 消息驅(qū)動(dòng)機(jī)制進(jìn)行編程。 阻塞和非阻塞 套接字可以處于阻塞或非阻塞模式。在阻塞模式下，在 I/O 操作完成前，執(zhí)行操作的 Winsock 函數(shù)會一直等待下去，不會立即返回 (將控制權(quán)交還給程序 )，直到操作完成。在非阻塞模式下， Winsock 函數(shù)無論如何都會立即返回并交出程序的控制權(quán)，在默認(rèn)情況下，套接字為阻塞模式。 字節(jié)順序 不同的計(jì)算機(jī)有時(shí)使用不同的字節(jié)順序存儲數(shù)據(jù)。任 何從 Winsock 函數(shù)對 IP地址和端口號的引用和傳送給 Winsock 函數(shù)的 IP 地址和端口號均是按照網(wǎng)絡(luò)順序組織的，這也包括了 sockaddr_in 這一數(shù)據(jù)結(jié)構(gòu)中的 IP 地址和端口號 (但不包括sin family)。 客戶機(jī) /服務(wù)器模型 一個(gè)在建立分布式應(yīng)用時(shí)最常用的范例便是客戶機(jī) /服務(wù)器模型。在這種方案中客戶應(yīng)用程序向服務(wù)器程序請求服務(wù)。這種方式隱含了在建立客戶機(jī) /服務(wù)器間通信的非對稱性。該模型工作時(shí)要求有一套為客戶機(jī)和服務(wù)器所共識的慣例，來保證服務(wù)能夠被提供。這一套慣例包含了一套協(xié)議，它必須在通信的兩頭都被 實(shí)現(xiàn)。根據(jù)不同的情況，協(xié)議可能是對稱的或是非對稱的。在對稱的協(xié)議中，每一方都有可能扮演主從角色；在非對稱協(xié)議中，一方被不可改變地認(rèn)為是主機(jī)，而另一方則是從機(jī)。一個(gè)對稱協(xié)議的例子是 Inter 中用于終端仿真的 Tel。而非對稱協(xié)議的例子是 Inter 中的 FTP。無論具體的協(xié)議是對稱的還是非對稱的，當(dāng)服務(wù)被提供時(shí)必然存在“客戶進(jìn)程”和“服務(wù)進(jìn)程”。 一個(gè)服務(wù)程序通常在一個(gè)眾所周知的地址監(jiān)聽對服務(wù)的請求，也就是說，服務(wù)進(jìn)程一直處于休眠狀態(tài)，直到一個(gè)客戶對這個(gè)服務(wù)的地址提出了連接請求。在這個(gè)時(shí)刻，服務(wù)程 序被“驚醒”并且為客戶提供服務(wù) — 對客戶的請求做出適當(dāng)?shù)?第 10 頁 共 24 頁 反應(yīng)。 Winsock 編程原理 Winsock 的啟動(dòng)和終止 由于 Winsock 的服務(wù)是以動(dòng)態(tài)連接庫 Winsock DLL 形式實(shí)現(xiàn)的，因此必須先調(diào)用 WSAStartup 函數(shù)對 Winsock 進(jìn)行初始化，協(xié)商 Winsock 的版本支持，并分配必要的資源。如果在調(diào)用 Winsock 函數(shù)之前，沒有加載 Winsock 庫，則會返回 SOCKET_ERROR 錯(cuò)誤，錯(cuò)誤信息是 WSANOTINITIALISED。 WSAStartup函數(shù)原形如下 : int WSAStartup(WORD wVersionRequested,LPWSADATA lpWSAData)； 其中 wVersionRequested 用于指定準(zhǔn)備加載的 Winsock 庫的版本，通常的做法是高位字節(jié)指定所需要的 Winsock 庫的副版本，而低位字節(jié)則是主版本，然后，再用宏 MAKEWORD(X,Y)(X 是高位字節(jié)， Y 是低位字節(jié) )獲得 wVersionRequested的正確值。 lpWSAData 參數(shù)是指向 LPWSADATA 結(jié)構(gòu)的指針，該結(jié)構(gòu)包含了加載的庫版本有關(guān)的信息，它的格式如下： Typedef struct WSAData { WORD wVersion。 WORD wHighVersion。 char szDescription [WSADESCRIPTION_LEN+1]。 char szSystemStatus [WSASYS_STATUS_LEN+1]。 unsighed short iMaxSockets。 unsighed short iMaxUdpDg。 char FAR * lpVendorInfo。 } WSADATA, *LPWSADATA。 其中， wVersion 字段為希望使用它們的 Winsock 版本。字段 wHighVersion返回現(xiàn)有 Winsock 的最高版本。 szDescription 和 szSystemStatus 這兩個(gè)字段由特定的 Winsock 實(shí)施方案設(shè)定，事實(shí)上沒有用。字段 iMaxSockets 和 iMaxUdpDg分別為可同時(shí)打開的套接字?jǐn)?shù)和數(shù)據(jù)報(bào)的最大長度，一般不要使用它們，若想知道數(shù)據(jù)報(bào)的最大長度則應(yīng)該通過 WSAEnumProtocols 函數(shù)來查詢協(xié)議信息，而可同時(shí)打開套接字的最大數(shù)目不是固定的，它很大程度上和可用物理內(nèi)存的多少有關(guān) 。最后一個(gè)字段 lpVendorInfo 是為 Winsock 實(shí)施方案有關(guān)的指定廠商信息預(yù)留的，任何一個(gè) Win32 平臺上都沒有使用這個(gè)字段。 此外，在應(yīng)用程序關(guān)閉套接字后，還應(yīng)調(diào)用 WSACleanup 函數(shù)終止對 Winsock DLL 的使用，并釋放資源，以備下一次使用。 WSACleanup 函數(shù)的原形如下： int WSACleanup(void)；該函數(shù)不帶任何參數(shù)，若調(diào)用成功則返回 0，否則返回錯(cuò)誤。 第 11 頁 共 24 頁 錯(cuò)誤檢查和控制 錯(cuò)誤檢查和控制對于 Winsock 應(yīng)用程序是至關(guān)重要的。事實(shí)上，對 Winsock API 函數(shù)來說，返回 錯(cuò)誤是常見的，但是多數(shù)情況下，通信仍可在套接字上進(jìn)行。 盡管返回錯(cuò)誤的值并非一成不變，但不成功的 Winsock 調(diào)用返回的最常見的值是SOCKET_ERROR( 值為 1 的 常 量 ) 。 如 果 錯(cuò) 誤 情 況 發(fā) 生 了 ， 就 可 用WSAGetLastError 函數(shù)來獲得一段代碼，這段代碼明確地表明產(chǎn)生錯(cuò)誤的原因。該函數(shù)原形為： int WSAGetLastError(void)； 該函數(shù)返回的錯(cuò)誤都是預(yù)先聲明的常量，根據(jù) Winsock 版本的不同，這些值的聲明不在 Winsock 中，就會在 中。兩個(gè)頭字段的惟一差 別是 中包含的錯(cuò)誤代碼 (針對 中引入的一些新的 API 函數(shù) )更多。為各種錯(cuò)誤代碼聲明的常量一般都以 WSAE 開頭。 Winsock 編程模型 不論是流套接字還是數(shù)據(jù)報(bào)套接字編程，一般都采用客戶 /服務(wù)器方式，它們的運(yùn)作過程基本類似，下面簡單介紹兩種基本的套接字編成模型。 (1) 數(shù)據(jù)報(bào)套接字編程模型。 數(shù)據(jù)報(bào)套接字編程的時(shí)序圖如圖 41 所示。 )服務(wù)器進(jìn)程創(chuàng)建套接字 服務(wù)進(jìn)程總是先于客戶進(jìn)程啟動(dòng)，服務(wù)進(jìn)程首先調(diào)用 socket 函數(shù)創(chuàng)建一個(gè)套接字。 socket 函數(shù)原形如下： SOCKET socket (int af, int type, int protocol)。 其中，參數(shù) af 用于指定網(wǎng)絡(luò)地址類型，一般取 AF_INET，表示該套接字在Inter 域中進(jìn)行通信。參數(shù) type 用于指定套接字類型，若取 SOCK_DGRAM 表示要?jiǎng)?chuàng)建的套接字是數(shù)據(jù)報(bào)套接字，若取 SOCK_RAW 表示要?jiǎng)?chuàng)建的套接字是原始套接字。參數(shù) protocol 用于指定網(wǎng)絡(luò)協(xié)議，一般取 0，表示默認(rèn)為 TCP/IP 協(xié)議，本課題指定協(xié)議為 IPPROTO_ICMP，表示創(chuàng)建一個(gè)將 ICMP 作為一種基層 IP 協(xié)議的套接字。 )將本地地址綁定到所創(chuàng)建的套接字上以便在網(wǎng)絡(luò)上表示該套接字。 這個(gè)過程就是通過調(diào)用 bind 函數(shù)來完成的，該函數(shù)原形如下： int bind(SOCKET s, const struct sockaddr *name, int namelen)； 其中，參數(shù) s 表示一個(gè)未捆綁套接字描述符。參數(shù) name 是賦予套接字的地址，它由 struct sockaddr 結(jié)構(gòu)表示，該結(jié)構(gòu)的格式如下： struct sockaddr{u_short sa_family； char sa_data[14]； }；該地址結(jié)構(gòu)隨選擇的 協(xié)議的不同而變化，因此一般情況下另一個(gè)與該地址結(jié)構(gòu)大小相同的