[筆記](méi) 計(jì)算機(jī)網(wǎng)絡(luò)安全：（7）虛擬專網(wǎng)技術(shù)

網(wǎng)絡(luò)安全基礎(chǔ)

internet協(xié)議的安全性

Web安全

網(wǎng)絡(luò)掃描和網(wǎng)絡(luò)監(jiān)聽(tīng)

防火墻原理與設(shè)計(jì)

入侵檢測(cè)系統(tǒng)

VPN技術(shù)

---

目錄

• [筆記](méi) 計(jì)算機(jī)網(wǎng)絡(luò)安全：（7）虛擬專網(wǎng)技術(shù)
• • 7.1 虛擬專網(wǎng)的基本概念和分類
  • • 7.1.1 虛擬專網(wǎng)的概念
    • 7.1.2 虛擬專網(wǎng)的特點(diǎn)
    • 7.1.3 虛擬專網(wǎng)的分類
    • • Access 虛擬專網(wǎng)：遠(yuǎn)程訪問(wèn)虛擬專網(wǎng)
      • Intranet 虛擬專網(wǎng)：網(wǎng)關(guān)-網(wǎng)關(guān)，企業(yè)內(nèi)部虛擬專網(wǎng)
      • Extranet 虛擬專網(wǎng)：網(wǎng)關(guān)-網(wǎng)關(guān)，企業(yè)外部虛擬專網(wǎng)
    • 7.1.4 虛擬專網(wǎng)的關(guān)鍵技術(shù)
    • • 密碼技術(shù)
      • 身份認(rèn)證技術(shù)
      • 隧道技術(shù)
      • 密鑰管理技術(shù)
      • 訪問(wèn)控制技術(shù)
  • 7.2 PPTP、IPSec、TLS等隧道協(xié)議
  • • 7.2.1 第二層隧道協(xié)議
    • • 代表協(xié)議
      • 優(yōu)缺點(diǎn)
    • 7.2.2 第三層隧道協(xié)議
    • • 代表協(xié)議
  • 7.3 IPSec 的原理及應(yīng)用
  • • 7.3.1 IP安全概述
    • • IP安全的必要性
      • IPSec安全體系結(jié)構(gòu)
      • IPSec協(xié)議簇
      • IPSec的功能
      • 術(shù)語(yǔ)補(bǔ)充
      • IPSec的實(shí)現(xiàn)
      • IPSec的傳輸模式
      • IPSec的隧道模式
      • IPsec協(xié)議概述
    • 7.3.2 IPSec的工作原理
    • • 外出處理
      • 進(jìn)入處理
    • 7.3.3 IPSec中的主要協(xié)議
    • • AH（Authentication Header，驗(yàn)證頭部協(xié)議） RFC2402
      • ESP
      • IKE
    • 7.3.4 IPSec 虛擬專網(wǎng)的構(gòu)成和部署
    • • IPSec 虛擬專網(wǎng)的構(gòu)成
      • IPSec 虛擬專網(wǎng)的部署
      • IPSec虛擬專網(wǎng)的缺陷
    • 7.3.5 IPSec的實(shí)現(xiàn)
  • 7.4 TLS 的原理及應(yīng)用
  • • 7.4.1 SSL 概述
    • • SSL VPN的特點(diǎn)
      • 概述
      • 組成
    • 7.4.2 TLS 的原理
    • • 握手協(xié)議
      • TLS記錄協(xié)議
      • 警告協(xié)議
      • TLS 虛擬專網(wǎng)的實(shí)現(xiàn)方式
      • SSL 虛擬專網(wǎng)的分類
    • 7.4.3 TLS 虛擬專網(wǎng)的優(yōu)缺點(diǎn)
    • 7.4.4 TLS 虛擬專網(wǎng)的應(yīng)用
    • 7.4.5 TLS VPN 與 IPSec VPN比較
  • 7.5 PPTP 虛擬專網(wǎng)的原理及應(yīng)用
  • • 7.5.1 PPTP 虛擬專網(wǎng)概述
    • 7.5.2 PPTP 虛擬專網(wǎng)的原理
    • 7.5.3 PPTP 虛擬專網(wǎng)的優(yōu)缺點(diǎn)
    • 7.6.4 PPTP與L2TP
  • 7.6 MPLS 虛擬專網(wǎng)的原理及應(yīng)用
  • • 7.6.1 MPLS 虛擬專網(wǎng)概述
    • 7.6.2 MPLS 虛擬專網(wǎng)的原理
    • 7.6.3 MPLS 虛擬專網(wǎng)的優(yōu)缺點(diǎn)
    • 7.6.2 MPLS 虛擬專網(wǎng)的原理
    • 7.6.3 MPLS 虛擬專網(wǎng)的優(yōu)缺點(diǎn)

---

7.1 虛擬專網(wǎng)的基本概念和分類

• 信息在傳輸中可能泄密
• 信息傳輸中可能失真
• 信息的來(lái)源可能是偽造的
• 信息傳輸?shù)某杀究赡芎芨?/li>

7.1.1 虛擬專網(wǎng)的概念

虛擬專網(wǎng)：VPN(Virtual Private Network)

定義：是指將物理上分布在不同地點(diǎn)的網(wǎng)絡(luò)通過(guò)公用網(wǎng)絡(luò)連接而構(gòu)成邏輯上的虛擬子網(wǎng)。

7.1.2 虛擬專網(wǎng)的特點(diǎn)

• 費(fèi)用低
• 安全保障
• 服務(wù)質(zhì)量 保證（QoS）
• 可擴(kuò)充性和靈活性
• 可管理性

7.1.3 虛擬專網(wǎng)的分類

Access 虛擬專網(wǎng)：遠(yuǎn)程訪問(wèn)虛擬專網(wǎng)

• Access VPN與傳統(tǒng)的遠(yuǎn)程訪問(wèn)網(wǎng)絡(luò)相對(duì)應(yīng)
• 遠(yuǎn)端用戶只要能使用合法IP地址訪問(wèn)Internet，接入到遠(yuǎn)端網(wǎng)關(guān)即可、可以利用VPN系統(tǒng)在公眾網(wǎng)上建立一個(gè)從客戶端到網(wǎng)關(guān)的安全傳輸通道。
• 降低了長(zhǎng)途電話，租用光纖及技術(shù)支持的費(fèi)用
• 適用于企業(yè)內(nèi)部人員流動(dòng)頻繁或遠(yuǎn)程辦公的情況

Intranet 虛擬專網(wǎng)：網(wǎng)關(guān)-網(wǎng)關(guān)，企業(yè)內(nèi)部虛擬專網(wǎng)

• 如果要進(jìn)行企業(yè)內(nèi)部異地分支機(jī)構(gòu)的互聯(lián)，可以使用Intranet VPN方式，這是所謂的網(wǎng)關(guān)對(duì)網(wǎng)關(guān)VPN
• Intranet VPN在異地兩個(gè)網(wǎng)絡(luò)的網(wǎng)關(guān)之間建立了一個(gè)加密的VPN隧道，兩端的內(nèi)部網(wǎng)絡(luò)可以通過(guò)該VPN隧道安全地進(jìn)行通信，就好像和本地網(wǎng)絡(luò)通信一樣

Extranet 虛擬專網(wǎng)：網(wǎng)關(guān)-網(wǎng)關(guān)，企業(yè)外部虛擬專網(wǎng)

• 如果一個(gè)企業(yè)希望將客戶、供應(yīng)商、合作伙伴或興趣群體連接到企業(yè)內(nèi)部網(wǎng)，可以使用Extranet VPN。
• Extranet VPN其實(shí)也是一種網(wǎng)關(guān)對(duì)網(wǎng)關(guān)的VPN，與Intranet VPN不同的是，它需要在不同企業(yè)的內(nèi)部網(wǎng)絡(luò)之間組建，需要有不同協(xié)議和設(shè)備之間的配合和不同的安全配置

7.1.4 虛擬專網(wǎng)的關(guān)鍵技術(shù)

• 隧道技術(shù)
• 密碼技術(shù)
• 密鑰管理技術(shù)
• 身份認(rèn)證技術(shù)
• 訪問(wèn)控制技術(shù)

密碼技術(shù)

• 密碼技術(shù)是實(shí)現(xiàn)VPN的關(guān)鍵核心技術(shù)之一。
• 一般情況下，在VPN實(shí)現(xiàn)中：
  • 雙方大量的通信流量的加密使用對(duì)稱加密算法，運(yùn)算量小、速度快。眾多算法中最常用的是DES（Data Encryption Standard）、AES（Adva nced Encryption Standard）和IDEA（Interna tional Data Encryption Algorithm）
  • 而在管理、分發(fā)對(duì)稱加密的密鑰上采用更加安全的非對(duì)稱加密技術(shù)。

身份認(rèn)證技術(shù)

