網絡安全的普及宣傳研究畢業論文(編輯修改稿)

　

【文章內容簡介】 akley和SKEME這三個協議為IKE的基礎，IKE沿用了ISAKMP的基礎、Oakley的模式以及SKEME的共享和密鑰更新技術，并定義了自己獨特的密鑰素材導出方式，以及協商共享策略的方法。另外IKE定義了它自身的兩種密鑰交換方式。IKE的相關概述對于IPSec而言，IKE則定義了其需要的密鑰交換技術。IKE交換的結果就是一個已經認證的密鑰以及建立在雙方協議基礎上的服務，即IPSec SA。 IKE協議簇圖IKE使用了兩個階段的ISAKMP，其中第1階段建立一個保密的和已認證無誤的通信信道，即IKE SA，以及建立通過認證的密鑰，為雙方的IKE通信提供機密性、消息完整性以及消息源認證服務。第2階段則利用第1階段的IKE SA來協商建立IPSec 具體的SA。在IKE定義的兩個階段中， IKE體系結構圖所示，階段1包含兩種模式，筆者稱之為主模式和主動模式，而階段2只有一種模式，稱之為快速模式。 IKE體系結構圖在上述所說的階段1為IKE建立的IKE SA提供了一套保護套件，其中包括各種實踐中所需的參數，包括加密算法、散列算法、認證方法以及DiffieHellman組，其在協商過程中是作為整個套件進行協商。IKE的以上交換均屬于信息方面的交換。在這種交換中，IKE通信雙方可相互間傳達有關錯誤信息和狀態咨詢，而且一種新的組交換模式可是各方協商如何在它們之中使用一個新的DiffieHellman組（以下簡稱DH組）。DH組決定了在進行一次DH交換時通信雙方需要采用的參數。IKE中定義了5個組，并為每個組分配了獨有的值。而對IKE影響最大的當屬認證方法，通過通信雙方協商的認證方法，可以改變一次IKE交換，常用的認證方法有：預共享密鑰（Preshared Keys，簡稱PSK）、PKI（系統默認）、使用RSA或者DES得到的數字簽名、使用交換加密的Nonce。在通信雙方第一條信息時，通信各方在向對方發送一部分外部可見的特征外，彼此都會保留一些私密信息，用于認證和保護IKE消息，以及為其他的安全服務衍生出相應的密鑰。這些私密信息包括以下四種：1）SKEID：經過交換密鑰信息后得到的共享密鑰ID，后面三種均是建立它之上的。2）SKEYID_d：用于為IPSec和其他協議的SA衍生出加密的材料；3）SKEYID_a：用來為IKE消息保障數據的完整性以及對數據源的身份認證；4）SKEYID_e：用于對IKE消息進行加密。SKEID的生成取決于使用何種認證方法，其他的以SKEID為基礎的私密信息都是以相同方式衍生出來。對于SKEID的生成，通信各方都要分別提供一個Cookie和Nonce。（2）主模式前文中筆者提到，IKE分為兩個階段，其中第1階段有兩種模式，分別為主模式和主動模式，第2階段只有一種模式，則為快速模式。主模式主要應用于協商階段1的ISAKMP SA，其將密鑰交換信息與身份認證信息分離開來，保護了身份信息，而交換的身份信息受到了前面生成的DH共享密鑰的保護，因此這些增加了3個消息的開銷。而在整個主模式下共有3個步驟并包含6條消息，三個步驟分別為SA協商、1次DH交換和1次Nonce交換以及對ISAKMP協商能力的完全利用。、由于本課題方案中采用的是預共享密鑰認證方式，所以下面以預共享密鑰認證為例，來講述主模式的體系結構，而其他認證方式的主模式交換體系結構與此類似。 主模式交換結構圖 IKE協商會話，下面將針對圖中的6條消息進行闡述。消息1和消息2發起者首先向響應者發送其所有的SA載荷信息，響應者收到發起者的消息1之后，將向發起者發送1個SA載荷，用于說明它所接受的正在協商的SA。在本次交換中通信雙方需要協商IKE SA的各項參數，并對交換的其余部分擬定規范。消息3和消息4發起者和響應者交換DH公開值和輔助數據，如Nonce，Nonce是計算共享秘密（用來生成加密密鑰和認證密鑰）所必需的。本次交換中通信雙方會交換DH公開值以及偽隨機Nonce，并生成SKEYID狀態。消息5和消息6發起者和響應者交換標識數據并認證DH交換。這兩條消息中傳遞的信息是經過加密的，而用于加密的密鑰來自于消息3和消息4中交換的密鑰信息，因此身份信息受到了保護。本次交換中通信雙方各自標定自己的身份，并相互交換認證散列摘要，交換過程中，用SKEYID_e進行加密。對于各種認證方式的主模式交換，可用一個比較形象且易于理解的圖示來說明。（3）主動模式主動模式和主模式的作用相同，都是建立一個已認證的SA和密鑰，隨后IKE可用它們為其他協議建立SA。二者的主要差別在于主動模式只需用到主模式一半的消息。由于對消息的數量進行了限制，主動模式同時也限制了它的協商能力，而且不會提供身份保護。主動模式允許同時傳送與SA、密鑰交換和認證相關的載荷，而將這些載荷組合到一條信息中，減少了信息的交換次數，但這樣正如前述而無法提供身份保護。主動模式運用的場合很少，但在實際應用當中也能碰到，比如在需要運行遠程訪問的環境下，由于發起者的地址是響應者無法預先知曉，而且雙方都打算使用預共享密鑰認證方法，則要想建立IKE SA，主動模式便是唯一可行的交換方式。另外，如果發起者已知響應者的策略，或者對策略有著非常全面的理解，此時發起方沒有必要利用IKE和響應者協商全部功能，則此時也可以用主動模式交換，這樣它們可以更加快捷地建立IKE SA。（4）快速模式在經過階段1建立好IKE SA之后，可用這些IKE SA為其他安全協議生成相應的SA，而這些SA則是通過快速模式交換建立起來的。同時，在單獨一個IKE SA的保護下，可以執行一次甚至并發地執行多次快速模式交換。在本模式交換中，通信雙方需要協商擬定IPSec SA的各項特征，并為其生成密鑰。IKE保護快速模式的方式主要是對其進行加密，并對消息進行認證。其中消息的認證時通過相關散列函數進行，來自IKE SA的SKEYID_a的值作為一個密鑰，對快速模式進行相關認證，這樣除了保障了快速模式下數據的完整性之外，還能提供對數據源的身份認證。因為在消息收到之后，只有來自通過認證的實體，而且消息在傳輸過程中并未發生改變。至于加密則是通過使用SKEYID_e的值來完成的。：1）消息1，發起者向接收者分別發送散列載荷、SA載荷、Nonce載荷各一個，以及可選的密鑰交換信息和標識信息。如果需要PFS，則此消息中必須包含密鑰交換信息。散列載荷中包含信息摘要，它是使用前面協商好的偽隨機函數對頭中的消息ID連同散列載荷后面的全部消息部分（包括所有載荷頭）進行計算的結果。2）消息2消息2中的載荷和消息1中的載荷類型。散列2中包含指紋的生成和散列1中的類似，只是除去了載荷頭的發起者Nonce，Ni插入在消息ID之后、其他部分之前。3）消息3消息3是用于對前面的交換進行認證，僅由ISAKMP和散列載荷組成。本章簡要地介紹了GRE與IPSec相關技術，下一張將結合前一章和本章內容，來對本課題案例的系統進行分析和概要設計。第三章 系統VPN分析與概要設計前面兩章介紹了VPN的基本概念，以及GRE與IPSec相關技術，后續內容將從本章開始，結合合肥百大集團網絡拓撲，開始本課題的設計與仿真。隨著合肥百大集團不斷的壯大發展，不但在合肥擁有眾多百貨大樓，同時在安徽蚌埠、蕪湖、淮南、黃山等多個縣市擁有業務分支。根據業務的需要，為了更好更穩定的保證總部與分支的數據通訊，分支和中心之間采用OSPF動態路由協議。由于網絡接入形式的多樣化，在考慮使用VPN對專線備份，來滿足業務延展性的需要，對網絡的實現形式也增加了限制條件。如何在開放的Internet網絡上建立私有數據傳輸通道，將遠程的分支連接起來，同時又要保證數據傳輸的安全性？以下將根據實際需求和相關技術的優勝劣汰進行闡述，以最終選擇出適合本課題的最佳技術方案。由于合肥百大集團已經發展到全省的各個市縣區均有業務分支機構，分支機構與合肥總部中心之間的數據交互密不可分，這樣就需要專門的鏈路來使得總部與各分支機構之間互聯。然而，在實際應用當中，就如同前文所述（），穿越整個互聯網，是不可能鋪設專門的物理鏈路來滿足業務的需求，因為架設專用鏈路所需的代價太高，顯然這樣的設計是不切實際的。因此需要一種VPN技術來滿足集團的業務需求。但是，前文中已經描述過，VPN技術由很多種（），如何在諸多種VPN技術中選擇出適合本集團所需的VPN技術呢，這要根據集團網絡實際設計和需求來決定。由于合肥百大集團在分支與中心之間采用三層路由協議，顯然就應該使用三層VPN技術，從而淘汰前文所述的二層VPN技術，如PPTP VPN、L2F VPN和L2TP VPN等，同時也可以淘汰掉SSL VPN技術，因為SSL是高于IP層的第四層協議。另外，MPLS VPN在此也不大適合集團的VPN設計，因為MPLS是獨立于二層和三層的協議，其適合更大的機構網絡運用，因為大型網絡要結合IGP和BGP，而MPLS就是由于此種需求應運而生的，因此在本案例設計中，也不應該用此技術。同時，綜合上述淘汰的諸多VPN技術，而產生的相互嵌套結合的VPN技術也隨之被棄選。因此，鑒于以上分析，適合三層VPN技術的有GRE VPN技術和IPSec VPN技術。但是如何在這兩種技術之間進行優選的決策呢？從前面章節（第二章）我們可以知道，IPSec VPN具有完好的加密認證技術，但是其IP路由只支持靜態路由，顯然對于像百大集團這樣一個大型公司來說，靜態路由指派顯然是一件效率極其低下的事情。在IPSec協議的實現過程中，研究機構為了彌補IPSec的這種缺陷，也相繼研究出實現IPSec協議支持動態路由協議的特性，即IPSec Profile。但是這種技術即使實現了IPSec支持動態路由協議的功能，也無法滿足百大集團的現實需求，因為在現有的網絡設備的軟件版本來說，很多版本并不支持這種技術。所以需要選擇另外的、比較傳統的隧道技術來結合傳統的IPSec協議，這種比較傳統且較為常用的技術就是GRE隧道技術。由上一章關于GRE與IPSec的介紹，我們不難總結出關于這兩種協議的優缺點：GRE優點：支持單播、組播、廣播和非IP數據流。 缺點：不提供安全加密功能。 適用場合：適用于復雜的網絡拓撲、IP或非IP網絡及高安全性 能的網絡環境。 IPSec優點：為數據提供加密、完整性、源認證和防重放功能。 缺點：只支持單播和IP數據流。 適用場合：適用于高安全性能、簡單拓撲配置的IP網絡環境。因此，結合1和2關于GRE與IPSec優缺點的描述來看，為了滿足本案例的業務需求，可將GRE與IPSec相結合而互補優缺點。經過以上分析可知，GRE協議和IPSec協議具有互補性，結合二者這種互補性，可以滿足百大集團的關于同時支持動態路由協議和安全加密認證的需求。而關于這兩種VPN技術的結合，有兩者結合方式，亦即GRE over IPSec VPN和IPSec over GRE VPN。關于這兩種技術（即GRE over IPSec VPN技術和IPSec over GRE VPN技術）的細則問題，則后文第四章的相關章節有詳細的介紹，此處不多做解釋，而最終的選擇則是GRE over IPSec VPN技術，下面將針對此技術進行本系統的規劃和設計。網絡設備的互聯，則表示的是合肥百大集團GRE over IPSec VPN的公網接入拓撲圖，其中路由器Center代表百大集團在合肥的總部中心路由器，而VPN1~VPN5的五個路由器則分別代表分布在全省各個市縣區的分支機構的接入網路由器（此處只選擇其中的五個，因為每個分支機構的配置都大同小異），亦即經OSPF劃分區域后，這些路由器則為普通區域與骨干區域的邊界路由器。路由器ISP則代表互聯網，其接口serial0/0~s1/1則代表運營商提供給總部和每個分支機構的出口，、。與路由器ISP的接口serial0/0~s1/1直連的總部以及分支機構的接入網路由器的接口，除總部路由器Center接口為serial0/0外，其余分支機構的分別為每個分支機構路由器的接口serial0/0，、。整個網絡進行OSPF區域劃分合肥總部網絡中心的區域為Area 6，其中服務器分別為WWW服務器、Email服務器、FTP服務器以及Database服務器，；，依次分別為Area Area Area Area Area 5，；穿越互聯網的區域為Area 0。同時，Area 1~ Area 6與Area 、。GRE隧道設計合肥總部路由器Center的接口serial0/0與各個分支機構的OSPF區域邊界路由器的接口serial0/0，通過互相指派為源和目的來建立GRE隧道，然后在每個隧道運行0SPF協議，使得能夠動態學習到相關的網段。IPSec隧道設計由于本系統相關技術是基于GRE over IPSec VPN技術，故而在各個分支機構內部以及總部的內部網絡中的主機傳輸的數據，到達邊界路由器時便通過GRE隧道接口進行GRE封裝，然后將經過封裝后的GRE數據包再通過IPSec隧道接口進行加密封裝。由此可見，針對于GRE數據包，各分支機構的邊界路由器與總部的邊界路由器之間相互通信的加密點和通信點均落在所有的邊界路由器上，故而可以選擇的IPSec的數據包封裝模式為傳輸模式，而不是選擇隧道模式，主要是因為隧道模式要比傳輸模式多了一個20B的、和傳輸模式一樣的報頭，這樣就使得每個隧道模式的數據包比傳輸模式的數據包少傳輸20B的數據，影響到數據的傳輸速率。同時，隧道模式因為多增加了數據報頭，就會增加網絡設備的內存和CPU資源，影響網絡設備的整體性能，增大網絡傳輸的延遲，等等。鑒于上述原因，最終選擇了GRE over IPSec VPN技術中的IPSec傳輸模式。對于IPSec通信對等點，總部路由器的接口serial0/0與各個分支機構路由器的接口serial0/0之間相互認證為IPS