【正文】 如果只保留 ESP/隧道模式，并要求 ESP 提供認 證功能，可以在不顯著減少系統(tǒng)功能的情況下，大大減少系統(tǒng)操作模式的數(shù)量，降低系統(tǒng)的復雜程度。 IPSec的文檔還指出在某些情況， AH和 ESP 可以同時使用， AH 提供認證功能而 ESP提供加密功能。這意味著如果兩臺計算機要對數(shù)據(jù)包進行認證一共有四種實現(xiàn)的方法。利用這些函數(shù)提供的安全功能，可以在不可信賴的網(wǎng)絡(luò)環(huán)境中建立 VPN，或者在局域網(wǎng)中為任何兩臺計算機之間發(fā)送數(shù)據(jù)包提供安全保護。這些在一定程度上導致了使用者對 IPSec難以清楚的認識，造成了不必要的安全問題。 IPSec的文檔也有很多不盡如人意之處。這是典型的由專家委員會制定標準造成的后果。正如功能測試無法證明系統(tǒng)不存在錯誤一樣，安全性分析不能證明系統(tǒng)不存在安全漏洞。所以 IPSec最大的問題之一就是過于復雜。但是對于復雜的系統(tǒng) —— 實際上我們并不知道如何處 理復雜性，復雜的系統(tǒng)錯誤很難糾正，復雜的關(guān)系讓一個小小的修改都可能引起更大的麻煩。鑒于許多簡單的系統(tǒng)也存在一些嚴重的安全性漏洞，很多都會覺得這句話很奇怪。根據(jù) RFC 2402～ 2412，對新版的 IPSec，密碼界的相關(guān)人士從包括安全性在內(nèi)的多個方面進行了分析和評論。 IPSec 安全性分析 IPSec的最早版本是 IETF于 1995年發(fā)布的，但是由于存在一些問題和安全缺陷， IETF的 IPSec工作 組于 1998年發(fā)布了新版的 IPSec。尚未引起足夠重視的一個重要的問題是在多播 (Multicast)環(huán)境下的密鑰分配問題，例如，在 Inter 多播骨干網(wǎng) (MBone)或 IM 網(wǎng)中的密鑰分配問題。但是，面 向用戶的密鑰分配需要對相應(yīng)的操作系統(tǒng)內(nèi)核作比較大的改動。這可能導致提供不了所需的功能，也可能會導致性能下降。它的最主要的缺點是一般對屬于不同進程和相應(yīng)條例的包不作區(qū)別。 Photuris 里面又添加了一種所謂的 cookie 交換，它可以 提供“清障 (antilogging)”功能，即防范對服務(wù)攻擊的否認。 Photuris 以及類 Photuris 協(xié)議的基本想法是對每一個會話密鑰都采用 DiffieHellman 參數(shù)，確保沒有“中間人”進行攻擊。 1996 年 9 月， IPSec決定采用 OAKLEY作為 ISAKMP 框架下強制推行的密鑰管理手段，采用SKIP 作為 IPv4 和 IPv6 實現(xiàn)時的優(yōu)先選擇。 MKMP 沒有這個要求，因為它假定雙方已經(jīng)共同知道一個主密鑰 (Master Key)，也可能是事先手工發(fā)布的。其中最重要的有： (1) IBM 提出的“標準密鑰管理協(xié)議 ((MKMP)” (2) Sun 提出的“ Inter 協(xié)議的簡單密鑰管理 (SKIP)” (3) Phil Karn 提出的“ Photuris 密鑰管理協(xié)議” (4) Hugo Krawczik 提出的“安全密鑰交換機制 (SKEME)” (5) NSA提出的“ Inter 安全條例及密鑰管理協(xié)議” (6) Hilarie Orman 提出的“ OAKLEY 密鑰決定協(xié)議” 需要再次強調(diào)指出的是，這些協(xié)議草案的相似點多于不同點。除 RFC 1828 和 RFC 1829 外，還有兩個實驗性的RFC 文件，規(guī)定了在 AH 和 ESP 體制中，用安全散列算法 (SHA )來代替 MD5 (RFC1825)和用三元 DES代替 DES (EFC 1815)。這些草案保留了原 RFC的語言和意圖，并進行了擴充，對包頭及其功能的描述更加完備，綜合性更強。 RFC 1826 (IP 身份驗證頭 )中對 AH 進行了描述，而 ESP 頭在 RFC1827(IP封裝安全有效負荷 (ESP))中描述。如果這樣的設(shè)備只用于一個主機，其工作情況與 BITS方法類似，但如果一個 BITW 設(shè)備為多個系統(tǒng)服務(wù)，實 現(xiàn)相對要復雜得多 [19]。這種方法使用外部加密硬件來執(zhí)行安全性處理功能。這種方法可用于將現(xiàn)有系統(tǒng)升級為支持 IPsec 的系統(tǒng)，且不要求重寫原有的 IP 棧軟件。這種方法將特殊的 IPsec 代碼插入到網(wǎng)絡(luò)棧中，在現(xiàn)有 IP 網(wǎng)絡(luò)軟件之下、本地鏈路軟件之上。但是，這種方法也要求對整個實體棧進行更新以反映上述改變。這意味著用戶可以愉快地使用應(yīng)用程序，而無需注意所有的數(shù)據(jù)報在發(fā)送到 Inter 之前，需要進行加密或身份驗證，當然在這種情形下所有的加密數(shù)據(jù)報都要由另一端的主機正確地解密，即要做到透明。而 ESP 可提供完整性、保密性 (如選擇適當?shù)乃惴?，它也可提供可鑒別性 )，這兩種方式可以結(jié)合起來提供更完善的安全保障。這些技術(shù)的有機結(jié)合定義了 IKE 自己獨特的驗證加密生成技術(shù)以及協(xié)商共享策略。 IKE 協(xié)議用于動態(tài)建立 SA， IKE 以 UDP 方式通信，端口號為 500。另外還要使用選擇符（ Selector），它被用來定義適用于某一 SA的或 SA集合的所有 IP數(shù)據(jù)流。 在 IPSce 的實現(xiàn)中需要用到兩個數(shù)據(jù)庫，一個是 SPD（安全策略數(shù)據(jù)庫）和 SAD（安全聯(lián)盟數(shù)據(jù)庫）。通過使用 AH 或 ESP 協(xié)議， SA為在其上承載的 IP 數(shù)據(jù)流提供安全服務(wù)。 SA 是兩個 IPSce 通信實體之間通過協(xié)商建立起來的一種共同協(xié)定， 它規(guī)定了通信雙方使用哪種 IPSce 協(xié)議保護數(shù)據(jù)安全、應(yīng)用的轉(zhuǎn)碼類型、加密和驗證的密鑰取值以及密鑰的生存周期等安全屬性值。雖然網(wǎng)關(guān)通常工作在隧道模式下，但是如果通信的目的地就是網(wǎng)關(guān)本身，那么網(wǎng)關(guān)也可以和普通主機一樣工作在傳輸模式之下。圖 35 以 Ipv4 為例說明在兩種模式下的ESP。 ESP 的格式因使用的算法不同而不同，要求至少支持兩種算法，即 HMACMD5 和 HMACSHA1。有些國家甚至連私用加密都要控制 [2]。 RFC 1827中對 ESP 的格式作了規(guī)定， RFC 1829中規(guī)定了在密碼塊連接 (CBC)狀態(tài)下 ESP 加密和解密要使用數(shù)據(jù)加密標準 (DES )。在管道狀態(tài)下，為當前已加密的 ESP 附加了一個新的 IP 頭(純文本 )，它可以用來對 IP 包在 Inter 上作路由選擇。圖 33 以 IPv4 為例，說明傳輸模式與隧道模式的區(qū)別： 數(shù) 據(jù)T C P 頭A H原 I P 頭數(shù) 據(jù)T C P 頭原 I P 頭A H新 I P 頭傳 輸 模 式隧 道 模 式隧 道 模 式 中 ， 新 I P 頭 的 可 變 字 段 不 參 加 認 證 圖 33 隧道模式和傳輸模式對比 2. 封裝安全載荷（ ESP） 由于認證信息只確保 IP 數(shù)據(jù)包的來源和完整性，而不能為 IP 數(shù)據(jù)包提供機 密性保護，所以引入20 了機密性保護 ESP，其協(xié)議代號為 50。傳輸模式只對上層協(xié)議數(shù)據(jù)和 IP 頭中的固定字段提供認證保護；隧道模式對整個 IP 數(shù)據(jù)包認證保護。最新 Inter 草案中建議的算法是HMACMD5 或 HMACSHA。RFC 1828首次規(guī)定了加封狀態(tài)下 AH 的計算和驗證中要采用帶密鑰的 MD5 算法。在后一種情形， AH 體制能額外地提供不可否認的服務(wù)。發(fā)送方用一個加密密鑰算出 AH，接收方用同一或另一密鑰對之進行驗證。認證頭的認證算法包括對基于稱密碼算法（如 DES）和基于單向散列函數(shù)（如 MD5 或SHA1）的帶密鑰的消息認證碼。 IPSec 協(xié)議主要由密鑰交換協(xié)議（ IKE）、認證頭（ AH）和封裝安全載荷（ ESP）三個子協(xié)議組成，同時還涉及認證和加密算法以及安全聯(lián)盟 SA等內(nèi)容。按照這些要求， IPSEC 工作組制定了一個規(guī)范：認證頭 (Authentication Header, AH)和封裝安全有效載荷(Encapsulating Security Payload, ESP)。該體制應(yīng)該是與算法無關(guān)的，即使加密算法替換了，也不會對其他部的實現(xiàn)產(chǎn)生影響。 IPSP 的主要目的是使需要安全措施的用戶能夠使用相應(yīng)的加密安全體制。 IPSec 定義了一個開放的體系結(jié)構(gòu)和一個開放的框架，它為 網(wǎng)絡(luò)層安全提供了一個穩(wěn)定的，長期持久的基礎(chǔ)。自動管理密鑰和安全聯(lián)盟（ SA），在需要很少人工配置的情況下，保證一個公司的 VPN 策略能在外延網(wǎng)絡(luò)上被方便而精確的實現(xiàn)。對傳輸層以上的應(yīng)用完全透明，操作系統(tǒng)原有軟件無須修改就可自動擁有 IPSec提供的安全功能，降低了軟件升級和用戶培訓的開銷。不僅可以實現(xiàn)密鑰自動管理，而且多種高層協(xié)議和應(yīng)用可以共享由 網(wǎng)絡(luò)層提供18 的密鑰管理基礎(chǔ)設(shè)施（ KMI），大大降低了密鑰協(xié)商開銷。 2. 比高層安全協(xié)議（如 SOCK v5）的性能更好，實現(xiàn)更方便；比低層安全協(xié)議更能適應(yīng)通信介質(zhì)多樣性。如果驗證數(shù)據(jù)有效，接受方就可以知道數(shù)據(jù)來自發(fā)送方，并且在傳輸過程中沒有被更改。這套協(xié)議在什么情況下使用，以及采用什么方式主要由用戶的具體應(yīng)用和系統(tǒng)安全要求來決定。它定義了一套默認的強制實施的算法，用以確保不同實現(xiàn)的系統(tǒng)的互通性。IPSec 提供了完整的保護機制，包括訪問 控制、無連接的完整性認證、數(shù)據(jù)來源認證、抗重傳、完整性、數(shù)據(jù)保密以及有限的通信流量保密等，從而有效保護 IP 數(shù)據(jù)的安全。也是目前應(yīng)用較廣的網(wǎng)絡(luò)安全協(xié)議。到達另一端時，外層的 IP 報頭被拆開，報頭被解密，然后送到收報地點。事實上，他們用的都是 IP 封裝技術(shù)。 SwIPe是另一個 Inter 層的安全協(xié)議，由 Ioannidis 和 Blaze 提出并實現(xiàn)原型?！熬W(wǎng)絡(luò)層安全協(xié)議 (NLSP)”是由國際標準化組織為“無連接網(wǎng)絡(luò)協(xié)議 (CLNP)”制訂的安全協(xié)議標準。 本章就 Inter的 Inter 層 的安全 對 Inter 層的安全協(xié)議進行標準化的想法早就有了。 在過去十多年里，許多的組織為實現(xiàn) TCP/IP的安全通信做了大量的工作，提出了很多 非常 有建設(shè)性和實用性的方法 。因此， B 被阻塞在 SYNRCVD 狀態(tài)，無法響應(yīng)來自其它客戶機的連接請求。 ③ 定時器問題 如果一入侵者企圖在不建立連接的情況下使連接建立定時器無效，可以觀察到以下序列包： 直到維持連接定時器將其重置為 CLOSED 狀態(tài)。 主機 C 不向主機 B發(fā)送其它任何包。 主機 B 首先處理 SYN 標志，生成一個帶有相應(yīng) ACK 標志位置位的包，并使狀態(tài)轉(zhuǎn)移到SYNRCVD，然后處理 FIN 標 志，使狀態(tài)轉(zhuǎn)移到 CLOSEWAIT，并向 C 回送 ACK 包。 從主機 C 到主機 B 發(fā)送一個帶有 SYN 和 FIN 標志位置位的 TCP 包。按照上述步驟，入侵主機能夠與主機 B 建立單向 TCP 連接。收到這個包之后，主機 B將向主機 A發(fā)送相應(yīng)的 SYNACK 包。 主機 A 向主機 B 發(fā)送一個 SYN 包。然后主機 C將用 RST 包作應(yīng)答。發(fā)送 SYN 包的目的是創(chuàng)建大量與主機 A 的半開放的 TCP 連接，從而填滿了主機 A的登錄端口連接隊列。 ① 偽造 IP 地址 最初，網(wǎng)絡(luò)監(jiān)控設(shè)備會監(jiān)測到大量的 TCP SYN 包從某個主機發(fā)往 A 的登錄端 r1。 (3) 利用網(wǎng)絡(luò)監(jiān)控設(shè)備觀測網(wǎng)絡(luò)入侵 在局域網(wǎng)上安裝一個網(wǎng)絡(luò)監(jiān)控設(shè)備觀測通過網(wǎng)絡(luò)的包，從而判斷是否發(fā)生了網(wǎng)絡(luò)入侵。由于 C不回送任何包，因此 A被鎖在 SYNRCVD狀態(tài)。 在 C 和 A 之間建立起一個 TCP 連接來傳送控制信號。在本例中，假設(shè)當主機收到對方的 SYN 包后，就關(guān)閉連接建立定時器。 A和 C 在收到對方的 SYN 包后都向?qū)Ψ桨l(fā)送一個 SYNACK 包。主機 A 向主機 C 發(fā)送一個 SYN 包，期待著回應(yīng)一個SYNACK 包。如果在規(guī)定時間內(nèi)不能建立連接，則 TCP 機回到 CLOSED 狀態(tài)。這會給系統(tǒng)帶來嚴重的安全性問題。因此入侵者可以假裝成已建立了合法連接的一個主機，然后向另一臺主機發(fā)送一個帶有適當序列號的 RST 段，這樣就可以終止連接了。這些轉(zhuǎn)移是很重要的，因為它們重置 TCP 而 中斷網(wǎng)絡(luò)連接。如果維持活動定時器特征被使用，通常 2 小時后 TCP 將會重置連接并轉(zhuǎn)移到 CLOSED 狀態(tài)。這個半開放連接保留在套接字偵聽隊列中，而且應(yīng)用進程不發(fā)送任何幫助 TCP 執(zhí)行狀態(tài)轉(zhuǎn)移的消息。因此，在這些 TCP 應(yīng)用程序中存在一條 TCP 協(xié)議中未作定義的從狀態(tài) SYNRCVD 到狀態(tài) CLOSEWAIT 的轉(zhuǎn)移弧，如圖 23 所示： 在上述入侵例子中，由于三次握手沒能徹底完成，因此并未真正建立 TCP 連接，相應(yīng)的網(wǎng)絡(luò)應(yīng)用程序并未從核心內(nèi)獲得連接。但是， TCP 協(xié)議中并未對從 SYNRCVD 狀態(tài)到 CLOSEWAIT 狀態(tài)的轉(zhuǎn)移作出定義。然后再處理 FIN 標志位，轉(zhuǎn)移到 CLOSEWAIT 狀態(tài)。在 TCP 協(xié)議中，關(guān)于如何處理 SYN 和 FIN同時置位的包并未作出明確的規(guī)定。 C 向 A發(fā)送一個包，其 SYN位和 FIN位 0 置位， A向 C 發(fā)送 ACK 包作為響應(yīng)： CA： SYN FIN(系列號 =M) AC： ACK(應(yīng)答序號 =M+1) 從狀態(tài)轉(zhuǎn)移圖可以看出， A 開始處于監(jiān)聽 (LISTEN)狀態(tài)。在前面的例子中，服務(wù)器端口是無法在 75 秒內(nèi)作出響應(yīng)的。如前所述， TCP維持一個連接建立定時器。主機 B 將執(zhí)行這些命令，認為他 們是由合法主機 A發(fā)來的。為此， C可以等到主機 A因某種原因終止運行，或者阻塞主機 A 的操作系統(tǒng)協(xié)議部分，使它不能響應(yīng)主機 B。假設(shè)主機 C 與 A 和 B 不同在一個子網(wǎng)內(nèi)，則不能檢測到 B的包，主機 C只有算出 B 的序列號，才能創(chuàng)建 TCP 連接。同時，主機 B 產(chǎn)生自己發(fā)送包序列號，并將其