• VPN需要解決的首要問(wèn)題就是網(wǎng)絡(luò)上用戶與設(shè)備的身份認(rèn)證。
• 從技術(shù)上說(shuō)，身份認(rèn)證基本上可以分為兩類：非PKI體系和PKI體系的身份認(rèn)證。
  • 非PKI體系：UID+PASSWORD
    • PAP，Password Authentication Protocol，口令認(rèn)證協(xié)議
    • CHAP，Challenge Handshake Authentication Protocol，挑戰(zhàn)握手認(rèn)證協(xié)議
    • MS CHAP，Microsoft Challenge Handshake Authentication Protocol，微軟CHAP
    • RADIUS，Remote Authentication Dial In User Service ，遠(yuǎn)程認(rèn)證撥號(hào)用戶服務(wù)
  • PKI體系
    • 常用的方法是依賴于CA（Certificate Authority，數(shù)字證書(shū)簽發(fā)中心）所簽發(fā)的符合X.509規(guī) 范的標(biāo)準(zhǔn)數(shù)字證書(shū)。
    • 通信雙方交換數(shù)據(jù)前，需先確認(rèn)彼此的身份，交換彼此的數(shù)字證書(shū)，雙方將用此證書(shū)進(jìn)行比較，只有比較結(jié)果正確，雙方才開(kāi)始交換數(shù)據(jù) ；否則，不能進(jìn)行后續(xù)通信

隧道技術(shù)

• 隧道技術(shù)通過(guò)對(duì)數(shù)據(jù)進(jìn)行封裝，在公共網(wǎng)絡(luò)上建立一條數(shù)據(jù)通道（隧道），讓數(shù)據(jù)包通過(guò)這條隧道傳輸。
• 生成隧道的協(xié)議有三種：
  • 第二層隧道協(xié)議
    • 第二層隧道協(xié)議是在數(shù)據(jù)鏈路層進(jìn)行的，先把各種網(wǎng)絡(luò)協(xié)議封裝到PPP包中，再把整個(gè)數(shù)據(jù)包裝入隧道協(xié)議中，這種經(jīng)過(guò)兩層封裝的數(shù)據(jù)包由第二層協(xié)議進(jìn)行傳輸
      • L2F（RFC 2341，Layer 2 Forwarding）
      • PPTP（RFC 2637，Point to Point Tunneling Protocol）
      • L2TP（RFC 2661，Layer Two Tunneling Protocol）。
    • 采用L2TP還是PPTP實(shí)現(xiàn)VPN取決于要把控制權(quán)放在NAS(Network Access Server)還是用戶手中。
    • L2TP比PPTP更安全，因?yàn)長(zhǎng)2TP接入服務(wù)器能夠確定用戶從哪里來(lái)。L2TP主要用于比較集中的、固定的VPN用戶，而PPTP比較適合移動(dòng)的用戶。
  • 第三層隧道協(xié)議
    • 在網(wǎng)絡(luò)層進(jìn)行的，把各種網(wǎng)絡(luò)協(xié)議直接裝入隧道協(xié)議中，形成的數(shù)據(jù)包依靠第三層協(xié)議進(jìn)行傳輸
      • IPSec (IP Security)，是目前最常用的VPN解決方案
      • GRE(RFC 2784，General Routing Encapsulation)
        • GRE主要用于源路由和終路由之間所形成的隧道。例如，將通過(guò)隧道的報(bào)文用一個(gè)新的報(bào)文頭（GRE報(bào)文頭）進(jìn)行封裝然后帶著隧道終點(diǎn)地址放入隧道中。當(dāng)報(bào)文到達(dá)隧道終點(diǎn)時(shí) ，GRE報(bào)文頭被剝掉，繼續(xù)根據(jù)原始報(bào)文的目標(biāo)地址進(jìn)行尋址。
        • GRE隧道技術(shù)是用在路由器中的，可以滿足Extranet VPN以及Intranet VPN的需求
  • 第四層隧道協(xié)議
    • 工作在傳輸層,把網(wǎng)絡(luò)層數(shù)據(jù)包或應(yīng)用數(shù)據(jù)裝入隧道協(xié)議中，形成的數(shù)據(jù)包依靠傳輸層協(xié)議進(jìn)行傳輸
      • TLS（ Transport Layer Security）：傳輸層安全性協(xié)議
      • TLS/SSL VPN 主要為遠(yuǎn)程訪問(wèn)VPN（Access-VPN)

密鑰管理技術(shù)

• 在VPN應(yīng)用中密鑰的分發(fā)與管理非常重要。密鑰的分發(fā)有兩種方法：
  • 手工配置：要求密鑰更新不要太頻繁，否則管理工作量太大，因此只適合于簡(jiǎn)單網(wǎng)絡(luò)的情況。
  • 采用密鑰交換協(xié)議動(dòng)態(tài)分發(fā)：采用軟件方式動(dòng)態(tài)生成密鑰，保證密鑰在公共網(wǎng)絡(luò)上安全地傳輸而不被竊取，適合于復(fù)雜網(wǎng)絡(luò)的情況，而且密鑰可快速更新，可以顯著提高VPN應(yīng)用的安全性

訪問(wèn)控制技術(shù)

• 訪問(wèn)控制決定了誰(shuí)能夠訪問(wèn)系統(tǒng)、能訪問(wèn)系統(tǒng)的何種資源以及如何使用這些資源
• 采取適當(dāng)?shù)脑L問(wèn)控制措施能夠阻止未經(jīng)允許的用戶有意或無(wú)意地獲取數(shù)據(jù)，或者非法訪問(wèn)系統(tǒng)資源等。

7.2 PPTP、IPSec、TLS等隧道協(xié)議

隧道協(xié)議

• 指通過(guò)一個(gè)公用網(wǎng)絡(luò)（通常是 Internet）建立的一條穿過(guò)公用網(wǎng)絡(luò)的安全的、邏輯上的隧道。在隧道中，數(shù)據(jù)包被重新封裝發(fā)送

VPN的主要封裝協(xié)議:

• 第2層的隧道協(xié)議
  • –包括PPTP、L2TP、L2F等
• 第3層的隧道協(xié)議
  • –包括IPSec、GRE等
• 第4層的隧道協(xié)議
  • –包括SSL、TLS等。

7.2.1 第二層隧道協(xié)議

代表協(xié)議

• PPTP
  • 讓遠(yuǎn)程用戶撥號(hào)連接到本地ISP、通過(guò)Internet安全遠(yuǎn)程訪問(wèn)公司網(wǎng)絡(luò)資源。
  • PPTP具有兩種不同的工作 模式，即被動(dòng)模式和主動(dòng)模式。
• L2F
  • 可以在多種介質(zhì)（如ATM、 幀中繼、IP網(wǎng)）上建立多協(xié)議的安全虛擬專用網(wǎng)。
  • 它將鏈路層的協(xié)議（如 HDLC，PPP， ASYNC等）封裝起來(lái)傳送
• L2TP
  • 在上述兩種協(xié)議的基礎(chǔ)上產(chǎn)生。 適合組建遠(yuǎn)程接入方式的VPN。

優(yōu)缺點(diǎn)

• 優(yōu)點(diǎn)
  • 簡(jiǎn)單易行
• 缺點(diǎn)
  • 可擴(kuò)展性都不好
  • 不提供內(nèi)在的安全機(jī)制，不能保證企業(yè)和企業(yè)的外部客戶及供應(yīng)商之間會(huì)話的保密性

7.2.2 第三層隧道協(xié)議

代表協(xié)議

• IPSec
  • 專為IP設(shè)計(jì)提供安全服務(wù)的一種協(xié)議
• GRE Generic Routing Encapsulation
  • 規(guī)定了如何用一種網(wǎng)絡(luò)協(xié)議去封裝另一種網(wǎng)絡(luò)協(xié)議的方法。
• MPLS Multiprotocol Label Switching
  • 引入了基于標(biāo)記的機(jī)制。
  • 它把選路和轉(zhuǎn)發(fā)分開(kāi)，用標(biāo)簽來(lái)規(guī)定一個(gè)分組通過(guò)網(wǎng)絡(luò)的路徑

7.3 IPSec 的原理及應(yīng)用

7.3.1 IP安全概述

• 大型網(wǎng)絡(luò)系統(tǒng)內(nèi)運(yùn)行多種網(wǎng)絡(luò)協(xié)議（TCP/IP、IPX/SP X和NETBEUA等）這些網(wǎng)絡(luò)協(xié)議并非為安全通信設(shè)計(jì)
• IP協(xié)議維系著整個(gè)TCP/IP協(xié)議的體系結(jié)構(gòu)，除了數(shù)據(jù)鏈路層外，TCP/IP的所有協(xié)議的數(shù)據(jù)都是以IP數(shù)據(jù)報(bào) 的形式傳輸?shù)摹?/li>
• TCP/IP協(xié)議簇有兩種IP版本：IPv4、IPv6。IPv6簡(jiǎn)化了IP頭，其數(shù)據(jù)報(bào)更加靈活，同時(shí)IPv6還增加了對(duì)安全性的考慮

IP安全的必要性

• IPv4在設(shè)計(jì)之初沒(méi)有考慮安全性，導(dǎo)致在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)很容易受到各式各樣的攻擊：比如偽造IP包地址、修改其內(nèi)容、重播以前的包以及在傳輸途中攔截并查看包的內(nèi)容等。因此，通信雙方不能保證收到IP數(shù)據(jù)報(bào)的真實(shí)性
• 為了加強(qiáng)因特網(wǎng)的安全性，從1995年開(kāi)始，IETF著手制定了一套用于保護(hù)IP通信的IP安全協(xié)議（IP Security，IPSec）。IPSec彌補(bǔ)了IPv4在協(xié)議設(shè)計(jì)時(shí)缺乏安全性考慮的不足。

