【正文】 配置如圖 63 所示： 圖 63 Server 端 FTP 服務器源地址 IP 協(xié)議及 IPSec 協(xié)議安全分析 27 配置如圖 64 所示： 圖 64 Server 端 FTP 服務器目的地地址 (2) 之后要為這個 IPSec 策略建立篩選器，這里 用帶完整性 (SHA_1 算法 )和加密(3DES 算法 )的協(xié)商安全，配置如圖 65 所示： 圖 65 協(xié)商安全時選擇的完整性和加密算法 (3) 要為雙方提供完全一致的預共享密鑰 ，配置如圖 66 所示： 。 IP 協(xié)議及 IPSec 協(xié)議安全分析 25 圖 53 協(xié)議分析模塊 6 基于 IPSec 策略的網(wǎng)絡安全性分析 基于圖形化界面的 IPSec策略實現(xiàn) 試驗拓撲圖 如圖 61 所示 ： 頁 1局 域 網(wǎng) 內 I P S e c 加 密 驗 證F T P 服 務 器E t h e r e a l 測 試 機C l i P C 1C l i P C 2 圖 61 實驗拓撲圖 從 Frame 協(xié)議開始 協(xié)議解析模塊 Hash 表 查找 Hash 表 判 斷是 否有 層協(xié) 議封裝 調用協(xié)議解析函數(shù)處理 將協(xié)議解析結果 程序初始化時生成 IP 協(xié)議及 IPSec 協(xié)議安全分析 26 首先， 我 來配置服務器端 FTP 站點。 協(xié)議分析模塊 首先我們來分析下 Ethereal 的處理流程： (1) 從列表中選出一個數(shù)據(jù)包 (2) 提取選中數(shù)據(jù)包中的數(shù)據(jù)，填寫在數(shù)據(jù)結構中 (3) 調用協(xié)議解析函數(shù) epan 的 Dissectors 進行處理 實際上，這 才 是真正的協(xié)議解析過程 。 (4) 主程序把捕獲的數(shù)據(jù)寫入到臨時文件中捕包進程和主程序是同一個可執(zhí)行文件，只是通過文件名不同，執(zhí)行不同的操作。 捕 包及讀文件模塊 首先分析下 Ethereal 的捕包流程： (1) 入口函數(shù)為 capture_start_cb (2) 捕包進程和主程序是通過 PIPE 進行傳遞數(shù)據(jù)的 (3) 捕包進程和主程序之間沒有數(shù)據(jù)同步機制，也就是說，主程序不知道捕包程序是否丟包。 (6) Dfilter 模塊初始化 update_thread：這個線程和 tap 有關 取 配置文件 preference capture filter 和 display filter 文件，分別保存在全局變量 capture_filter 和display_filter 中。 frame_handle 保存了 frame 協(xié)議的 handle。 ： 全局變量 proto_names， proto_short_names， proto_filter_names 以上三個全局變量主要用來判斷新注冊的協(xié)議名是否重復，如果重復，給出 提示信息，在協(xié)議解析過程中并沒有使用。 (4) Capture 捕包引擎 (5) Wiretap 從文件中讀取數(shù)據(jù)包，支持多種文件格式，源碼在 wiretap 目錄 。 GTK 1/2 CORE Capture Wiretap Epan ProtocolTree Dissectors Plugin DisplayFilters Winlibpcap Capture Filters Hard Disk Network IP 協(xié)議及 IPSec 協(xié)議安全分析 23 ：保存數(shù)據(jù)包的協(xié)議信息 ：在 epan/dissector 目錄下，各種協(xié)議解碼器。 不過我認為只要今后它還一如既往的保持它的開源精神，那我們就永遠不會失去IP 協(xié)議及 IPSec 協(xié)議安全分析 22 這么優(yōu)秀的網(wǎng)絡分析軟件。這些都是由于Ethereal 沒有實現(xiàn) TCP 協(xié)議 棧，無法做到流級別的識別。由于協(xié)議名為 y 開頭。每次協(xié)議數(shù)據(jù)需要內容識別時，按字母順序逐個調用表里的每個識別函數(shù)。另外對于內容識別式。這就讓一些非標準端口的協(xié)議數(shù)據(jù)沒有正確解析出來。 盡管 Ethereal是目前最好的開放源碼的網(wǎng)絡分析系統(tǒng)，但 Ethereal 仍然有一些可以改進的地方，一個優(yōu)秀的網(wǎng)絡分析器，盡可能的正確分析出數(shù)據(jù)協(xié)議和高效的處理數(shù)據(jù)是兩個重要的指標。 我想 也 正 是因為有很好的體系結構，這個系統(tǒng)才能夠開發(fā)出如此多的協(xié)議解析器 。這樣一個新的協(xié)議分析模塊就加入到系統(tǒng)中了。 Ethereal 由于采用插件技術，程序員開發(fā)一種新的協(xié)議分析模塊的時候不需要 了解所 有的代碼，只需要寫好這個協(xié)議模塊的函數(shù)后，寫一個格式為 proto_reg_handoff_XXX 的函數(shù)，在函數(shù)內調用注冊函數(shù)告訴系統(tǒng)在什么時候需要調用這個協(xié)議模塊。通過增加插件使程序有很強的可擴展性，各個功能模塊內聚。它著名的應用實例有：媒體播放器 Winamp、微軟的網(wǎng)絡瀏覽器 IE 等。 最后，我們來看一下 Ethereal 最值得稱道也是它廣泛普及的 基于插件技術的協(xié)議分析器所謂插件技術，就是在程序的設計開發(fā)過程中，把整個應用程序分成宿主程序和插件兩個部分，宿主程序與插件能夠相互通信，并且，在宿主程序不變 的情況下，應用層 IP TCP UDP HTTP TFTP IP 協(xié)議及 IPSec 協(xié)議安全分析 21 可以通過增減插件或修改插件來調整應用程序的功能。這樣由根節(jié)點開始一層層解析下去。 這樣當一個端口為 21 的 TCP 數(shù)據(jù)流來到時。比如 FTP 協(xié)議。 在 Ethereal 中注冊一個協(xié)議解析器首先要指出它的父協(xié)議是什么。 =21 就可以認為是FTP 協(xié)議，特征字可以是協(xié)議規(guī)范定義的任何一個字段。這些特征字給自己的子節(jié)點協(xié)議提 供可以互相區(qū)分開來的標識。那么這些擁有同樣父協(xié)議兄弟節(jié)點協(xié)議如何互相區(qū)分了 Ethereal 系統(tǒng)采用協(xié)議的特征字來識別。我們將最低層的無結構數(shù)據(jù)流作為根接點。上圖就是一個簡單的協(xié)議樹。從而對數(shù)據(jù)流里的各個層次的協(xié)議能夠逐層處理。 協(xié)議樹如圖 51 所示。首先對網(wǎng)絡層的協(xié)議識別后進行組包還原然后脫去網(wǎng)絡 層協(xié)議頭。由于OSI 的 7 層協(xié)議模型，協(xié)議數(shù)據(jù)是從上到下封裝后發(fā)送的 [12]。其次， Ethereal 采用的是雙層次化 的數(shù)據(jù)包協(xié)議分析方法 。就實現(xiàn)來說提供的函數(shù)調用接口也是一致的?，F(xiàn) 有的大部分 Linux 捕包系統(tǒng)都是基于這套函數(shù)庫或者是在它基礎上做一些針對性的改進在 window 系統(tǒng)中，意大利人 Fulvio Risso 和 Loris Degioanni 提出并實現(xiàn)了Winpcap 函數(shù)庫。 在 Linux系統(tǒng)中， 1992年 Lawrence Berkeley Lab 的 Steven McCann和 Van Jacobson提出了包過濾器的一種的實現(xiàn)。作用是從網(wǎng)卡取得數(shù)據(jù)包或者根據(jù)過濾規(guī)則取出數(shù)據(jù)包的子集，再轉交給上層分析模塊。 Ethereal 網(wǎng)絡 分析系統(tǒng)首先依賴于一套捕捉網(wǎng)絡數(shù)據(jù)包的函數(shù)庫。 Ethereal適用于當前所有較為流行的計算機系統(tǒng)，包括 Unix、 Linux 和 Windows 其次， Ethereal 可以 通過 各個應用的響應時間，一個操作需要的時間，應用帶寬的消耗，應用的行為特征，應用性能的瓶頸等等幫助我們評估業(yè)務運行狀態(tài) ， 幫助我們評估網(wǎng)絡的性能 ；另外， Ethereal 可以幫助我們排除潛在的威脅 ， 快速定位故障 。它具有用戶對協(xié)議分析器所期望的所有標準 特征，并具有其它同類產(chǎn)品所不具備的有關特征。這樣才能適應網(wǎng)新 IP AH 原 IP TCP/UDP 應用程序數(shù)據(jù) 報頭 報頭 報頭 報頭 完整性檢查部分 (簽名 ) IP 協(xié)議及 IPSec 協(xié)議安全分析 19 絡發(fā)展的需要不斷加入新的協(xié)議解析器。事實上由于網(wǎng)絡上各種協(xié)議種類繁多，各種新的協(xié)議層出不窮。 我們 很難想象如此多的人開發(fā)的代碼可以很好的融入系統(tǒng)中；并且在系統(tǒng)中加入一個新的協(xié)議解析器很簡單。 由于 Ethereal 是一個開放源碼的網(wǎng)絡分析系統(tǒng)，也是目前最好的開放源碼的網(wǎng)絡協(xié)議分析器，支持 Linux 和 Windows 平臺。 其最常用的功能是被攻擊者用來檢測被攻擊電腦通過23(TELNET)和 110(POP3)端口進行的一些明文傳輸數(shù)據(jù)，以輕松得到用戶的登錄口令和郵件賬號密碼。 Ethereal 基本類似于 TCPdump，但 Ethereal 還具有設計完美的 GUI 和眾多分類信息及過濾選項。作為協(xié)議分析工具 —— Ethereal，是一個有名的網(wǎng)絡端口探測器， 它 可以在 Windows， Linux、 Solaris 等各種平臺運行的網(wǎng)絡監(jiān)聽軟件，它主要是針對 TCP/IP 協(xié)議的不安全性對運行該協(xié)議的機器進行監(jiān)聽。 AH 隧道模式中的簽名部分 如圖 45 所示 。 AH 隧道模式為整個數(shù)據(jù)包提供完整性檢查和認證，認證功能優(yōu)于 ESP。其中 內部 IP 報頭 (原 IP 報頭 )指定最終的信源和信宿地址，而 外部 IP 報頭 (新 IP報頭 )中包含的常常是做中間處理的安全網(wǎng)關地址。 圖 44 ESP 的加密部分和完整性檢查 部分 (3) ESP 隧道模式和 AH 隧道模式 之前我們分析 的是傳輸模式下的 AH 協(xié)議和 ESP 協(xié)議， ESP 隧道模式和 AH 隧道模式與傳輸模式略有不同 。完整性檢查部分包括ESP 報頭、有效載荷 (應用程序數(shù)據(jù) )和 ESP 報尾。 Header(下一個報頭 )：識別下一個使用 IP 協(xié)議號的報頭，如 TCP 或 UDP。 DH 算法要求數(shù)據(jù)長度 (以位為單位 )模 512 為448，若應用數(shù)據(jù)長度不足，則用擴展位填充。接收端校驗序列號為該字段值的數(shù)據(jù)包是否已經(jīng)被接收過，若是，則拒收該數(shù)據(jù)包。 ESP 由 IP 協(xié)議號 50標識 . 原 IP IPSec(ESP) 傳輸層 應用程序數(shù)據(jù) ESP 報尾 ESP 報尾 報頭 報頭 報頭 安全參數(shù)索引 索引號 擴展位 擴展位 下一個報頭 長度 認證數(shù)據(jù) 新 IP AH 原 IP TCP/UDP 應用程序數(shù)據(jù) 報頭 報頭 報頭 報頭 完整性檢查部分 (簽名 ) IP 協(xié)議及 IPSec 協(xié)議安全分析 17 其中， ESP 報頭字段包括： Parameters Index (SPI，安全參數(shù)索引 )：為數(shù)據(jù)包識別安全關聯(lián)。但在端對端的隧道通信中， ESP 需要對整個數(shù)據(jù)包加密 。 ESP 可以單獨使用，也可以和 AH 結合使用。 ESP 的加密服務是可選的，但如果啟用加密，則也就同時選擇了完整性檢查和認證。 ， 重播 (Replay)保護才是可選的。其 報文 格式如圖 43 所示。 (2) Encapsulating Security Payload(ESP)協(xié)議結構 ESP 為 IP 數(shù)據(jù)包提供完整性檢查、認證和加密，可以看作是 超級 AH，因為它提供機密性并可防止篡改。 IP 協(xié)議及 IPSec 協(xié)議安全分析 16 圖 42 AH 為整個數(shù)據(jù)包提供完整性 檢查 AH 報頭插在 IP 報頭之后， TCP， UDP，或者 ICMP 等上層協(xié)議報頭之前。接收端接收數(shù)據(jù)包后，首先執(zhí)行 hash 計算，再與發(fā)送端所計算的該字段值比較，若兩者相等，表示數(shù)據(jù)完整，若在傳輸過程中數(shù)據(jù)遭修改，兩個計算結果不一致，則丟棄該數(shù)據(jù)包。接收端校驗序列號為該字段值的數(shù)據(jù)包是 否已經(jīng)被接收過，若是，則拒收該數(shù)據(jù)包。 (長度 )： AH 報頭長度。 AH 可以單獨使用，也可以與 ESP協(xié)議結合使用。 IP 協(xié)議及 IPSec 協(xié)議安全分析 15 原 IP IPSec(AH) 傳輸層報頭 應用程序數(shù)據(jù) 報頭 下一個 長度 安全參數(shù)索引 序列號 認證數(shù)據(jù) (hash 檢查和 ) 報頭 (SPI) 圖 41 AH 報頭 AH 報頭位置在 IP 報頭和傳輸層協(xié)議報頭之間。此報頭包含一個帶密鑰的 hash 散列 (可以將其當作數(shù)字簽名，只是它不使用證書 )，此 hash 散列在整個數(shù)據(jù)包中計算，因此對數(shù)據(jù)的任何更改將致使散列無效 ， 這樣就提供了完整性保護。 (1) Authentication Header(AH)協(xié)議結構 AH 協(xié)議為 IP 通信提供數(shù) 據(jù)源認證、數(shù)據(jù)完整性和反重播保證，它能保護通信免受篡改，但不能防止竊聽，適合用于傳輸非機密數(shù)據(jù)。 AH 和 ESP 都可以提供認證服務，不過， AH 提供的認證服務要強于 ESP,IKE 用于密鑰交換。其中 AH 協(xié)議定義了認證的應用方法，提供數(shù)據(jù)源認證和完整性保證； ESP 協(xié)議定義了加密和可選認證的應用方法，提供可靠性保證。加密機制通過對數(shù)據(jù)進行編碼來保證數(shù)據(jù)的機密性，以防數(shù)據(jù)在傳輸過程中被竊聽。 IPSec 體系結構分析 IPSec 提供了兩種安全機制：認證和加密。通過使用兩種通信安全協(xié)議 (AH 協(xié)議和 ESP 協(xié)議 )以及 Inter 密鑰交換 (IKE)協(xié)議等密鑰管理過程和協(xié)議， IPSec 實現(xiàn)了這些目標 [9]。在 IP 層上提供安全服務，具有較好的安全一致性和共享性及應用范圍。