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