IPSec安全體系結(jié)構(gòu)

• IPSec（IP Security）是一種由IETF設(shè)計(jì)的端到端的確保IP層通信安全的機(jī)制。
• IPSec不是一個(gè)單獨(dú)的協(xié)議，而是一組協(xié)議，IPSec協(xié)議的定義文件包括了12個(gè)RFC文件和幾十個(gè)Internet草案，已經(jīng)成為工業(yè)標(biāo)準(zhǔn)的網(wǎng)絡(luò)安全協(xié)議。
• IPSec在IPv6中是必須支持的，而在IPv4中是可選的

IPSec協(xié)議簇

• IPSec協(xié)議簇主要包括兩個(gè)安全協(xié)議：AH協(xié)議和ESP協(xié)議
  • AH協(xié)議（Authentication Header，驗(yàn)證頭）：可以進(jìn)行數(shù)據(jù)源身份驗(yàn)證、保障數(shù)據(jù)的完整性以及防止相同數(shù)據(jù)包在因特網(wǎng)重放
  • ESP協(xié)議（Encapsulating Security Payload，封裝安全載荷）：具有所有AH的功能，還可以利用加密技術(shù)保障數(shù)據(jù)機(jī)密性。
• 雖然AH和ESP都可以提供身份認(rèn)證，但它們有2點(diǎn)區(qū)別：
  • ESP要求使用高強(qiáng)度的加密算法，會(huì)受到許多限制。
  • 多數(shù)情況下，使用AH的認(rèn)證服務(wù)已能滿足要求，相對(duì)來(lái)說(shuō)，ESP開(kāi)銷較大。
• 有兩套不同的安全協(xié)議意味著可以對(duì)IPSec網(wǎng)絡(luò)進(jìn)行更細(xì)粒度的控制，選擇安全方案可以有更大的靈活度
• AH和ESP可以單獨(dú)使用，也可以組合使用，可以在兩臺(tái)主機(jī)、兩臺(tái)安全網(wǎng)關(guān)（防火墻和路由器），或者主機(jī)與安全網(wǎng)關(guān)之間使用
• IKE（Internet Key Exchange）
  • IKE協(xié)議負(fù)責(zé)密鑰管理，定義了通信實(shí)體間進(jìn)行身份認(rèn)證、協(xié)商加密算法以及生成共享的會(huì)話密鑰的方 法。
  • IKE將密鑰協(xié)商的結(jié)果保留在安全聯(lián)盟（SA）中，供AH和ESP以后通信時(shí)使用
• DOI（Domain of Interpretation）
  • 解釋域DOI定義IKE所沒(méi)有定義的協(xié)商的內(nèi)容；
  • DOI為使用IKE進(jìn)行協(xié)商SA的協(xié)議統(tǒng)一分配標(biāo)識(shí)符。共享一個(gè)DOI的協(xié)議從一個(gè)共同的命名空間中選擇安 全協(xié)議和變換、共享密碼以及交換協(xié)議的標(biāo)識(shí)符等
  • DOI將IPSec的這些RFC文檔聯(lián)系到一起

IPSec的功能

• 保證數(shù)據(jù)完整性
  • IPSec通過(guò)驗(yàn)證算法保證數(shù)據(jù)從發(fā)送方到接收方的傳送過(guò)程中的任何數(shù)據(jù)篡改和丟失都可以被檢測(cè)。
• 保證數(shù)據(jù)機(jī)密性
  • IPSec通過(guò)加密算法使只有真正的接收方才能獲取真正的發(fā)送內(nèi)容，而他人無(wú)法獲知數(shù)據(jù)的真正內(nèi)容

術(shù)語(yǔ)補(bǔ)充

• SA（Security Association，安全關(guān)聯(lián)）
  • 是兩個(gè)IPSec實(shí)體（主機(jī)、安全網(wǎng)關(guān)）之間經(jīng)過(guò)協(xié)商建立起來(lái)的一種協(xié)定。
  • 內(nèi)容包括采用何種IPSec協(xié)議（AH還是ESP）、運(yùn)行模式（傳輸模式還是隧道模式）、驗(yàn)證算法、加密算法 、加密密鑰、密鑰生存期、抗重放窗口、計(jì)數(shù)器等，從而決定了保護(hù)什么、如何保護(hù)以及誰(shuí)來(lái)保護(hù)。
  • 可以說(shuō)SA是構(gòu)成IPSec的基礎(chǔ)。
  • 每個(gè)SA由三元組（SPI，IP目的地址，IPSec協(xié)議）來(lái)唯一標(biāo)識(shí)
    • SPI（Security Parameter Index，安全參數(shù)索引）是32位的安全參數(shù)索引，用于標(biāo)識(shí)具有相同IP地址和相同安全協(xié)議的不同的SA，它通常被放在AH或ESP頭中
    • IP目的地址：它是SA的終端地址。
    • IPSec協(xié)議：采用AH或ESP。
  • SA是單向的，在一次通信中，IPSec需要建立兩個(gè)SA，一個(gè)用于入站通信，另一個(gè)用于出站通信
• SAD（Security Association Database，安全關(guān)聯(lián)數(shù)據(jù)庫(kù)）
  • SAD并不是通常意義上的“數(shù)據(jù)庫(kù)”，而是將所有的SA以某種數(shù)據(jù)結(jié)構(gòu)集中存儲(chǔ)的一個(gè)列表。
  • 對(duì)于外出的流量，如果需要使用IPSec處理，然而相應(yīng)的SA不存在，則IPSec將啟動(dòng)IKE來(lái)協(xié)商出一個(gè)SA，并存儲(chǔ)到SAD中
  • 對(duì)于進(jìn)入的流量，如果需要進(jìn)行IPSec處理，IPSec將從IP包中得到三元組（SPI,DST,Protocol），并利用這個(gè)三元組在SAD中查找一個(gè)SA。
• SP（Security Policy，安全策略）
  • 決定對(duì)IP數(shù)據(jù)包提供何種保護(hù)，并以何種方式實(shí)施保護(hù)。
  • SP主要根據(jù)源IP地址、目的IP地址、入數(shù)據(jù)還是出數(shù)據(jù)等來(lái)標(biāo)識(shí)。
  • IPSec還定義了用戶能以何種粒度來(lái)設(shè)定自己的安全策略，不僅可以控制到IP地址，還可以控制到傳輸層協(xié)議或者TCP/UDP端口等
• SPD（Security Policy Database，安全策略數(shù)據(jù)庫(kù)）
  • SPD也不是通常意義上的“數(shù)據(jù)庫(kù)”，而是將所有的SP以某種數(shù)據(jù)結(jié)構(gòu)集中存儲(chǔ)的列表。 （包處理過(guò)程中，SPD和SAD兩個(gè)數(shù)據(jù)庫(kù)要聯(lián)合使用）
  • 當(dāng)接收或?qū)⒁l(fā)出IP包時(shí)，首先要查找SPD來(lái)決定如何進(jìn)行處理。存在3種可能的處理方式：丟棄、不用 IPSec和使用IPSec。
    • 丟棄：流量不能離開(kāi)主機(jī)或者發(fā)送到應(yīng)用程序，也不能進(jìn)行轉(zhuǎn)發(fā)。
    • 不用IPSec：對(duì)流量作為普通流量處理，不需要額外的IPSec保護(hù)。
    • 使用IPSec：對(duì)流量應(yīng)用IPSec保護(hù)，此時(shí)這條安全策略要指向一個(gè)SA。對(duì)于外出流量，如果該SA尚不存在，則啟動(dòng)IKE進(jìn)行協(xié)商，把協(xié)商的結(jié)果連接到該安全策略上。

SPD示例

srcdes處理隧道本地端點(diǎn)隧道對(duì)方端點(diǎn)

B	A	ESP	RB	A
B	A	轉(zhuǎn)發(fā)	無(wú)	無(wú)

IPSec的實(shí)現(xiàn)

• IPSec的實(shí)現(xiàn)方式有兩種：傳輸模式（Trans port Mode）和隧道模式（Tunnel Mode）
• AH和ESP都支持這兩種模式，因此有四種組合：
  • 傳輸模式的AH
  • 隧道模式的AH
  • 傳輸模式的ESP
  • 隧道模式的ESP

IPSec的傳輸模式

• 采用傳輸模式時(shí)，IPSec只對(duì)IP數(shù)據(jù)包的凈荷進(jìn)行加密或認(rèn)證。
• 封裝數(shù)據(jù)包繼續(xù)使用原IP頭部，只對(duì)部分域進(jìn)行修改。
• 而IPSec協(xié)議頭部插入到原IP頭部和傳輸層頭部之間。
• 只用于兩臺(tái)主機(jī)之間的安全通信

正常網(wǎng)絡(luò)IP頭傳輸層數(shù)據(jù)報(bào)

應(yīng)用AH		IP頭	AH	傳輸層數(shù)據(jù)報(bào)
應(yīng)用ESP		IP頭	ESP	傳輸層數(shù)據(jù)報(bào)
應(yīng)用AH和ESP	IP頭	AH	ESP	傳輸層數(shù)據(jù)報(bào)

IPSec的隧道模式

