【正文】 I T 1F I N W A I T 2 T I M E W A客 戶 機 正 常 運 轉服 務 器 正 常 運 轉外 部 轉 移 圖 23 非正常狀態(tài)轉移 14 上述的入侵過程，主機 C是如何阻止主機 A向主機 B發(fā)送響應的呢？主機 C 可以通過代表 A發(fā)送一系列的 SYN 包，但不讓 A 向 B 發(fā)送 SYNACK 包而中止主機 A 的登錄端 GI。如前所述， TCP維持一個連接建立定時器。如果在規(guī)定時間內 (通常為 75 秒 )不能建立連接，則 TCP 將重置連接。在前面的例子中，服務器端口是無法在 75 秒內作出響應的。 下面來討論一下主機 C和主機 A之間 相互發(fā)送的包序列。 C 向 A發(fā)送一個包，其 SYN位和 FIN位 0 置位， A向 C 發(fā)送 ACK 包作為響應： CA： SYN FIN(系列號 =M) AC： ACK(應答序號 =M+1) 從狀態(tài)轉移圖可以看出， A 開始處于監(jiān)聽 (LISTEN)狀態(tài)。當它收到來自 C 的包后，就開始處理這個包。在 TCP 協(xié)議中，關于如何處理 SYN 和 FIN同時置位的包并未作出明確的規(guī)定。假設它首先處理 SYN標志位，轉移到 SYNRCVD 狀態(tài)。然后再處理 FIN 標志位，轉移到 CLOSEWAIT 狀態(tài)。如果前一個狀態(tài)是 ESTABLISHED， 那么轉移到 CLOSEWAIT 狀態(tài)就是正常轉移。但是， TCP 協(xié)議中并未對從 SYNRCVD 狀態(tài)到 CLOSEWAIT 狀態(tài)的轉移作出定義。但在幾種 TCP 應用程序中都有這樣的轉移，例如開放系統(tǒng) ULTRX4. 3。因此，在這些 TCP 應用程序中存在一條 TCP 協(xié)議中未作定義的從狀態(tài) SYNRCVD 到狀態(tài) CLOSEWAIT 的轉移弧，如圖 23 所示： 在上述入侵例子中，由于三次握手沒能徹底完成，因此并未真正建立 TCP 連接，相應的網絡應用程序并未從核心內獲得連接。但是，主機 A 的 TCP 機處于 CIOSEWAIT 狀態(tài)，因此它 可以向 C發(fā)送一個 FIN 包終止連接。這個半開放連接保留在套接字偵聽隊列中，而且應用進程不發(fā)送任何幫助 TCP 執(zhí)行狀態(tài)轉移的消息。因此主機 A的 TCP 機被鎖在了 CLOSEWAIT 狀態(tài)。如果維持活動定時器特征被使用，通常 2 小時后 TCP 將會重置連接并轉移到 CLOSED 狀態(tài)。 當 TCP 機收到來自對等主機的 RST 時，就從 ESTABLISHED, FINWAIT1 和 FINWAIT2 狀態(tài)轉移到 CLOSED 狀態(tài)。這些轉移是很重要的，因為它們重置 TCP 而 中斷網絡連接。但是，由于到達的數據段只根據源 IP 地址和當前隊列窗口號 來證實。因此入侵者可以假裝成已建立了合法連接的一個主機，然后向另一臺主機發(fā)送一個帶有適當序列號的 RST 段，這樣就可以終止連接了。 從上面的分析可以看到幾種 TCP 應用程序中都存在外部狀態(tài)轉移。這會給系統(tǒng)帶來嚴重的安全性問題。 ③ 定時器問題 正如前文所述，一旦進入連接建立過程，則啟動連接定時器。如果在規(guī)定時間內不能建立連接，則 TCP 機回到 CLOSED 狀態(tài)。 再來分析一下主機 A 和主機 C 的例子。主機 A 向主機 C 發(fā)送一個 SYN 包，期待著回應一個SYNACK 包。假設幾乎同時，主機 C想與主機 A建 立連接，向 A發(fā)送一個 SYN 包。 A和 C 在收到對方的 SYN 包后都向對方發(fā)送一個 SYNACK 包。當都收到對方的 SYNACK 包后，就可認為連接15 己建立。在本例中，假設當主機收到對方的 SYN 包后，就關閉連接建立定時器。 CA: SYN(序列號 =M) AC: SYN(序列號 =N) CA: SYN(序列號 =M)， ACK(應答號 =N+1) AC: SYN(序列號 =N)， ACK(應答號 =M+l) 主機 C 向主機 A發(fā)送一個 FTP 請求。在 C 和 A 之間建立起一個 TCP 連接來傳送控制信號。主機 A向 C 發(fā)送一個 SYN 包以啟動一個 TCP 連接用來傳輸數據，其狀態(tài)轉移到 SYNSENT 狀態(tài)。 當 C 收到來自 A的 SYN 包時，它回送一個 SYN 包作為響應。 主機 C 收到來自 A的 SYNACK 包，但不回送任何包。 主機 A期待著接收來自 C的 SYNACK。由于 C不回送任何包，因此 A被鎖在 SYNRCVD狀態(tài)。這樣， C 就成功地封鎖了 A的一個端口。 (3) 利用網絡監(jiān)控設備觀測網絡入侵 在局域網上安裝一個網絡監(jiān)控設備觀測通過網絡的包，從而判斷是否發(fā)生了網絡入侵。下面討論在幾種入侵過程中網絡監(jiān)控設備可觀測 到的序列包。 ① 偽造 IP 地址 最初，網絡監(jiān)控設備會監(jiān)測到大量的 TCP SYN 包從某個主機發(fā)往 A 的登錄端 r1。主機 A 會回送相應的 SYNACK 包。發(fā)送 SYN 包的目的是創(chuàng)建大量與主機 A 的半開放的 TCP 連接，從而填滿了主機 A的登錄端口連接隊列。 大量的 TCP SYN 包將從主機 C經過網絡發(fā)往主機 B，相應地有 SYNACK包從主機 B 發(fā)往主機C。然后主機 C將用 RST 包作應答。這個 SYN/SYNACK/RST 包序列使得入侵者可以知道主機 B的TCP 序列號發(fā)生器的動作。 主機 A 向主機 B 發(fā)送一個 SYN 包。實際上，這 是主機 C 發(fā)送的一個“偽造”包。收到這個包之后，主機 B將向主機 A發(fā)送相應的 SYNACK 包。主機 A向主機 B 發(fā)送 ACK 包。按照上述步驟，入侵主機能夠與主機 B 建立單向 TCP 連接。 ② 虛假狀態(tài)轉移 當入侵者試圖利用從 SYNRCVD 到 CLOSEWAIT 的狀態(tài)轉移長時間阻塞某服務器的一個網絡端口時，可以觀察到如下序列包： 從主機 C 到主機 B 發(fā)送一個帶有 SYN 和 FIN 標志位置位的 TCP 包。 主機 B 首先處理 SYN 標志，生成一個帶有相應 ACK 標志位置位的包，并使狀態(tài)轉移到SYNRCVD，然后處理 FIN 標 志，使狀態(tài)轉移到 CLOSEWAIT，并向 C 回送 ACK 包。 主機 C 不向主機 B發(fā)送其它任何包。主機的 TCP 機將固定在 CLOSEWAIT 狀態(tài)。直到維持連接定時器將其重置為 CLOSED 狀態(tài)。 16 因此，如果網絡監(jiān)控設備發(fā)現一串 SYNFIN / ACK 包，可推斷入侵者正在阻塞主機 B的某個端口。 ③ 定時器問題 如果一入侵者企圖在不建立連接的情況下使連接建立定時器無效，可以觀察到以下序列包： 主機 C 從主機 B 收到一個 TCP SYN 包。 主機 C 向主機 B 回送一個 SYN 包。 主機 C 不向 主機 B 發(fā)送任何 ACK 包。因此， B 被阻塞在 SYNRCVD 狀態(tài)，無法響應來自其它客戶機的連接請求。 17 3 安全協(xié)議分析 由于 TCP/IP 本身缺乏對安全性的考慮，所以要實現基于 TCP/IP 的安全通信必須借助其他的手段。 在過去十多年里，許多的組織為實現 TCP/IP的安全通信做了大量的工作，提出了很多 非常 有建設性和實用性的方法 。 從這些方法提供的服務和使用的機制來講，這些方式大體相似，但從各自的應用范圍和在 TCP/IP的協(xié)議棧中位置則不盡相同。 本章就 Inter的 Inter 層 的安全 對 Inter 層的安全協(xié)議進行標準化的想法早就有了。例如，“安全協(xié)議 3 號 (Security Protocol 3)”就是由美國國家安全局以及標準技術協(xié)會作為“安全數據網絡系統(tǒng) (SDNS)”的一部分而制訂的?！熬W絡層安全協(xié)議 (NLSP)”是由國際標準化組織為“無連接網絡協(xié)議 (CLNP)”制訂的安全協(xié)議標準?！凹苫?NLSP (INLSP)”是由美國國家科技研究所提出的包括 IP 和 CLNP 在內的統(tǒng)一安全機制。 SwIPe是另一個 Inter 層的安全協(xié)議，由 Ioannidis 和 Blaze 提出并實現原型。所有這些提案的共同點多于不同點。事實上，他們用的都是 IP 封裝技術。其本質是純文本的包被加密封裝在外層的 IP 報頭里，用來對加密的包進行 Inter 上的路由選擇。到達另一端時，外層的 IP 報頭被拆開，報頭被解密，然后送到收報地點。 IPSec（ IP Security）協(xié)議就是基于這種方案的安全協(xié)議。也是目前應用較廣的網絡安全協(xié)議。 IPSec (IP Security)協(xié)議是一種由 IETF 設計的端到端的確保基于 IP 通訊的數據安全性的機制。IPSec 提供了完整的保護機制，包括訪問 控制、無連接的完整性認證、數據來源認證、抗重傳、完整性、數據保密以及有限的通信流量保密等，從而有效保護 IP 數據的安全。 IPSec 提供了一種標準的、強壯的和包容廣泛的機制，可以為 IP 及其上層傳輸協(xié)議提供安全措施。它定義了一套默認的強制實施的算法，用以確保不同實現的系統(tǒng)的互通性。 IPSec 為 IPv4 和 IPv6 提供基于密碼的高度安全的協(xié)議，這套安全服務是通過采用兩種數據安全協(xié)議，認證頭協(xié)議 (AH, Authentication Header)，安全封裝載荷協(xié)議 (ESP, Encapsulation Security Payload)和一些密鑰管理方法和協(xié)議實現的。這套協(xié)議在什么情況下使用，以及采用什么方式主要由用戶的具體應用和系統(tǒng)安全要求來決定。 IPSec 協(xié)議下，只有發(fā)送方和接受方知道加密密鑰。如果驗證數據有效，接受方就可以知道數據來自發(fā)送方，并且在傳輸過程中沒有被更改。 與同類協(xié)議相比： IPSec 具有以下優(yōu)點： 。 2. 比高層安全協(xié)議（如 SOCK v5）的性能更好，實現更方便；比低層安全協(xié)議更能適應通信介質多樣性。 3. 系統(tǒng)開銷小。不僅可以實現密鑰自動管理，而且多種高層協(xié)議和應用可以共享由 網絡層提供18 的密鑰管理基礎設施（ KMI），大大降低了密鑰協(xié)商開銷。 4. 透明性好。對傳輸層以上的應用完全透明，操作系統(tǒng)原有軟件無須修改就可自動擁有 IPSec提供的安全功能，降低了軟件升級和用戶培訓的開銷。 5. 管理方便。自動管理密鑰和安全聯盟（ SA），在需要很少人工配置的情況下，保證一個公司的 VPN 策略能在外延網絡上被方便而精確的實現。 6. 開放性好。 IPSec 定義了一個開放的體系結構和一個開放的框架，它為 網絡層安全提供了一個穩(wěn)定的，長期持久的基礎。 IPSec 體系結構 Inter 工程特遣組 (IETF)已經特許 Inter 協(xié)議安全協(xié)議 (IPSEC)工作組對 IP 安全協(xié)議 (IPSP)和對應的 Inter 密鑰管理協(xié)議 (IKMP)進行標準化工作。 IPSP 的主要目的是使需要安全措施的用戶能夠使用相應的加密安全體制。該體制不僅能在目前流行的 IP (IPv4)下工作，也能在 IP 的新版本 (Ing或 IP v6)下工作。該體制應該是與算法無關的，即使加密算法替換了，也不會對其他部的實現產生影響。此外，該體制必須能實行多種安全策略，但要避免給不使用該體制的人造成不利影響。按照這些要求， IPSEC 工作組制定了一個規(guī)范：認證頭 (Authentication Header, AH)和封裝安全有效載荷(Encapsulating Security Payload, ESP)。 AH 提供 IP 包的真實性和完整性， ESP 提供機要內容。 IPSec 協(xié)議主要由密鑰交換協(xié)議（ IKE）、認證頭（ AH）和封裝安全載荷（ ESP）三個子協(xié)議組成，同時還涉及認證和加密算法以及安全聯盟 SA等內容。 以上各 IPSec 的要素關系如圖 31 所示： 體 系封 裝 安 全 載 荷 （ E S P ） 認 證 頭 （ A H ）加 密 算 法 認 證 算 法解 釋 域密 鑰 交 換 與 管 理 （ I K E ） 安 全 聯 盟 （ S A ） 圖 31 IPSec安全體系 結構圖 19 1. 認證頭（ AH） 認證頭的協(xié)議代號是 51，是一個基于網絡層的安全協(xié)議，用于為 IP 數據包提供安全認證的一種安全協(xié)議。認證頭的認證算法包括對基于稱密碼算法（如 DES）和基于單向散列函數（如 MD5 或SHA1）的帶密鑰的消息認證碼。 即是指一段消息認證代碼 (Message Authentication Code, MAC)，在發(fā)送 IP 包之前，它已經被事先計算好。發(fā)送方用一個加密密鑰算出 AH，接收方用同一或另一密鑰對之進行驗證。如果收發(fā)雙方使用的是單鑰體制，那它們就使用同一密鑰；如果收 發(fā)雙方使用的是公鑰體制，那它們就使用不同的密鑰。在后一種情形， AH 體制能額外地提供不可否認的服務。事實上，有些在傳輸中有可變的域，如 IPv4 中的 timetolive 域或 IPv6 中的 hop limit 域，都是在 AH 的計算中必須略過不計的。RFC 1828首次規(guī)定了加封狀態(tài)下 AH 的計算和驗證中要采用帶密鑰的 M