Windows ipsec 簡介

簡介

當您建立 IPsec 策略時，您需配置 IPsec 規則（這些規則確定 IPsec 的行為）以及設定（設定的應用與配置的規則無關）。 配置 IPsec 策略後，必須將該策略指派給一台電腦才能實施該策略。 雖然在一台電腦上可以存在多個 IPsec 策略，但每次只能將一個 IPsec 策略指派給一台電腦。

IPsec 規則確定 IPsec 必須對哪些類型的通訊流進行檢查；是允許通訊流、阻止通訊流還是協商安全性；如何對 IPSec 對等方進行身分識別驗證；以及其他設定。 配置 IPsec 規則時，您可以配置篩選器列表，該列表包含一個或多個篩選器、篩選器操作、驗證方法、連線類型和 IPsec 封裝模式（傳輸模式或隧道模式）。 IPsec 規則通常是針對特定用途（例如，“阻止所有從 Internet 到 TCP 通訊埠 135 的入站通訊流”）配置的。

篩選器定義了要檢查的通訊流（這與防火牆規則類似）以及源和目標 IP 位址、協議和連接埠號碼（如果適用）。 篩選器操作定義了網路通訊流的安全性要求。 您可以配置篩選器操作以允許通訊流、阻止通訊流或協商安全性（協商 IPsec）。 如果將篩選器操作配置為協商安全性，則還必須配置各種金鑰交換安全措施（以及這些方法的優先順序）、是否接受最初傳入的無安全保護的通訊流、是否允許與不支援 IPsec 的電腦進行無安全保護的通訊以及是否使用完全向前保密 (PFS)。

金鑰交換設定和金鑰交換安全措施確定了 IPsec 協議線格式（驗證頭 (AH) 或封裝式安全措施負載 (ESP)）、加密和雜湊演算法、密鑰生存期以及配置 Internet 密鑰關聯 (IKE) 主模式和 IPsec 安全性關聯 (SA) 所必需的其他設定。 SA 是與密鑰資料相關聯的安全性設定協議。 在第一次 IKE 協商階段建立的 SA 被稱為 IKE 主模式 SA（亦稱為 ISAKMP 主模式 SA）。 IKE 主模式 SA 對 IKE 協商本身進行保護。 在第二次 IKE 協商階段建立的 SA 被稱為 IPsec SA（亦稱為 IKE 快速模式 SA，這是因為每個 IKE 快速模式協商都為每個方向進行 IPsec SA 協商）。 IPsec SA 對應用程式通訊流進行保護。

本節提供了有關以下重要 IPsec 策略概念的資訊：

•	IKE 協商過程
•	IPsec 策略篩選器
•	安全措施
•	IPsec 協議線格式
•	IKE 身分識別驗證
•	IKE 驗證方法和安全措施優先順序
•	安全協商選項

有關 IPsec 策略概念的詳細資料，請參閱 Microsoft Windows Server 2003 的說明及支援中心。 返回頁首

IPsec 策略篩選器

篩選器是 IPsec 策略最重要的組成部分。 如果您未在用戶端策略或伺服器策略中指定正確的篩選器，或者如果 IP 位址已更改，但該策略的篩選器卻未更新，則安全性就會得不到保障。 IPsec 篩選器被插入到電腦上的 TCP/IP 網路通訊協定堆棧的 IP 層，因此這些篩選器可以對所有入站或出站 IP 資料包進行檢查（篩選）。 除了稍有延遲之外（在兩台電腦之間協商安全性關係必然引起延遲），IPsec 對於終端使用者應用程式和作業系統服務來說是透明的。 篩選器依據 IPsec 策略中的安全性規則與相應的篩選器操作相關聯。 Windows IPsec 同時支援將 IPsec 隧道模式和 IPsec 傳輸模式用作此規則的選項。 IPsec 隧道模式規則的配置與 IPsec 傳輸模式規則的配置有很大差異。

與 IPsec 策略相關聯的篩選規則與防火牆規則類似。 通過使用 IP 安全性原則管理 Microsoft 管理主控台 (MMC) 嵌入式管理單元提供的圖形化使用者介面 (GUI)，可以將 IPsec 配置為根據源與目標地址組合以及特定協議和連接埠來允許或阻止特定類型的通訊流。

註：Windows IPsec 並不是功能全面並基於主機的防火牆，它也不支援動態篩選功能或有狀態篩選功能，例如在 TCP 握手期間跟蹤已建立的位以控制通訊流可以具有的流向。 瞭解 IPsec 篩選

篩選器列表僅僅是已知子網和基礎結構 IP 位址的清單。 重要的是，您要瞭解包含在所有規則中的全部篩選器是如何組合到一起以提供所需的入站和出站存取控制的。 本節提供了非常重要的詳細資料，通過這些詳細資料，您就可以瞭解 IPsec 篩選器是如何影響資料包處理的。