• 隧道模式保護(hù)的是整個(gè)IP包。通常情況下，只要IPSec雙方有一方是安全網(wǎng)關(guān)或路由器，就必須使用隧道模式
• 采用隧道模式時(shí)，IPSec對(duì)整個(gè)IP數(shù)據(jù)包進(jìn)行加密或認(rèn)證。
• 產(chǎn)生一個(gè)新的IP頭，IPSec頭被放在新IP頭和原IP數(shù)據(jù)包之間，組成一新IP頭。

正常網(wǎng)絡(luò)原始IP頭傳輸層數(shù)據(jù)報(bào)

應(yīng)用AH	外部IP頭	ESP頭	原始IP頭	傳輸層數(shù)據(jù)報(bào)	ESP尾
應(yīng)用ESP	外部IP頭	AH頭	原始IP頭	傳輸層數(shù)據(jù)報(bào)

IPsec協(xié)議概述

AH、ESP或AH+ESP既可以在隧道模式中使用，又可以在傳輸模式中使用

功能/模式認(rèn)證頭協(xié)議（AH）封裝安全載荷（ESP）ESP+AH

訪問(wèn)控制	1	1	1
認(rèn)證	1	1	1
消息完整性	1	1	1
重放保護(hù)	1	1	1
機(jī)密性	0	1	1

7.3.2 IPSec的工作原理

• IPSec的工作原理類似于包過(guò)濾防火墻，可以把它看做是包過(guò)濾防火墻的一種擴(kuò)展。
• IPSec網(wǎng)關(guān)通過(guò)查詢安全策略數(shù)據(jù)庫(kù)（SPD）決定對(duì)接收到的IP數(shù)據(jù)包進(jìn)行轉(zhuǎn)發(fā)、丟棄或IPSec處理
• IPSec網(wǎng)關(guān)可以對(duì)IP數(shù)據(jù)包只進(jìn)行加密或認(rèn)證，也可以對(duì)數(shù)據(jù)包同時(shí)實(shí)施加密和認(rèn)證。
• 無(wú)論是進(jìn)行加密還是進(jìn)行認(rèn)證，IPSec都有兩種工作模式：傳輸模式和隧道模式

外出處理

• 外出處理過(guò)程中，傳輸層的數(shù)據(jù)包流入IP層。IP層檢索SPD數(shù)據(jù)庫(kù)，判斷應(yīng)為這個(gè)包提供哪些服務(wù)。可能有以下幾種情況：
  • 丟棄：簡(jiǎn)單丟掉
  • 不應(yīng)用安全服務(wù)：為載荷增添IP頭，然后分發(fā)IP包
  • 應(yīng)用安全服務(wù)：如果已建立SA，則返回指向該SA的指針；如果未建立SA，則調(diào)用IKE建立SA。按照建立的SA，增添適當(dāng)?shù)腁H和ESP頭。

進(jìn)入處理

• 收到IP包后，如果包內(nèi)沒(méi)有IPSec頭，則根據(jù)安全策略對(duì)包進(jìn)行檢查，決定如何處理：
  • 丟棄：直接丟棄；
  • 應(yīng)用安全服務(wù)：如果沒(méi)有ipsec頭，說(shuō)明包有問(wèn)題，丟棄；
  • 不應(yīng)用安全服務(wù)：將包載荷傳給上層協(xié)議處理
• 如果IP包中包含了IPSec包：
  • 從IP包中提取三元組(SPI，目標(biāo)地址，協(xié)議)在SAD中檢索
  • 根據(jù)協(xié)議值交給AH層或ESP層處理。
  • 協(xié)議載荷處理完之后，要在SPD中查詢策略，驗(yàn)證SA使用是否得當(dāng)

7.3.3 IPSec中的主要協(xié)議

IPSec中主要由AH、ESP和IKE三個(gè)協(xié)議來(lái)實(shí)現(xiàn)加密、認(rèn)證和管理交換功能。

• AH
  • RFC 2402將AH服務(wù)定義如下：
    • 非連接的數(shù)據(jù)完整性校驗(yàn)；
    • 數(shù)據(jù)源點(diǎn)認(rèn)證；
    • 可選的抗重放攻擊服務(wù)。
  • AH有兩種實(shí)現(xiàn)方式：傳輸方式和隧道方式
  • AH只涉及認(rèn)證，不涉及加密
• ESP
  • ESP協(xié)議主要用于對(duì)IP數(shù)據(jù)包進(jìn)行加密，此外也對(duì)認(rèn)證提供某種程度的支持。
  • ESP協(xié)議也有兩種工作模式：傳輸模式和隧道模式。
• IKE
  • 用于動(dòng)態(tài)建立安全關(guān)聯(lián)（SA，Security Association）

AH（Authentication Header，驗(yàn)證頭部協(xié)議） RFC2402

• AH對(duì)IP層的數(shù)據(jù)使用驗(yàn)證算法MAC，從而對(duì)完整性進(jìn)行保護(hù)。
• MAC（Message Authentication Codes，報(bào)文驗(yàn)證碼），即報(bào)文摘要，是從HASH算法演變而來(lái)，又稱為HMAC，如HMAC-MD5、HMAC-SHA1、HMAC-RIPEMD-160。
• 通過(guò)HMAC可以檢測(cè)出對(duì)IP包的頭部和載荷的修改，從而保護(hù)IP包的內(nèi)容完整性和來(lái)源可靠性。
• 不同IPSec系統(tǒng)可用的HMAC算法可能不同，但HMAC-MD5和HMAC-SHA1是必須實(shí)現(xiàn)的
• AH協(xié)議和TCP、UDP協(xié)議一樣，是被IP協(xié)議封裝的協(xié)議之一，可以由IP協(xié)議頭部中的協(xié)議字段判斷，AH的協(xié)議號(hào)是51

AH傳輸模式

• AH插入到IP頭部（包括IP選項(xiàng)字段）之后，傳輸層協(xié)議（如TCP、UDP）或者其他IPSec協(xié)議之前
• 被AH驗(yàn)證的區(qū)域是整個(gè)IP包（可變字段除外），包括IP包頭部，因此源IP地址、目的IP地址是不能修改的，否則會(huì)被檢測(cè)出來(lái)
• 然而，如果該包在傳送的過(guò)程中經(jīng)過(guò)NAT網(wǎng)關(guān)，其源/目的IP地址將被改變，將造成到達(dá)目的地址后的完整性驗(yàn)證失敗。因此，AH在傳輸模式下和NAT是沖突的，不能同時(shí)使用，或者可以說(shuō)AH不能穿越NAT

正常網(wǎng)絡(luò)IP頭部(含選項(xiàng)字段)TCP頭部(含選項(xiàng)字段)數(shù)據(jù)

AH傳輸	IP頭部(含選項(xiàng)字段)	AH頭部	TCP頭部(含選項(xiàng)字段)	數(shù)據(jù)

AH隧道模式

• 在隧道模式中，AH插入到原始IP頭部之前，然后在AH之前再增加一個(gè)新的IP頭部
• 隧道模式下，AH驗(yàn)證的范圍也是整個(gè)IP包，因此上面討論的AH和NAT的沖突在隧道模式下也存在。
• 在隧道模式中，AH可以單獨(dú)使用，也可以和ESP一起嵌套使用。

正常網(wǎng)絡(luò)IP頭部(含選項(xiàng)字段)TCP頭部(含選項(xiàng)字段)數(shù)據(jù)

AH隧道	新IP頭部(含選項(xiàng)字段)	AH頭部	IP頭部(含選項(xiàng)字段)	TCP頭部(含選項(xiàng)字段)	數(shù)據(jù)

數(shù)據(jù)完整性檢查

• 在發(fā)送方，整個(gè)IP包和驗(yàn)證密鑰被作為輸入，經(jīng)過(guò)HMAC算法計(jì)算后得到的結(jié)果被填充到AH頭部的“驗(yàn)證數(shù)據(jù)”字段中

• 在接收方，整個(gè)IP包和驗(yàn)證算法所用的密鑰也被作為輸入，經(jīng)過(guò)HMAC算法計(jì)算的結(jié)果和AH頭部的“驗(yàn)證數(shù)據(jù)”字段進(jìn)行比較

• 如果一致，說(shuō)明該IP包數(shù)據(jù)沒(méi)有被篡改，內(nèi)容是真實(shí)可信的

• ipv4不定字段（在通信過(guò)程中可能被合法修改）：

  • 在計(jì)算HMAC時(shí)先臨時(shí)用0填充；

  • 另外，AH頭部的驗(yàn)證數(shù)據(jù)字段在計(jì)算之前也要用0填充，計(jì)算之后再填充驗(yàn)證結(jié)果。

• 應(yīng)被AH保護(hù)的內(nèi)容（在通信過(guò)程應(yīng)該不被修改）：

  • 固定字段；
  • AH頭中除“驗(yàn)證數(shù)據(jù)”以外的其他字段；
  • 數(shù)據(jù)：指經(jīng)過(guò)AH處理之后，在AH頭部后面的數(shù)據(jù)。
    • 傳輸方式下，指TCP、UDP或ICMP等傳輸層數(shù)據(jù)
    • 隧道模式下，指被封裝的原IP包。

ESP

• 與AH相比，ESP驗(yàn)證的數(shù)據(jù)范圍要小一些。ESP協(xié)議規(guī)定了所有IPSec系統(tǒng)必須實(shí)現(xiàn)的驗(yàn)證算法：HMAC-MD5、HMAC-SHA1、NULL。
• ESP的加密采用的是對(duì)稱密鑰加密算法。不同的IPSec實(shí)現(xiàn)，其加密算法也有所不同。為了保證互操作性，ESP協(xié)議規(guī)定了所有IPSec系統(tǒng)都必須實(shí)現(xiàn)的加密算法：DES-CBC、NULL。
• 但ESP協(xié)議規(guī)定加密和認(rèn)證不能同時(shí)為NULL。即加密和認(rèn)證必須至少選其一
• ESP協(xié)議和TCP、UDP協(xié)議一樣，是被IP協(xié)議封 裝的協(xié)議之一，可以由IP協(xié)議頭部中的協(xié)議字 段判斷，ESP的協(xié)議號(hào)是50

ESP傳輸模式

• 保護(hù)的是IP包的載荷；
• ESP插入到IP頭部（包括IP選項(xiàng)字段）之后，任何被IP協(xié)議所封裝的協(xié)議（如傳輸層協(xié)議TCP、UDP、ICMP，或者IPSec協(xié)議）之前
• ESP加密不包括SPI、序號(hào)字段和驗(yàn)證數(shù)據(jù)；（不包括頭）
• ESP的驗(yàn)證不包括IP頭部：
  • 優(yōu)點(diǎn)：不存在與NAT沖突的問(wèn)題；
  • 缺點(diǎn)：除了ESP頭部之外，任何IP頭部字段都可以修改，只要保證其校驗(yàn)和計(jì)算正確，接收端就不能檢測(cè)出這種修改。所以，ESP傳輸模式的驗(yàn)證服務(wù)要比AH傳輸模式弱一些。如果需要更強(qiáng)的驗(yàn)證服務(wù)并且通信雙方都是公有IP地址，應(yīng)該采用AH來(lái)驗(yàn)證，或者將AH認(rèn)證與ESP驗(yàn)證同時(shí)使用

正常網(wǎng)絡(luò)IP頭部(含選項(xiàng)字段)TCP頭部(含選項(xiàng)字段)數(shù)據(jù)

ESP傳輸	IP頭部(含選項(xiàng)字段)	ESP頭部	TCP頭部(含選項(xiàng)字段)	數(shù)據(jù)	ESP尾部	ESP驗(yàn)證數(shù)據(jù)

ESP隧道模式

• 保護(hù)的是整個(gè)IP包，對(duì)整個(gè)IP包進(jìn)行加密；
• 在隧道模式中，ESP插入到原始IP頭部之前，然后在ESP之前再增加一個(gè)新的IP頭部
• ESP隧道模式的驗(yàn)證和加密能夠提供比ESP傳輸模式更加強(qiáng)大的安全功能，因?yàn)樗淼滥Ｊ较聦?duì)整個(gè)原始IP包進(jìn)行驗(yàn)證和加密，可以提供數(shù)據(jù)流加密服務(wù)；而ESP在傳輸模式下不能提供流加密服務(wù)，因?yàn)樵础⒛康腎P地址不被加密。
• 不過(guò)，隧道模式將占用更多的帶寬，因?yàn)樵黾恿艘粋€(gè)額外的IP頭部。
• 盡管ESP隧道模式的驗(yàn)證功能不像AH傳輸模式或隧道模式那么強(qiáng)大，但ESP隧道模式提供的安全功能已經(jīng)足夠了

正常網(wǎng)絡(luò)IP頭部(含選項(xiàng)字段)TCP頭部(含選項(xiàng)字段)數(shù)據(jù)

ESP隧道	新IP頭部(含選項(xiàng)字段)	ESP頭部	IP頭部(含選項(xiàng)字段)	TCP頭部(含選項(xiàng)字段)	數(shù)據(jù)	ESP尾部	ESP驗(yàn)證數(shù)據(jù)

ESP處理

• 根據(jù)ESP采用的模式來(lái)具體處理。
• 注意：
  • 密文是得到驗(yàn)證的，而驗(yàn)證中包括未加密的明文.
  • 所以：外出報(bào)文—先加密；進(jìn)入報(bào)文—先驗(yàn)證

AH & ESP

• IPSec協(xié)議使用認(rèn)證頭標(biāo)AH和封裝安全凈載ESP兩種安全協(xié)議來(lái)提供安全通信。兩種安全協(xié)議都分為隧道模式和傳輸模式。
• 傳輸模式用在主機(jī)到主機(jī)的通信，隧道模式用在其它任何方式的通信

IKE

IKE協(xié)議分兩個(gè)階段：

• 第一階段：建立IKE安全關(guān)聯(lián)，即在通信雙方之間協(xié)商密鑰
• 第二階段：利用這個(gè)既定的安全關(guān)聯(lián)為IPSec建立安全通道。

Internet密鑰交換

• Internet密鑰交換（IKE）用于動(dòng)態(tài)建立SA
• IKE屬于一種混合型協(xié)議，由RFC2409定義，包含了3個(gè)不同協(xié)議的有關(guān)部分：ISAKMP、O akley和SKEME ，還定義了自己的兩種密鑰交換方式。
• IKE并非為IPSec專用，只要其他協(xié)議需要， 都可用它協(xié)商具體的安全服務(wù)。

ISAKMP協(xié)議

• ISAKMP（Internet Security Association Key Mana gement Protocol，Internet安全聯(lián)盟密鑰管理協(xié)議）：RFC2408。
• 定義了協(xié)商、建立、修改和刪除SA的過(guò)程和包格式。
• ISAKMP只是為協(xié)商、修改、刪除SA的方法提供了一個(gè)通用的框架，并沒(méi)有定義具體的SA格式。這個(gè)通用的 框架是與密鑰交換獨(dú)立的，可以被不同的密鑰交換協(xié)議使用。
• ISAKMP報(bào)文可以利用UDP或者TCP，端口都是500，一般情況下常用UDP協(xié)議

ISAKMP協(xié)議報(bào)文

• ISAKMP報(bào)文的頭部是固定長(zhǎng)度的，包含了維護(hù)狀態(tài)、處理載荷必要的信息

• 發(fā)起方Cookie（Initiator Cookie）：64位

  • Cookie可以幫助通信雙方確認(rèn)一個(gè)ISAKMP報(bào)文是否真的來(lái)自對(duì)方。
  • 在發(fā)起方，如果收到的某報(bào)文的應(yīng)答方Cookie字段和以前收到的該字段不同，則丟棄該報(bào)文；同樣，在應(yīng)答方，如果收到的某報(bào)文的發(fā)起方Cookie和以前收到的該字段不同，則丟棄該報(bào)文。這種機(jī)制可以防止DOS攻擊。
  • 盡管Cookie的生成方法在實(shí)現(xiàn)不同的ISAKMP時(shí)可能不同，但無(wú)論發(fā)起方還是響應(yīng)方，Cookie必須滿足兩個(gè)條件：
    • Cookie必須是用各自的機(jī)密信息生成的，該機(jī)密信息不能從Cookie中推導(dǎo)出來(lái)；
    • 對(duì)于一個(gè)SA，其Cookie是惟一的，也就是說(shuō)對(duì)于一次SA協(xié)商過(guò)程，Cookie不能改變。
  • 常用的一個(gè)生成Cookie的方法是對(duì)下述信息進(jìn)行HASH（MD5、SHA1或其他HASH算法）之后，取結(jié)果的前64位： 源IP地址＋目的IP地址＋UDP源端口＋UDP目的端口＋隨機(jī)數(shù)＋當(dāng)前日期＋當(dāng)前時(shí)間

• 應(yīng)答方Cookie(Responder Cookie): 64位

  • 應(yīng)答方的Cookie，緊跟在發(fā)起方Cookie之后

• 下一個(gè)載荷（Next Payload）：4位

  • 表示緊跟在ISAKMP頭部之后的第一個(gè)載荷的類型值。

• 主版本（Major Version）：4位

  • 表示ISAKMP協(xié)議的主版本號(hào)。

• 次版本（Minor Version）：4位

  • 表示ISAKMP協(xié)議的次版本號(hào)。

• 交換類型（Exchange Type）：8位

  • 表示該報(bào)文所屬的交換類型

• 標(biāo)志（Flags）：8位

  • 目前只有后3位有用，其余保留，用0填充。后3位的含義從最后一位往前依次為：
    • 加密位（encryption），0x01。加密位如果是1，表示ISAKMP頭部后面的所有載荷都被加密了；如果是0，表示載荷是明文，沒(méi)有加密。
    • 提交位（commit），0x02。用于確保在發(fā)送被保護(hù)的數(shù)據(jù)之前完成SA協(xié)商。
    • 純驗(yàn)證位（Authentication Only），0x04。主要由哪些希望為ISAKMP引入密鑰恢復(fù)機(jī)制的人使用。

• 報(bào)文ID（Message ID）：32位

  • 包含的是由第二階段協(xié)商的發(fā)起方生成的隨機(jī)值，這個(gè)惟一的報(bào)文標(biāo)識(shí)可以惟一確定第二階段的協(xié)議狀態(tài)。

• 報(bào)文長(zhǎng)度（length）：32位

  • 以字節(jié)為單位表示了ISAKMP整個(gè)報(bào)文（頭部+若干載荷）的總長(zhǎng)度。