Windows Server 2003 IPsec 監視器 MMC 嵌入式管理單元提供了最詳細的 IPsec 篩選器順序視圖。 當 IPsec 服務處理一組 IPsec 策略規則時，篩選器被複製為兩類篩選器，從而對 IKE 協商的兩個階段進行控制：

1.	IKE 主模式篩選器。 這些篩選器僅使用 IPsec 策略中定義的篩選器源地址和目標地址來控制 IKE 主模式。 專用於 IKE 主模式的篩選器每個都有與之相關的 IKE 主模式協商策略，該策略定義了： • 使用金鑰交換設定為 IPsec 策略定義的 IKE 主模式安全措施，例如 Diffie Hellman 主要金鑰強度和用於保護 IKE 協商本身的密碼編譯演算法與完整性演算法。 • IKE 主模式生存期以及對根據同一主要金鑰產生的工作階段金鑰數的限制。 • 驗證方法。
2.	IKE 快速模式篩選器。 這些篩選器包含有關地址、協議和連接埠的全部篩選器資訊。 IKE 快速模式對此篩選器定義進行協商，以確定在 IPsec 安全性關聯對內部可以對哪些通訊流進行保護。 每個特定的篩選器都有相應的權值和一組安全措施，這些安全措施定義了： • 傳輸模式或隧道模式下的 AH 或 ESP 封裝選項。 • 密碼編譯演算法與完整性演算法列表。 • IPsec 安全性關聯的生存期（以KB和秒計）。 • 完全向前保密安全設定。

專用於 IKE 快速模式的篩選器就是對 IPsec 驅動程式指定的要強制實施的那些篩選器。 IPsec 驅動程式按照最高權值指定的順序來將所有入站和出站 IP 通訊流與這些篩選器進行匹配。 以下關於 IKE 協商過程的部分描述了 IKE 是如何使用這些策略控制來協商和管理 IPsec 安全性關聯的。

IPsec 策略中定義的篩選器之所以被看作“一般”篩選器，是因為它們可能已在該策略應用時被 IPsec 服務解釋。 在電腦上應用（或更改）IPsec 策略時，IPsec 服務將所有的一般篩選器解釋為特定的篩選器。 特定的篩選器具有內建的計算權值的演算法或順序，在選擇通訊流時，順序也被稱為篩選器的特定程度。 權值越大，篩選器就越特定。 所有這些特定篩選器都根據它們的權值排序。 篩選器權值是依次根據篩選器中可能定義的 IP 位址、協議和連接埠計算的。 這種方法確保策略中的規則順序、每個不同篩選器列表中的篩選器順序，不會對 IPsec 驅動程式在資料包處理期間強制實施的篩選行為產生影響。 資料包首先與最特定的篩選器進行匹配，從而最大程度地縮短根據全部篩選器處理每個資料包所需的時間。 與某個資料包相匹配的最特定篩選器所對應的篩選器操作就是對該資料包執行的唯一操作。 可以定義的最具一般性的篩選器就是與任何 IP 位址、所有協議和連接埠都匹配的那些篩選器。 例如，請考慮以下四個篩選器定義：

•	任何 IP 位址 <-> 任何 IP 位址，任何協議
•	任何 IP 位址 <-> 192.168.1.0/24，任何協議
•	任何 IP 位址 <-> 192.168.1.0/24，任何協議
•	任何 IP 位址 <-> 192.168.1.10/24，任何 TCP 源連接埠，目標連接埠為 25

“任何 IP 位址到任何 IP 位址”就是可以定義的最一般的篩選器。 僅有 Windows Server 2003 和 Windows XP Service Pack 2 (SP2) 支援此篩選器。 此篩選器通常與阻止操作配合使用以實現預設行為“全部拒絕”。如果使用此篩選器來阻止全部通訊流，則其餘更特定的篩選器可以被看作第一個篩選器的例外情況。 對於 Windows 2000 來說，受支援的最一般篩選器是“任何 IP 位址 <-> 子網，任何協議”或“任何 IP 位址 <-> 我的 IP 位址”（如果未使用子網）。

對於使用 TCP 通訊埠 25 從任何 IP 位址到 192.168.1.10 的入站通訊流以及從連接埠 25 發出的相應出站響應，全部四個篩選器都匹配。 由於第四個篩選器指定了目標 IP 位址、協議和連接埠號碼，所以它最為特定。 如果 IPsec 驅動程式強制實施全部這四個篩選器，則發往 TCP 通訊埠 25 的入站資料包將只與第四個篩選器（也就是最特定的篩選器）匹配。 如果遠程系統使用除連接埠 25 以外的其他連接埠來向 192.168.1.10 發送 TCP 通訊流，則此通訊流與第三個篩選器匹配。 最後，如果通訊流被發送到 192.168.1.0 子網中除 192.168.1.10 以外的任何 IP 位址，則第二個篩選器對於該通訊流來說就是最特定的篩選器。 潛在的篩選器設計問題