ISAKMP載荷

• ISAKMP雙方交換的內(nèi)容稱為載荷（payload ）。對(duì)于一個(gè)用基于ISAKMP的密鑰管理協(xié)議 交換的消息來(lái)說(shuō)，其構(gòu)建方法是：將ISAKMP所有載荷鏈接到一個(gè)ISAKMP頭。
• 目前定義了13種載荷，它們都是以相同格式的頭開(kāi)始的

ISAKMP載荷頭部

不論何種載荷，都有一個(gè)相同格式的載荷頭部

• 下一個(gè)載荷（Next Payload）：8位
  • 表示緊跟在本載荷后面的下一個(gè)載荷的類型。
  • 第一個(gè)載荷的類型在ISAKMP頭部中指明，最后一個(gè)載荷的Next Payload類型為0。
• 保留（reserved）：8位，全0
• 載荷長(zhǎng)度（Payload Length）：16位
  • 以字節(jié)為單位表示的載荷長(zhǎng)度（包括載荷頭部），定義了每個(gè)載荷的邊界

ISAKMP協(xié)商階段

• 階段1
  • 這個(gè)階段要協(xié)商的SA可以稱為ISAKMP SA（在IKE中可以稱為 IKE SA），該SA是為了保證階段2的安全通信。
• 階段2
  • 這個(gè)階段要協(xié)商的SA是密鑰交換協(xié)議最終要協(xié)商的SA，當(dāng)IKE為IPSec協(xié)商時(shí)可以稱為IPSec SA，是保證AH或者ESP的安全通信。
  • 階段2的安全由階段1的協(xié)商結(jié)果來(lái)保證。階段1所協(xié)商的一個(gè)SA可以用于協(xié)商多個(gè)階段2的SA。

ISAKMP交換類型

• 交換類型定義的是在通信雙方所傳送的載荷的類型和順序，比如一方先發(fā)送什么載荷，另一方應(yīng)如何應(yīng)答等。這些交換模式的區(qū)別在于對(duì)傳輸信息的保護(hù)程度不同，并且傳輸?shù)妮d荷多少也不同
• ISAKMP本身沒(méi)有定義具體的密鑰交換技術(shù)。對(duì)于IPSec而言，已定義的密鑰交換就是IKE。IKE交換的最終結(jié)果是一個(gè)通過(guò)驗(yàn)證的密鑰以及建立在雙方同意基礎(chǔ)上的安全聯(lián)盟SA

IKE交換模式

• IKE基于兩個(gè)階段ISAKMP來(lái)建立安全聯(lián)盟SA，第一階段建立SA，第二階段用IKE SA建立IPSec的SA
• 第一階段
  • 主模式
  • 積極模式/野蠻模式 （建立IKE SA，建立驗(yàn)證過(guò)的密鑰，是其他交換的前提條件）
• 第二階段
  • 快速模式（為IPSec協(xié)商安全服務(wù)）

IKE身份認(rèn)證方式

• 基于預(yù)共享字符串（Pre_Shared Key）
  • 雙方事先通過(guò)某種方式商定好一個(gè)雙方共享的字符串
• 基于數(shù)字簽名（Digital Signature）
  • 利用數(shù)字證書(shū)來(lái)表示身份，利用數(shù)字簽名算法計(jì)算出一個(gè)簽名來(lái)驗(yàn)證身份。
• 基于公開(kāi)密鑰（Public Key Encryption）
  • 利用對(duì)方的公開(kāi)密鑰加密身份，通過(guò)檢查對(duì)方發(fā)來(lái)的該HASH 值作認(rèn)證。
• 基于修正的公開(kāi)密鑰（Revised Public Key Encrypt ion）
  • 對(duì)上述方式進(jìn)行修正

IKE第一階段

IKE第二階段

一個(gè)完整的IPSec的工作原理

7.3.4 IPSec 虛擬專網(wǎng)的構(gòu)成和部署

IPSec 虛擬專網(wǎng)的構(gòu)成

IPSec 虛擬專網(wǎng)的部署

IPSec虛擬專網(wǎng)的缺陷

• IPSec VPN通信性能低。由于IPSec VPN在 安全性方面比較高，影響了它的通信性能
• IPSec VPN需要客戶端軟件，可能帶來(lái)了與其他系統(tǒng)軟件之間兼容性問(wèn)題的風(fēng)險(xiǎn)
• 安裝和維護(hù)困難
• 實(shí)際全面支持的系統(tǒng)比較少，很少有能運(yùn)行在其它PC系統(tǒng)平臺(tái)的，如Mac、Linux、Solaris 等
• 不易解決網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)和穿越防火墻的問(wèn)題

7.3.5 IPSec的實(shí)現(xiàn)

• FreeS/WAN是Linux操作系統(tǒng)中包含的IPsec VPN實(shí)現(xiàn)方案。
• 在網(wǎng)上可以找到其開(kāi)放的源代碼下載網(wǎng)址： www.freeswan.org

7.4 TLS 的原理及應(yīng)用

7.4.1 SSL 概述

• SSL VPN也稱做傳輸層安全協(xié)議（TLS）VPN

• TLS協(xié)議主要用于HTTPS協(xié)議中，TLS也可以作為構(gòu)造VPN的技術(shù)

• TLS VPN的最大優(yōu)點(diǎn)是用戶不需要安裝和配置客戶端軟件。

• 只需要在客戶端安裝一個(gè)IE瀏覽器即可。

• 由于TLS協(xié)議允許使用數(shù)字簽名和證書(shū)，故它能提供強(qiáng)大的認(rèn)證功能。

SSL VPN的特點(diǎn)

• SSL VPN可在NAT代理裝置上以透明模式工作
• SSL VPN不會(huì)受到安裝在客戶端與服務(wù)器之間的防火墻等NAT設(shè)備的影響，穿透能力強(qiáng)
• SSL VPN將遠(yuǎn)程安全接入延伸到IPSec VPN擴(kuò)展不到的地方，降低了部署和支持費(fèi)用
• 客戶端安全檢查和授權(quán)訪問(wèn)等操作，實(shí)現(xiàn)起來(lái)更加方便
• SSL VPN可以在任何地點(diǎn)，利用任何設(shè)備，連接到相應(yīng)的網(wǎng)絡(luò)資源上。可以說(shuō)從功能上講，SSL VPN是企業(yè)遠(yuǎn)程安全接入的最佳選擇

概述

• SSL（Secure Socket Layer）安全套接層是一種運(yùn)行在兩臺(tái)機(jī)器之間的安全通道協(xié)議；也可以運(yùn) 行在SSL代理和PC之間
• 功能：保護(hù)傳輸數(shù)據(jù)（加密），識(shí)別通信機(jī)器（認(rèn)證）
• SSL提供的安全通道是透明的，幾乎所有基于TCP的協(xié)議稍加改動(dòng)就可以直接運(yùn)行于SSL之上
• 目前，IETF將SSL作了標(biāo)準(zhǔn)化，推出TLS傳輸層安全協(xié)議（RFC 2246）整合取代，它工作在TCP之上 。TLS1.0與SSL3.0的差別非常微小

組成

• 握手協(xié)議：
  • 對(duì)服務(wù)器進(jìn)行認(rèn)證
  • 確立用于保護(hù)數(shù)據(jù)傳輸?shù)募用苊荑€
• 記錄協(xié)議
  • 傳輸數(shù)據(jù)
• 告警協(xié)議
• SSL連接分為兩個(gè)階段，即握手和數(shù)據(jù)傳輸階段；傳輸任何應(yīng)用數(shù)據(jù)之前必須先完成握手

7.4.2 TLS 的原理

握手協(xié)議

功能

• 協(xié)商SSL協(xié)議的版本
• 協(xié)商加密套件
• 協(xié)商密鑰參數(shù)
• 驗(yàn)證通訊雙方的身份(對(duì)客戶端的身份認(rèn)證可選)
• 建立SSL連接

SSL握手過(guò)程

• 無(wú)客戶端認(rèn)證的全握手過(guò)程

• 會(huì)話恢復(fù)過(guò)程

• 有客戶端認(rèn)證的全握手過(guò)程

TLS記錄協(xié)議

• 保護(hù)傳輸數(shù)據(jù)的私密性，對(duì)數(shù)據(jù)進(jìn)行加密和解密
• 驗(yàn)證傳輸數(shù)據(jù)的完整性，計(jì)算報(bào)文的摘要
• 提高傳輸數(shù)據(jù)的效率，對(duì)報(bào)文進(jìn)行壓縮
• 保證數(shù)據(jù)傳輸?shù)目煽亢陀行?/li>

工作流程

警告協(xié)議

• 警告協(xié)議用于提示何時(shí)TLS協(xié)議發(fā)生了錯(cuò)誤，或者兩個(gè)主機(jī)之間的會(huì)話何時(shí)終止。
• 只有在TLS協(xié)議失效時(shí)告警協(xié)議才會(huì)被激活

TLS 虛擬專網(wǎng)的實(shí)現(xiàn)方式

在企業(yè)的防火墻后面放置一個(gè)TLS代理服務(wù)器

用戶欲安全地連接到公司網(wǎng)絡(luò)