定義篩選器時，不應該使用某些源地址和目標地址組合。 如上所述，對於運行 Windows 2000 的主機而言，應該避免使用指定了“任何 IP 位址到任何 IP 位址”的篩選器。

一般來講，策略包含的篩選器越多，對資料包處理效能的影響就越大。 這方面的效能影響通常表現為輸送量下降、非頁面緩衝池核心記憶體利用率提高以及 CPU 利用率提高。 對效能產生的影響是很難精確估算的，這是因為此影響取決於電腦上的總體通訊流量、所處理的受 IPsec 保護的通訊流量以及 CPU 負載。 因此，在進行規劃時，應該考慮對 IPsec 策略設計進行效能測試。 除了在輸送量非常高的電腦上，幾百個篩選器的影響是不大可能被注意到的。

Windows 2000 未提供用於處理大量篩選器的最佳化措施。 IPsec 驅動程式必須按順序掃描整個篩選器列表以尋找相匹配的篩選器。

在 Windows XP 和 Windows Server 2003 中，採用了許多最佳化措施來提高篩選器處理速度，因此 IPsec 策略可以使用大量的篩選器。 使用了通用資料包分類器 (GPC) 驅動程式對具有“從 <IP 位址> 到 <IP 位址>”格式的篩選器（協議和連接埠不限）進行最佳化，因而尋找速度極快。 GPC 幾乎可以處理任意數目的這些篩選器，而輸送量不會降低。 因此，倘若有足夠的非分頁核心記憶體來容納整個篩選器列表，就可以很容易地支援使用“我的 IP 位址到 <特定免除 IP 位址>”格式的大型免除列表。 GPC 無法最佳化源和目標不具有特定 IP 位址的篩選器，這意味著“任何 IP 位址 <-> 特定 IP 位址（或子網）”篩選器將要求執行順序搜尋。 但是，實施措施相比 Windows 2000 已有改進。

使用“我的 IP 位址”在許多情況下也許是合適的，但對於具有許多 IP 位址的主機（如託管許多虛擬網站的 Web 服務器），也許會引起問題。 如果有大量的篩選器使用“我的 IP 位址”，則 IPsec 驅動程式資料包篩選操作可能會發生延遲。 在服務啟動期間以及發生 IP 位址改變事件時，IPsec 服務需要處理那些 過濾器。 延遲問題可能會引起安全性漏洞或者延遲 IPsec 安全連線的建立時間。 同樣，應該通過測試效能來確認特定策略設計的影響是否可以接受。

當允許或拒絕發往特定連接埠或協議的通訊流時，可能最適合使用“我的 IP 位址”。 例如，在 Woodgrove Bank 的 IPsec 策略設計中，使用了“我的 IP 位址”篩選器建立了一個更特定的篩選器，該篩選器允許在所有電腦之間使用明文收發 網際網路控制訊息通訊協定 (ICMP) (ICMP) 通訊流。

如果對組織中的移動用戶端分配了“我的 IP 位址 <-> 任何 IP 位址”規則，然後將其放在外部網中，則此移動用戶端在該環境中可能無法進行通訊。 如果允許該用戶端回退到使用明文，它在串連到每個目標時都會出現三秒鐘或更長時間的延遲。 如果目標使用 IKE 響應進行回覆，則 IKE 協商會失敗，這是因為 IKE 將無法使用域信任 (Kerberos) 來進行身分識別驗證。 顯然，如果將 RFC 1918 專用地址用作內部網路子網，則移動用戶端在串連至酒店、家用網路以及其他可能的內部網路時會受到影響。 如果移動用戶端遇到串連問題，它們在串連至其他網路時可能需要本地管理員權限以停止 IPsec 服務。 因此，當移動用戶端串連到內部網路時，可能需要使用域登入指令檔來檢查 IPsec 服務是否正在運行。

由於無法使用 IKE 協商來對使用多播地址和廣播位址的資料包通訊進行保護，所以 Windows 2000 最初未被設計成能夠為此類資料包提供過濾。 因此，多播資料包類型和廣播資料包類型是最初的預設免除（繞過 IPsec 篩選器）的部分內容。 請參閱 Microsoft 知識庫 (KB) 文章 811832“IPSec Default Exemptions Can Be Used to Bypass IPsec Protection in Some Scenarios”(http://support.microsoft.com/kb/811832)，以瞭解預設免除對安全性影響的深入闡釋以及預設情況下 Service Pack 3 為了除去某些免除而進行的更改。 在 Windows XP 和 Windows Server 2003 中，TCP/IP 與 IPsec 的整合已被增強為能夠對所有類型的 IP 資料包進行篩選。 然而，由於 IKE 無法為多播和廣播協商安全性，所以只提供了有限的篩選支援。 請參閱 KB 文章 810207“IPSec default exemptions are removed in Windows Server 2003”(http://support.microsoft.com/kb/810207)，以瞭解有關刪除預設免除以及對多播和廣播通訊流的篩選支援程度的詳細資料。 Windows XP SP2 與 Windows Server 2003 一樣，都支援“任何 IP 位址 <-> 任何 IP 位址”篩選功能。 返回頁首

IKE 協商過程

設計 IKE 協議的目的是為了協助在每台電腦之間安全地建立信任關係、協商安全性選項以及動態產生共用的、加密金鑰資料。 為了確保能夠成功並且安全地進行通訊，IKE 執行兩階段的操作：第一階段（主模式）協商和第二階段（快速模式）協商。 在每個階段，通過使用兩台電腦在安全協商期間認可的密碼編譯演算法和身分識別驗證演算法，使機密性和身分識別驗證得到保障。 主模式協商

在主模式協商期間，兩台電腦建立安全並且經過驗證的通道。 首先，對下列 IPsec 策略參數進行協商：密碼編譯演算法（DES 或 3DES）、完整性演算法（MD5 或 SHA1）、用於基本密鑰資料的 Diffie-Hellman 組（組 1、組 2 或 Windows Server 2003 中的組 2048）以及驗證方法（Kerberos V5 協議、密鑰憑證或預先共用金鑰）。 在對 IPsec 策略參數進行協商後，公用值的 Diffie-Hellman 交換就完成了。 Diffie-Hellman 演算法用來產生電腦之間的共用密鑰、對稱金鑰和加密金鑰。 Diffie-Hellman 交換完成後，每台電腦上的 IKE 服務都產生用於協助保護身分識別驗證的主要金鑰。 配合協商演算法和協商方法，主要金鑰用來驗證身份。 然後，通訊的發起方將潛在的 SA 提供給回應程式。 回應程式發送接受該內容的回複或者其他回複。 成功的 IKE 主模式協商將得到主模式 SA。 快速模式協商

在快速模式協商期間，建立一對 IPsec SA 來協助保護應用通訊流，此通訊流可以包括通過 TCP、使用者資料包通訊協定 (UDP) 以及其他協議發送的資料包。 首先，對下列策略參數進行協商：IPsec 協議線格式（AH 或 ESP）、用於確保完整性和進行身分識別驗證的雜湊演算法（MD5 或 SHA1）以及在要求進行加密時要使用的密碼編譯演算法（DES 或 3DES）。 在此期間，達成一個有關在所建立的 IPsec SA 對中傳送的 IP 資料包類型的公用協議。 IPsec 策略參數協商完畢後，就會重新整理或交換工作階段金鑰材料（每種演算法的加密金鑰和密鑰生存期，分別以千位元和秒計）。

每個 IPsec SA 都由安全參數指數 (SPI) 標識，後者將被插入到所發送的每個資料包的 IPsec 標題中。 一個 SPI 標識入站 IPsec SA，另一個 SPI 標識出站 IPsec SA。 IKE 主模式 SA 和 IPsec SA

每次使用 IPsec 來協助保護通訊流安全時，就會建立一個 IKE 主模式 SA 和兩個 IPsec SA。 在樣本方案中，為了在 CORPCLI 與 CORPSRV 之間進行受 IPSec 保護的通訊，建立了下列 SA：

CORPCLI [IP1] <-------- IKE main mode SA [IP1, IP2] -----> [IP2] CORPSRV

CORPCLI [IP1] ---------- IPsec SA [SPI=x] ------------------> [IP2] CORPSRV

CORPCLI [IP1] ---------- IPsec SA [SPI=x] ------------------> [IP2] CORPSRV

其中：

•	IP1 是 CORPCLI 的 IP 位址。
•	IP2 是 CORPSRV 的 IP 位址。
•	x 代表 SPI，它標識 CORPSRV 從 CORPCLI 獲得的入站 IPsec SA。
•	y 代表 SPI，它標識 CORPSRV 發往 CORPCLI 的出站IPsec SA。

正如本總結所述，CORPCLI 與 CORPSRV 之間的 IKE 主模式 SA 是雙向的。 兩台電腦都可以通過使用 IKE 主模式 SA 提供的保護來啟動快速模式協商。 IPsec SA 不依賴於上層協議的狀態。 例如，建立和結束 TCP 串連時，IPsec SA 的工作不會中斷，並且 IPsec SA 可以在 TCP 串連結束前到期。 在現有 IPsec SA 對的生存期到期前，IKE 將嘗試使用快速模式協商建立兩個新的 IPsec SA 對來進行重新協商，從而協助防止串連中斷。 雖然此過程通常被稱為重建 IPsec SA 密鑰，將實際上建立了兩個新的 IPsec SA。 IKE 主模式 SA 的壽命僅按時間以及已嘗試的 IPsec SA 數目度量（而不是按通過 IKE 協議傳輸的資料位元組數度量）。 IKE 主模式 SA 的到期與 IPsec SA 對無關。 如果需要新的 IPsec SA 對，則將根據需要自動重新協商 IKE 主模式 SA（在主模式 SA 到期後）。 按照 Internet 工程任務小組 (IETF) 的設計，IKE 必須能夠在任何一個方向上重建主模式 SA 密鑰並協商 IKE 快速模式。 因此，兩台電腦上的 IPsec 策略中為 IKE 主模式 SA 配置的驗證方法應該確保能夠在 IKE 主模式協商的發起方向上進行成功的身分識別驗證。 同樣，快速模式篩選器操作中的 IPsec 原則設定應該確保雙向快速模式協商成功。 返回頁首

安全措施

在 IKE 主模式協商期間，安全措施用來定義密碼編譯演算法、雜湊演算法以及 Diffie-Hellman 組，而 Diffie-Hellman 組用來建立主模式 SA 以及協助確保 IKE 協商通道的安全。 在快速模式協商期間，安全措施還用來定義封裝模式（傳輸模式或隧道模式）、IPsec 協議線格式（AH 或 ESP）、密碼編譯演算法和雜湊演算法以及用來建立快速模式入站和出站 SA 的密鑰生存期。 返回頁首

IPsec 封裝模式和 IPsec 協議線格式

IPsec 通過對 IP 承載進行加密保護來對 IP 資料包中的資料進行保護。 所提供的保護依賴於 IPsec 的使用方式以及 IPsec 協議線格式。 您可以以傳輸模式或隧道模式使用 IPsec。 IPsec 封裝模式

IPsec隧道模式最常用於對網路（如通過 Internet 實現的網站到網站連網）之間的網站到網站（也稱為網關到網關或路由器到路由器）通訊流進行保護。 使用 IPsec 隧道模式時，發送資料包的網關對整個原始 IP 資料包進行封裝，其方法是建立一個新的 IP 資料包並通過其中一種 IPsec 協議線格式（AH 或 ESP）對其進行保護。 有關 IPsec 隧道模式的資訊，請參閱 Windows Server 2003 部署工具包中的“Deploying Network Services”的“Deploying IPsec”一章，網址為 http://go.microsoft.com/fwlink/?LinkId=8195。

IPsec 傳輸模式用於對主機到主機的通訊進行保護，並且它是 Windows IPsec 的預設模式。 使用 IPsec 傳輸模式時，IPsec 僅對 IP 承載進行加密，而不對 IP 標題進行加密。 在傳輸模式下，Windows IPsec 主要用於協助保護端到端通訊（如用戶端與伺服器之間的通訊）。 IPsec 協議線格式

IPsec 支援兩種協議線格式：AH 和 ESP。 IPsec 傳輸模式用 IPsec 標題（AH 或 ESP）來封裝原始 IP 承載。 AH

AH 為整個資料包（既包括 IP 標題也包括資料包中包含的資料承載，IP 標題中允許在傳輸過程中發生改變的欄位除外）提供資料來源身分識別驗證、資料完整性以及反重放保護。 AH 未提供資料保密功能，這意味著它不對資料進行加密。 該資料可以被讀取但不能被修改，從而防止了電子欺騙。 如下圖所示，完整性和身分識別驗證是通過在 IP 標題與 TCP 資料之間放置 AH 標題提供的。

圖 A.1 資料包中的驗證頭
查看大圖

要使用 AH，在適當規則的屬性中，在“自訂安全措施設定”對話方塊中，選擇“資料和地址不加密的完整性 (AH)”複選框，然後指定要使用的完整性演算法。 ESP

ESP 提供了資料來源身分識別驗證、資料完整性、反重放保護以及僅用於 IP 承載的保密選項。 在傳輸模式下，ESP 未通過密碼總和檢查碼來保護整個資料包。 未對 IP 標題進行保護。 如下圖所示，ESP 標題被放置在 TCP 資料之前，ESP 尾端和 ESP 身分識別驗證尾端被放置在 TCP 資料之後。

圖 A.2 資料包中的 ESP 資料
查看大圖

要使用 ESP，在適當規則的屬性中，在“自訂安全措施設定”對話方塊中，選擇“資料完整性和加密 (ESP)”複選框，然後指定要使用的完整性演算法和密碼編譯演算法。 返回頁首

IKE 身分識別驗證

IKE 在電腦之間使用相互身分識別驗證以建立受信任通訊，並且，IKE 要求使用下列其中一種驗證方法：Kerberos V5 協議、電腦 X.509 V3 公開金鑰基礎結構 (PKI) 認證或預先共用金鑰。 兩個通訊端點必須有至少一種公用的驗證方法，否則通訊將會失敗。 IKE 身分識別驗證過程

在 IKE 協商期間，IKE 發起方為回應程式提供驗證方法列表。 回應程式使用發起方的源 IP 位址來確定 IKE 協商由哪個篩選器控制。 與回應程式 IPsec 策略中的篩選器相對應的驗證方法將被用來從發起方的列表中選擇一種驗證方法。 然後，回應程式進行回複，將雙方同意的驗證方法通知發起方。 即使選擇的驗證方法失敗，IKE 也不會提供一種途徑來嘗試使用另一種驗證方法。 如果身分識別驗證成功，並且主模式協商成功完成，則主模式 SA 將在 8 小時內有效。 如果 8 小時結束時仍在傳輸資料，則將自動重新協商主模式 SA。 IKE 驗證方法

選擇適合於 IPsec 策略的驗證方法非常重要。 IPsec 策略規則使篩選器中的每個 IP 位址與一個驗證方法列表相關聯，以便 IKE 可以確定與每個 IP 位址配合使用的驗證方法列表。 Kerberos V5 身分識別驗證協議

Kerberos V5 協議是 Windows 2000 和 Windows Server 2003 Active Directory 域的預設身分識別驗證標準。 域或受信任域中的任何電腦都可以使用這種驗證方法。

使用 Kerberos 驗證方法時，在主模式協商期間，每個 IPSec 對等方都以未加密格式將其電腦標識發送給另一對等方。 在主模式協商期間的身分識別驗證階段對整個標識承載進行加密之前，電腦標識是未加密的。 攻擊者可以發送 IKE 資料包來使相應的 IPSec 對等方暴露其電腦標識和域成員資格。 因此，為了確保與 網際網路連線的電腦的安全，建議您使用憑證驗證。

預設情況下，在 Windows 2000 到 Windows 2000 Service Pack 3 以及 Windows XP 中，IPsec 篩選不對 Kerberos 協議通訊流進行處理。 要對 Kerberos 協議通訊流進行 IPsec 篩選處理，您必須修改註冊表，然後添加適當的 IPsec 篩選器以確保此通訊流的安全。 有關 Windows 2000 和 Windows Server 2003 中的預設免除的資訊，請參閱 Microsoft 網站上的“Special IPsec considerations”以建立、修改和指派 IPSec 策略，網址為：
www.microsoft.com/resources/documentation/WindowsServ/
2003/standard/proddocs/en-us/sag_IPSECbpSpecial.asp。 密鑰憑證身分識別驗證

在 Windows 2000 Server 中，您可以使用認證服務來在機器憑證的整個壽命周期內為 IPsec 自動管理那些認證。 認證服務與 Active Directory 和組策略整合在一起，它通過啟用認證自動註冊和續訂以及提供一些與 IPsec 相容的預設憑證範本來簡化認證部署。 要使用認證來進行 IKE 身分識別驗證，您需定義所要使用的可接受根授權 (CA) 有序列表，而不是定義所要使用的特定認證。 兩台電腦在它們的 IPsec 策略配置中必須要有公用的根 CA，並且用戶端必須要有相關聯的機器憑證。

在認證選擇過程中，IKE 將執行一系列檢查以確保機器憑證的特殊要求得到滿足。 例如，機器憑證必須要有長度大於 512 位的公開金鑰並使用數位簽章密鑰用法。

註：在設定了進階選項“啟用強私密金鑰保護”的情況下從認證服務擷取的認證不適用於 IKE 身分識別驗證，這是因為您在 IKE 協商期間無法輸入必需的個人識別碼 (PIN)，因此無法訪問機器憑證的私密金鑰。 預先共用金鑰

如果您未使用 Kerberos 身分識別驗證，並且無權訪問 CA，則可以使用預先共用金鑰。 例如，在某些情況下，網路中的獨立電腦可能由於（通過電腦的域帳戶進行的）Kerberos 身分識別驗證和 CA 提供的認證都無法成功地進行 IKE 身分識別驗證而需要使用預先共用金鑰。

重要：預先共用金鑰容易實施，但使用不當會產生負面影響。 Microsoft 建議不要在 Active Directory 中使用預先共用金鑰身份認證，這是因為沒有安全地儲存體金鑰值，因此難以保密。 預先共用金鑰值以明文形式儲存在 IPsec 策略中。 本地 Administrators 組中的任何成員都可以查看本地 IPsec 策略，任何具有 Local System 使用者權限的系統服務都可以讀取本地 IPsec 策略。 預設情況下，域中任何已通過身分識別驗證的使用者都可以查看儲存在基於 Active Directory 的 IPsec 策略中的預先共用金鑰。 此外，如果攻擊者可以捕獲 IKE 協商資料包，攻擊者就可以利用發行的方法來發現預先共用金鑰值。
有關詳細資料，請參閱“Authentication Vulnerabilities in IKE and Xauth with Weak Pre-Shared Secrets”，網址為：http://go.microsoft.com/fwlink/?LinkId=18769。

預先共用金鑰身分識別驗證是為了實現互通性而提供的，它符合 RFC 標準。 如果您必須使用預先共用金鑰身分識別驗證，請使用 25 個字元或更長的隨機密鑰值，並且對每個 IP 位址對使用不同的預先共用金鑰。 這些措施會導致為每個目標產生不同的安全性規則，從而確保被破壞的預先共用金鑰只會危害那些共用該密鑰的電腦的安全。 IPsec CRL 檢查

如果使用基於認證的身分識別驗證，則還可以啟用 IPsec 憑證撤銷清單 (CRL) 檢查。 預設情況下，在 Windows 2000 中，在 IKE 憑證驗證期間不會自動進行 IPsec CRL 檢查。

要啟用 IPsec CRL 檢查

注意：錯誤地編輯註冊表可能會嚴重地破壞系統。 在對註冊表變更之前，您應該備份電腦上任何有價值的資料。

1.	在 HKEY_LOCAL_MACHINE/System/CurrentControlSet/ Services/PolicyAgent/ 下添加新的 Oakley 登錄機碼，並建立名為 StrongCrlCheck 的雙位元組項。
2.	對此項指定 0 與 2 之間的值，其中： • 值 0 禁用 CRL 檢查（這是 Windows 2000 中的預設值）。 • 如果值為 1，則將嘗試進行 CRL 檢查，並且僅當認證已被吊銷時才會導致認證驗證失敗（這是 Windows XP 和 Windows Server 2003 中的預設值）。 在進行 CRL 檢查期間遇到的其他故障（如無法訪問吊銷 URL）不會導致驗證認證操作失敗。 • 如果值為 2，則啟用強 CRL 檢查，這意味著必須進行 CRL 檢查，並且 CRL 處理期間遇到的任何錯誤都會導致認證驗證操作失敗。 請設定此註冊表值以增強安全性。
3.	執行下列其中一項操作： • 重新啟動電腦。 • 通過從命令提示字元運行 net stop policyagent 和 net start policyagent 命令，停止並接著重新啟動 IPsec 服務。 注：IPsec CRL 檢查不能保證認證驗證操作在認證被吊銷時立即失敗。 在將被撤銷憑證放入已更新發行 CRL 的時刻與執行 IPsec CRL 檢查的電腦檢索此 CRL 的時刻之間有一段延遲。 在當前 CRL 到期或下次發布 CRL 之前，電腦不會檢索新的 CRL。 CryptoAPI 將 CRL 緩衝在記憶體和 /Documents and Settings/UserName/Local Settings/Temporary Internet Files 中。 由於 CRL 不會由於電腦重新啟動而丟失，所以，如果發生 CRL 快取問題，重新啟動電腦並不能解決該問題。

返回頁首

IKE 驗證方法和安全措施優先順序

您可以配置僅指定了一種驗證方法或一種安全措施的 IPsec 規則。 此外，您也可以指定驗證方法和安全措施的優先列表。 優先順序將應用於驗證方法或安全措施，因此，您可以按照從最優先到最不優先的順序來指定每種方法。 例如，您可以同時指定 Kerberos V5 協議和密鑰憑證身分識別驗證來作為驗證方法，但對 Kerberos 協議指定較高的優先順序，如下圖所示。

圖 A.3 驗證方法優先順序

如果用戶端嘗試串連至 CORPSRV，卻只接受使用密鑰憑證來進行身分識別驗證，則 CORPSRV 使用此驗證方法並繼續進行通訊。 使用所選驗證方法時，IKE 協商必須成功，否則通訊會被阻止。 即使協商失敗，IKE 也不會嘗試使用另一種驗證方法。 同一原理也適用於安全措施，例如，ESP 可能比 AH 優先。 返回頁首

安全協商選項

在篩選器操作的屬性中，您可以在“安全措施”選項卡中配置 IPsec 策略是否允許回退到使用明文（回退到未受保護的通訊）、是否允許入站通過和工作階段金鑰 PFS。 在“金鑰交換設定”對話方塊中，您可以在規則的一般屬性中配置主要金鑰 PFS。 回退到使用明文

如果允許回退到使用明文，則 IPsec 將儘可能地保護通訊流的安全（如果串連另一端的電腦支援策略包含補充性篩選器操作和篩選器的 IPsec），但是，如果對等方沒有與安全協商請求相對應的 IPsec 策略，則以不安全的方式發送通訊流。 如果對等方在三秒鐘內未響應安全協商請求，則建立用於明文通訊流的 SA（軟 SA）。 軟 SA 允許進行正常的 TCP/IP 通訊，不進行 IPsec 封裝。 請記住，雖然 IPsec 可能無法對此類通訊流進行保護，但別的應用程式也許能確保此通訊流的安全（例如，通訊流可能受輕量型目錄存取通訊協定 (LDAP) 加密或遠端程序呼叫 (RPC) 身分識別驗證機制的保護）。 如果對等方在三秒鐘內未響應，並且安全協商失敗，則與相應篩選器相匹配的通訊將被阻止。

“回退到使用明文”設定允許與下列電腦進行互操作：

•	運行比 Wndows 2000 舊的作業系統的電腦
•	運行未配置 IPsec 策略的 Wndows 2000 或更舊系統的電腦
•	運行不支援 IPsec 的非 Microsoft 作業系統的電腦

要啟用或禁用“回退到使用明文”，在“安全措施”選項卡上，在篩選器操作的屬性中，選擇或清除“允許和不支援 IPSec 的電腦進行不安全的通訊”複選框。

對於用戶端策略來說，您可以啟用或禁用此選項。 如果啟用了此選項，並且伺服器未響應用戶端的協商安全性請求，則可以允許此用戶端“回退到使用明文”。 如果清除了此複選框，並且伺服器未響應用戶端的協商安全性請求，則通訊將被阻止。 在某些情況下，允許“回退到使用明文”非常有用。 但是，僅當未接收到回覆時，IKE 才允許“回退到使用明文”。 為了確保安全，Windows IPsec 不允許在 IKE 協商失敗時或者在 IKE 協商期間（在接收到回覆之後）遇到諸如身分識別驗證失敗或無法達成安全參數協議之類的錯誤時進行未受保護的通訊。

對於最初的部署，建議您選中此複選框，以便當伺服器上的 IPsec 處于禁用狀態時用戶端可以“回退到使用明文”並建立初始串連。 入站通過

如果啟用入站通過功能，則對於正常的入站 TCP/IP 通訊流（未受 IPsec 保護的通訊流，例如 TCP SYN 資料包）來說，如果它與篩選器操作的相關入站篩選器相匹配，則它會被接受。 上層協議響應資料包（例如，TCP SYN ACK 資料包）與相應的出站篩選器相匹配並觸發安全協商。 協商好兩個 IPsec SA 之後，兩個方向上的通訊流都受 IPSec 保護。 “入站通過”選項允許伺服器使用預設響應規則來對用戶端啟動安全協商。 如果在用戶端 IPsec 策略中啟用了預設響應規則，用戶端就不需要維護包含伺服器 IP 位址的篩選器。 如果在用戶端 IPsec 策略中未啟用預設響應規則，您就不需要在伺服器 IPsec 策略中啟用“入站通過”選項。 此外，在串連到 Internet 的電腦上，絕對不應該啟用此選項。

要啟用或禁用入站通過，在篩選器操作的屬性的“安全措施”選項卡中，選擇或清除“允許不安全的通訊，但總是用 IPsec 響應”複選框。 工作階段金鑰和主要金鑰 PFS

PFS 是一種機制，此機制確定主要金鑰的現有密鑰資料是否可用來派生新的工作階段金鑰。 PFS 確保單個密鑰受到的危害只會影響到受 PFS 保護的資料，而不會影響到整個通訊。 為此，PFS 確保用於保護資料轉送的密鑰不能用來產生其他密鑰。 工作階段金鑰 PFS 在使用時不需要進行重新驗證，與主要金鑰 PFS 相比，所需資源較少。 如果啟用了工作階段金鑰 PFS，則會執行新的 Diffie-Hellman 金鑰交換以產生主要金鑰的新的重建密鑰資訊。

如果在伺服器策略中啟用了工作階段金鑰 PFS，則還必須在用戶端策略中啟用它。 您可以啟用工作階段金鑰 PFS，方法如下：在“金鑰交換設定”對話方塊中，在規則的常規屬性中，選擇“使用工作階段金鑰完全向前保密 (PFS)”複選框。 主要金鑰 PFS 要求進行重新驗證，因而耗費的資源較多。 對於進行的每一次快速模式協商，主要金鑰 PFS 都要求進行新的主模式協商。 您可以通過選擇“主要金鑰完全向前保密 (PFS)”複選框來配置主要金鑰 PFS。 如果在伺服器策略中啟用了主要金鑰 PFS，則不需要在用戶端策略中啟用它。 由於啟用此選項會產生很大的開銷，因此，建議您只在危險的環境中才啟用工作階段金鑰 PFS 或主要金鑰 PFS。在那些環境中，IPsec 通訊流可能會暴露給老練的攻擊者，他們會嘗試攻破 IPsec 提供的強加密保護