• 首先要在瀏覽器上輸入一個(gè)URL(Universal Resource Locator)
• 該連接請(qǐng)求將被TLS代理服務(wù)器取得
• 用戶通過(guò)身份驗(yàn)證
• TLS代理服務(wù)器提供用戶與各種不同應(yīng)用服務(wù)器之間的連接

SSL 虛擬專網(wǎng)的分類

基于Web代理的SSL VPN

• 無(wú)須安裝任何客戶端，真正的跨平臺(tái)方案
• 僅支持基于Web方式的訪問(wèn)
• 非Web應(yīng)用需要進(jìn)行應(yīng)用轉(zhuǎn)換，將基于C/S的Email 、FTP、SSH等應(yīng)用以Web的形式重新實(shí)現(xiàn)，實(shí)現(xiàn)起來(lái)復(fù)雜
• 對(duì)于Web頁(yè)面中的鏈接，需要進(jìn)行URL替換
• 優(yōu)點(diǎn)：可以用于任何客戶端，兼容各種平臺(tái)訪問(wèn)，智能終端能無(wú)縫支持
• 缺點(diǎn)：支持的應(yīng)用少，需要為新的應(yīng)用進(jìn)行Web轉(zhuǎn)化
• 內(nèi)網(wǎng)服務(wù)器鏈接： https://sslvpnip/http/serverip/path/xx.html
  • 需要將該頁(yè)面中的所有的鏈接全部替換為類似的鏈接，包括靜態(tài)鏈接、動(dòng)態(tài)鏈接等
• 存在問(wèn)題：
  • 性能影響較大
  • 由于Web技術(shù)繁多，替換不完全

基于端口轉(zhuǎn)發(fā)的SSL VPN

• 對(duì)于FTP、EMAIL、OA、TELNET、遠(yuǎn)程桌面、數(shù)據(jù)庫(kù)等用戶經(jīng)常使用的C/S應(yīng)用，如果采用Web應(yīng)用轉(zhuǎn)換，對(duì)每一種應(yīng)用單獨(dú)處理，工作量很大；此外，也改變了用戶的使用習(xí)慣，不為用戶所接受

• 對(duì)于這些應(yīng)用，采用端口轉(zhuǎn)發(fā)技術(shù)，客戶端需要運(yùn)行一個(gè)較小的ActiveX插件或Java applet程序，在本地端口監(jiān)聽(tīng)；訪問(wèn)企業(yè)內(nèi)網(wǎng)的應(yīng)用數(shù)據(jù)發(fā)送到該監(jiān)聽(tīng)端口，該程序?qū)⑹盏降臄?shù)據(jù)通過(guò)瀏覽器的SSL連接傳輸?shù)骄W(wǎng)關(guān)，網(wǎng)關(guān)再轉(zhuǎn)發(fā)給內(nèi)網(wǎng)服務(wù)器。

• 支持多種TCP應(yīng)用

• 端口轉(zhuǎn)發(fā)原理

基于隧道的SSL VPN

• 采用跟IPSecVPN類似的技術(shù)，需要安裝客戶端軟件，以及虛擬網(wǎng)卡
• 到內(nèi)網(wǎng)服務(wù)器的IP報(bào)文（虛擬IP→內(nèi)網(wǎng)服務(wù)器）會(huì)被客戶端軟件進(jìn)行SSL協(xié)議封裝（真實(shí)IP→SSL VPN網(wǎng)關(guān)地址），到對(duì)端的SSLVPN網(wǎng)關(guān)設(shè)備再解密解封裝，還原為原始IP報(bào)文，交給內(nèi)網(wǎng)服務(wù)器
• 能支持基于TCP、UDP、ICMP協(xié)議的各種應(yīng)用
• 因工作在套接字層，無(wú)IPSecVPN的NAT穿越問(wèn)題
• 缺點(diǎn)：平臺(tái)兼容性不夠好
• 開(kāi)源代碼：OpenVPN

7.4.3 TLS 虛擬專網(wǎng)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

• 無(wú)須安裝客戶端軟件
• 適用于大多數(shù)設(shè)備
• 適用于大多數(shù)操作系統(tǒng)
• 不需要對(duì)網(wǎng)絡(luò)做改變
• 支持網(wǎng)絡(luò)驅(qū)動(dòng)器訪問(wèn)
• 較強(qiáng)的資源控制能力
• 可繞過(guò)防火墻進(jìn)行訪問(wèn)
• 費(fèi)用低且有良好安全性
• 已內(nèi)嵌在瀏覽器中

缺點(diǎn)

• 認(rèn)證方式單一
• 應(yīng)用的局限性很大
• 只對(duì)應(yīng)用通道加密
• 不能對(duì)消息進(jìn)行簽名
• 加密級(jí)別通常不高
• LAN連接缺少解決方案
• 不能保護(hù)UDP通道安全
• 不能訪問(wèn)控制
• 是應(yīng)用層加密，性能差
• 需CA支持

7.4.4 TLS 虛擬專網(wǎng)的應(yīng)用

• 在客戶與TLS VPN的通信中，人們常采用TLS Proxy技術(shù)來(lái)提高VPN服務(wù)器的通信性能和安全身份驗(yàn)證能力
• 主要用于訪問(wèn)內(nèi)部網(wǎng)中的一些基于Web的應(yīng)用

7.4.5 TLS VPN 與 IPSec VPN比較

選項(xiàng)TLS VPNIPSec VPN

身份驗(yàn)證	單向身份驗(yàn)證 雙向身份驗(yàn)證 數(shù)字證書(shū)	雙向身份驗(yàn)證 數(shù)字證書(shū)
加密	強(qiáng)加密 基于Web瀏覽器	強(qiáng)加密 依靠執(zhí)行
全程安全性	端到端安全 從客戶到資源端全程加密	網(wǎng)絡(luò)邊緣到客戶端 僅對(duì)從客戶到VPN網(wǎng)關(guān)之間通道加密
可訪問(wèn)性	適用于任何時(shí)間、任何地點(diǎn)訪問(wèn)	限制適用于已經(jīng)定義好受控用戶的訪問(wèn)
費(fèi)用	低（無(wú)須任何附加客戶端軟件）	高（需要管理客戶端軟件）
安裝	即插即用安裝 無(wú)須任何附加的客戶端軟、硬件安裝	通常需要長(zhǎng)時(shí)間的配置 需要客戶端軟件或硬件
用戶的易使用性	對(duì)用戶非常友好，使用非常熟悉的Web瀏覽器 無(wú)須終端用戶的培訓(xùn)	對(duì)沒(méi)有相應(yīng)技術(shù)的用戶比較困難 需要培訓(xùn)
支持的應(yīng)用	基于Web的應(yīng)用 文件共享 E-mail	所有基于IP協(xié)議的服務(wù)
用戶	客戶、合作伙伴用戶、遠(yuǎn)程用戶、供應(yīng)商等	更適合在企業(yè)內(nèi)部使用
可伸縮性	容易配置和擴(kuò)展	在服務(wù)器端容易實(shí)現(xiàn)自由伸縮，在客戶端比較困難
穿越防火墻	可以	不可以

• TLS VPN有很多優(yōu)點(diǎn)，但并不能取代IPSec VPN
• IPSec VPN主要提供LAN-to-LAN的隧道安全連接
• 在為企業(yè)高級(jí)用戶提供遠(yuǎn)程訪問(wèn)及為企業(yè)提供LAN-to-LAN隧道連接方面，IPSec具有無(wú)可比擬的優(yōu)勢(shì)
• 目前，IPSec VPN的廠商也開(kāi)始研究如何讓IPSec VPN兼容TLS VPN，以增強(qiáng)可用性。如果成功，IPSec VPN的擴(kuò)展性將大大加強(qiáng)，生命力也將更長(zhǎng)久。

7.5 PPTP 虛擬專網(wǎng)的原理及應(yīng)用

7.5.1 PPTP 虛擬專網(wǎng)概述

• PPTP VPN最早是Windows NT 4.0支持的隧道協(xié)議標(biāo)準(zhǔn)，是PPP的擴(kuò)展。
• 增強(qiáng)了PPP的認(rèn)證和加密功能。
• PPTP的主要功能是開(kāi)通VPN隧道，它還是采用原來(lái)的PPP撥號(hào)建立網(wǎng)絡(luò)連接
• PPTP的兩個(gè)主要任務(wù)是“封裝”和“加密”。
  • PPTP本身不提供加密服務(wù)，只是對(duì)先前已加密的PPP幀進(jìn)行封裝。
  • 所謂的“加密”實(shí)際上是PPP通過(guò)MS-CHAP 和EAP-TLS協(xié)議建立會(huì)話密鑰。
  • 然后再對(duì)凈荷部分采用MPPE機(jī)制進(jìn)行加密

7.5.2 PPTP 虛擬專網(wǎng)的原理

• PPTP基于C/S結(jié)構(gòu)，它將認(rèn)證和連接設(shè)置功能分離開(kāi)來(lái)，在其他類型的VPN中，這兩個(gè)功能是統(tǒng)一的。
• PPTP正是利用了“NAS功能分解”機(jī)制的支持，才能在Internet上實(shí)現(xiàn)VPN。
• PPTP定義了三個(gè)功能實(shí)體：
  • PPTP訪問(wèn)集中器（PAC，PPTP Access Server）
  • 網(wǎng)絡(luò)訪問(wèn)服務(wù)器（NAS，Network Access Server， 有時(shí)稱RAS）
  • PPTP網(wǎng)絡(luò)服務(wù)器（PNS，PPTP Network Server）

建立PPTP連接

• 首先需要建立客戶端與本地ISP的PPP連接。
• 成功接入Internet，再就是建立PPTP連接。
• 從最頂端的PPP客戶端、PAC 和PNS服務(wù)器之間開(kāi)始，由已經(jīng)安裝好PPTP的PAC建立并管理PPTP任務(wù)

7.5.3 PPTP 虛擬專網(wǎng)的優(yōu)缺點(diǎn)

思路

• 遠(yuǎn)程Windows用戶通過(guò)撥號(hào)網(wǎng)絡(luò)中的遠(yuǎn)程訪問(wèn)服務(wù)（RAS）與本地ISP進(jìn)行PPP撥號(hào)連接。
• 當(dāng)PPP連接建立后，VPN客戶再使用VPN連接選項(xiàng)進(jìn)行二次撥號(hào)。

優(yōu)點(diǎn)

它不依賴于TCP/IP協(xié)議族，可以與Novell的IPX或Microsoft的 NetBEUI協(xié)議一起使用

缺點(diǎn)

由于PPTP中沒(méi)有定義加密功能，使PPTP VPN的安全性在所有類型的IP VPN中最低

7.6.4 PPTP與L2TP

• PPTP和L2TP都使用PPP協(xié)議對(duì)數(shù)據(jù)進(jìn)行封裝，然后添加附加包頭用于數(shù)據(jù)在互聯(lián)網(wǎng)絡(luò)上的傳輸
• PPTP要求互聯(lián)網(wǎng)絡(luò)為IP網(wǎng)絡(luò)。L2TP只要求隧道媒介提供面向數(shù)據(jù)包的點(diǎn)對(duì)點(diǎn)的連接。L2TP可以在IP（使用UDP），楨中繼永久虛擬電路（PVCs),X.25虛擬電路（VCs）或 ATM VCs網(wǎng)絡(luò)上使用。
• PPTP只能在兩端點(diǎn)間建立單一隧道。L2TP支持在兩端點(diǎn)間使用多隧道。使用L2TP，用戶可以針對(duì)不同的服務(wù)質(zhì) 量創(chuàng)建不同的隧道。
• L2TP可以提供包頭壓縮。當(dāng)壓縮包頭時(shí)，系統(tǒng)開(kāi)銷（ove rhead）占用4個(gè)字節(jié)，而PPTP協(xié)議下要占用6個(gè)字節(jié)。
• L2TP可以提供隧道驗(yàn)證，而PPTP則不支持隧道驗(yàn)證。但是當(dāng)L2TP或PPTP與IPSEC共同使用時(shí)，可以由IPSEC提供隧道驗(yàn)證，不需要在第2層協(xié)議上驗(yàn)證隧道。

7.6 MPLS 虛擬專網(wǎng)的原理及應(yīng)用

7.6.1 MPLS 虛擬專網(wǎng)概述

• 多協(xié)議標(biāo)記交換(MPLS:Multiprotocol Label Switching)
• MPLS VPN是一種基于MPLS技術(shù)的IP VPN。
• MPLS技術(shù)可以大大加快路由器交換和轉(zhuǎn)發(fā)數(shù)據(jù)包的速度。
• MPLS由Cisco的標(biāo)記交換技術(shù)演變而來(lái)，已成為IETF的標(biāo)準(zhǔn)協(xié)議，是標(biāo)記轉(zhuǎn)發(fā)的典范。
• 與傳統(tǒng)的網(wǎng)絡(luò)層技術(shù)相比，它引入了以下一些新概念
  • 流（Flow）
  • 標(biāo)記（Label）
  • 標(biāo)記交換（Label Swap）
  • MPLS節(jié)點(diǎn)（MPLS Node）
  • MPLS域（MPLS Domain）
  • MPLS邊界節(jié)點(diǎn)（MPLS Edge Node）
  • 標(biāo)記交換路徑（LSP，Label Switched Path）
  • 標(biāo)記交換路由器（LSR，Label Switching Router）
  • 標(biāo)記分發(fā)協(xié)議（LDP，Label Distribution Protocol）

7.6.2 MPLS 虛擬專網(wǎng)的原理

• MPLS VPN中，每個(gè)VPN子網(wǎng)分配一個(gè)獨(dú)一無(wú)二的標(biāo)示符，它與用戶的地址連接形成轉(zhuǎn)發(fā)表中獨(dú)一無(wú)二的地址（VPN-IP地址）
• VPN轉(zhuǎn)發(fā)表中包括與VPN-IP地址對(duì)應(yīng)的標(biāo)簽，通過(guò)它將數(shù)據(jù)送到相應(yīng)地址。

這種方案的優(yōu)勢(shì)

• 通過(guò)相同的網(wǎng)絡(luò)結(jié)構(gòu)支持多種VPN，不必為每一個(gè)用戶建立單獨(dú)的VPN網(wǎng)絡(luò)連接。
• 服務(wù)提供商可以為租用者配置一個(gè)網(wǎng)絡(luò)以提供專用的IP網(wǎng)服務(wù)，而無(wú)須管理隧道。
• QoS服務(wù)可與MPLS VPN無(wú)縫結(jié)合，為每個(gè)VPN網(wǎng)絡(luò)提供特有的業(yè)務(wù)策略。
• MPLS VPN用戶能夠使用他們專有的IP地址上網(wǎng)，無(wú)須網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）幫助。

7.6.3 MPLS 虛擬專網(wǎng)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

• 降低了成本
• 方便了用戶
• 提高了資源利用率
• 提高了網(wǎng)絡(luò)速度
• 提高了靈活性和可擴(kuò)展性
• 安全性高
• MPLS的QoS保證
• 業(yè)務(wù)綜合能力強(qiáng)
• 適用于城域網(wǎng)（PAN）這樣的網(wǎng)絡(luò)環(huán)境

缺點(diǎn)

• 由于ATM技術(shù)本身目前備受爭(zhēng)議，故MPLS VPN的價(jià)值大打折扣
• 本身沒(méi)有采用加密機(jī)制，因此MPLS VPN實(shí)際上并不十分安全。
  換技術(shù)演變而來(lái)，已成為IETF的標(biāo)準(zhǔn)協(xié)議，是標(biāo)記轉(zhuǎn)發(fā)的典范。
• 與傳統(tǒng)的網(wǎng)絡(luò)層技術(shù)相比，它引入了以下一些新概念
  • 流（Flow）
  • 標(biāo)記（Label）
  • 標(biāo)記交換（Label Swap）
  • MPLS節(jié)點(diǎn)（MPLS Node）
  • MPLS域（MPLS Domain）
  • MPLS邊界節(jié)點(diǎn)（MPLS Edge Node）
  • 標(biāo)記交換路徑（LSP，Label Switched Path）
  • 標(biāo)記交換路由器（LSR，Label Switching Router）
  • 標(biāo)記分發(fā)協(xié)議（LDP，Label Distribution Protocol）

7.6.2 MPLS 虛擬專網(wǎng)的原理

• MPLS VPN中，每個(gè)VPN子網(wǎng)分配一個(gè)獨(dú)一無(wú)二的標(biāo)示符，它與用戶的地址連接形成轉(zhuǎn)發(fā)表中獨(dú)一無(wú)二的地址（VPN-IP地址）
• VPN轉(zhuǎn)發(fā)表中包括與VPN-IP地址對(duì)應(yīng)的標(biāo)簽，通過(guò)它將數(shù)據(jù)送到相應(yīng)地址。

這種方案的優(yōu)勢(shì)

• 通過(guò)相同的網(wǎng)絡(luò)結(jié)構(gòu)支持多種VPN，不必為每一個(gè)用戶建立單獨(dú)的VPN網(wǎng)絡(luò)連接。
• 服務(wù)提供商可以為租用者配置一個(gè)網(wǎng)絡(luò)以提供專用的IP網(wǎng)服務(wù)，而無(wú)須管理隧道。
• QoS服務(wù)可與MPLS VPN無(wú)縫結(jié)合，為每個(gè)VPN網(wǎng)絡(luò)提供特有的業(yè)務(wù)策略。
• MPLS VPN用戶能夠使用他們專有的IP地址上網(wǎng)，無(wú)須網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）幫助。

7.6.3 MPLS 虛擬專網(wǎng)的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)

• 降低了成本
• 方便了用戶
• 提高了資源利用率
• 提高了網(wǎng)絡(luò)速度
• 提高了靈活性和可擴(kuò)展性
• 安全性高
• MPLS的QoS保證
• 業(yè)務(wù)綜合能力強(qiáng)
• 適用于城域網(wǎng)（PAN）這樣的網(wǎng)絡(luò)環(huán)境

缺點(diǎn)

• 由于ATM技術(shù)本身目前備受爭(zhēng)議，故MPLS VPN的價(jià)值大打折扣
• 本身沒(méi)有采用加密機(jī)制，因此MPLS VPN實(shí)際上并不十分安全。

總結(jié)

以上是生活随笔為你收集整理的[ 笔记 ] 计算机网络安全_7_虚拟专网技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。