【導(dǎo)讀】IPSecurity協(xié)議的實(shí)現(xiàn)過程。[3](美)NaganandDoraswamy,DanHarkins著.IPSec新一代因特網(wǎng)安全標(biāo)準(zhǔn).機(jī)械工業(yè)出。與結(jié)構(gòu)（第四版）.北京：電子工業(yè)出版社，,134.當(dāng)今，互聯(lián)網(wǎng)是在20世紀(jì)60年代的ARPANET的基礎(chǔ)上發(fā)展起來的。TCP/IP協(xié)議簇廣泛應(yīng)用于網(wǎng)際互聯(lián)。該協(xié)議是一個(gè)成功的網(wǎng)絡(luò)協(xié)議，有很多優(yōu)點(diǎn)，

　　

【正文】 性能 ；另外， Ethereal 可以幫助我們排除潛在的威脅 ， 快速定位故障 。 Ethereal 工作模式 首先，讓我們來了解下 Ethereal 的捕包平臺(tái) 。 Ethereal 網(wǎng)絡(luò) 分析系統(tǒng)首先依賴于一套捕捉網(wǎng)絡(luò)數(shù)據(jù)包的函數(shù)庫。這套函數(shù)庫工作在 網(wǎng)絡(luò)分析系統(tǒng)模塊的最底層。作用是從網(wǎng)卡取得數(shù)據(jù)包或者根據(jù)過濾規(guī)則取出數(shù)據(jù)包的子集，再轉(zhuǎn)交給上層分析模塊。從協(xié)議上說，這套函數(shù)庫將一個(gè)數(shù)據(jù)包從鏈路層接收，至少將其還原至傳輸層以上，以供上層分析。 在 Linux系統(tǒng)中， 1992年 Lawrence Berkeley Lab 的 Steven McCann和 Van Jacobson提出了包過濾器的一種的實(shí)現(xiàn)。 Libpcap 是一個(gè)基于 BPF 的開放源碼的捕包函數(shù)庫?，F(xiàn) 有的大部分 Linux 捕包系統(tǒng)都是基于這套函數(shù)庫或者是在它基礎(chǔ)上做一些針對(duì)性的改進(jìn)在 window 系統(tǒng)中，意大利人 Fulvio Risso 和 Loris Degioanni 提出并實(shí)現(xiàn)了Winpcap 函數(shù)庫。由于 NPF 的主要思想就是來源于 BPF，它的設(shè)計(jì)目標(biāo)就是為Windows 系統(tǒng)提供一個(gè)功能強(qiáng)大的開發(fā)式數(shù)據(jù)包捕獲平臺(tái)，希望在 Linux 系統(tǒng)中的網(wǎng)絡(luò)分析工具經(jīng)過簡(jiǎn)單編譯以后也可以移植到 Windows 中，因此這兩種捕包架構(gòu)是非常現(xiàn)實(shí)的。就實(shí)現(xiàn)來說提供的函數(shù)調(diào)用接口也是一致的。 Ethereal 網(wǎng)絡(luò)分析系統(tǒng)也需要一個(gè)底層的 抓包平臺(tái)，在 Linux 中是采用 Libpcap 函數(shù)庫抓包，在 Windows 系統(tǒng)中采用 winpcap 函數(shù)庫抓包 。其次， Ethereal 采用的是雙層次化 的數(shù)據(jù)包協(xié)議分析方法 。因?yàn)樗?取得捕包函數(shù)捕回的數(shù)據(jù)包后就需要進(jìn)行協(xié)議分析和協(xié)議還原工作了。由于OSI 的 7 層協(xié)議模型，協(xié)議數(shù)據(jù)是從上到下封裝后發(fā)送的 [12]。對(duì)于協(xié)議分析需要從下至上進(jìn)行。首先對(duì)網(wǎng)絡(luò)層的協(xié)議識(shí)別后進(jìn)行組包還原然后脫去網(wǎng)絡(luò) 層協(xié)議頭。將里面IP 協(xié)議及 IPSec 協(xié)議安全分析 20 的數(shù)據(jù)交給傳輸層分析，這樣一直進(jìn)行下去直到 應(yīng)用層。 協(xié)議樹如圖 51 所示。 圖 51 數(shù)據(jù)流向 圖 由于網(wǎng)絡(luò)協(xié)議種類很 多，就 Ethereal 所識(shí)別的 500 多種協(xié)議來說，為了使協(xié)議和協(xié)議間層次關(guān)系明顯。從而對(duì)數(shù)據(jù)流里的各個(gè)層次的協(xié)議能夠逐層處理。 Ethereal 系統(tǒng)采用了協(xié)議樹的方式。上圖就是一個(gè)簡(jiǎn)單的協(xié)議樹。如果 左子樹 協(xié)議的所有數(shù)據(jù)都是封裝在 右子樹 協(xié)議里的，那么這個(gè) 左子樹 協(xié)議 就是 右子樹 協(xié)議 的 兒子節(jié)點(diǎn)。我們將最低層的無結(jié)構(gòu)數(shù)據(jù)流作為根接點(diǎn)。那么具有相同父節(jié)點(diǎn)的協(xié)議成為兄弟節(jié)點(diǎn)。那么這些擁有同樣父協(xié)議兄弟節(jié)點(diǎn)協(xié)議如何互相區(qū)分了 Ethereal 系統(tǒng)采用協(xié)議的特征字來識(shí)別。每個(gè)協(xié)議會(huì)注冊(cè)自己的特征字。這些特征字給自己的子節(jié)點(diǎn)協(xié)議提 供可以互相區(qū)分開來的標(biāo)識(shí)。比如 TCP 協(xié)議的 port 字段注冊(cè) [13]后。 =21 就可以認(rèn)為是FTP 協(xié)議，特征字可以是協(xié)議規(guī)范定義的任何一個(gè)字段。比如 IP 協(xié)議就可以定義 proto字段為一個(gè)特征字。 在 Ethereal 中注冊(cè)一個(gè)協(xié)議解析器首先要指出它的父協(xié)議是什么。另外還要指出自己區(qū)別于父節(jié)點(diǎn)下的兄弟接點(diǎn)協(xié)議的特征。比如 FTP 協(xié)議。在 Ethereal 中他的父接點(diǎn)是 TCP 協(xié)議，它的特征就是 TCP 協(xié)議的 port 字段為 21。 這樣當(dāng)一個(gè)端口為 21 的 TCP 數(shù)據(jù)流來到時(shí)。首先由 TCP 協(xié)議注冊(cè)的解析模塊處理，處 理完之后通過查找協(xié)議樹找到自己協(xié)議下面的子協(xié)議，判斷應(yīng)該由那個(gè)子協(xié)議來執(zhí)行，找到正確的子協(xié)議后，就轉(zhuǎn)交給 FTP 注冊(cè)的解析模塊處理。這樣由根節(jié)點(diǎn)開始一層層解析下去。由于采用了協(xié)議樹加特征字的設(shè)計(jì)，這個(gè)系統(tǒng)在協(xié)議解析上由了很強(qiáng)的擴(kuò)展性，增加一個(gè)協(xié)議解析器只需要將解析函數(shù)掛到協(xié)議樹的相應(yīng)節(jié)點(diǎn)上即可。 最后，我們來看一下 Ethereal 最值得稱道也是它廣泛普及的 基于插件技術(shù)的協(xié)議分析器所謂插件技術(shù)，就是在程序的設(shè)計(jì)開發(fā)過程中，把整個(gè)應(yīng)用程序分成宿主程序和插件兩個(gè)部分，宿主程序與插件能夠相互通信，并且，在宿主程序不變 的情況下，應(yīng)用層 IP TCP UDP HTTP TFTP IP 協(xié)議及 IPSec 協(xié)議安全分析 21 可以通過增減插件或修改插件來調(diào)整應(yīng)用程序的功能。運(yùn)用插件技術(shù)可以開發(fā)出伸縮性良好、便于維護(hù)的應(yīng)用程序。它著名的應(yīng)用實(shí)例有：媒體播放器 Winamp、微軟的網(wǎng)絡(luò)瀏覽器 IE 等。 由于現(xiàn)在網(wǎng)絡(luò)協(xié)議種類繁多，為了可以隨時(shí)增加新的協(xié)議分析器，一般的協(xié)議分析器都采用插件技術(shù)，這樣如果需要對(duì)一個(gè)新的協(xié)議分析只需要開發(fā)編寫這個(gè)協(xié)議分析器并調(diào)用注冊(cè)函數(shù)在系統(tǒng)注冊(cè)就可以使用了。通過增加插件使程序有很強(qiáng)的可擴(kuò)展性，各個(gè)功能模塊內(nèi)聚。 然而 在協(xié)議分析器中新增加一個(gè)協(xié)議插件一般需要插件安裝或者注冊(cè)，插件初始化，插件處理 3 個(gè)步驟 ，下面以 Ethereal 為例進(jìn)行分析如何利用插件技術(shù)新增加一個(gè)協(xié)議分析模塊。 Ethereal 由于采用插件技術(shù)，程序員開發(fā)一種新的協(xié)議分析模塊的時(shí)候不需要 了解所 有的代碼，只需要寫好這個(gè)協(xié)議模塊的函數(shù)后，寫一個(gè)格式為 proto_reg_handoff_XXX 的函數(shù)，在函數(shù)內(nèi)調(diào)用注冊(cè)函數(shù)告訴系統(tǒng)在什么時(shí)候需要調(diào)用這個(gè)協(xié)議模塊。 這樣開發(fā)者不需要知道自己的注冊(cè)函數(shù)如何被調(diào)用的。這樣一個(gè)新的協(xié)議分析模塊就加入到系統(tǒng)中了。 由于采用了插件方式， Ethereal 良好的結(jié)構(gòu)設(shè)計(jì)讓 開發(fā)人員 只需要關(guān)系自己開發(fā)的協(xié)議模塊，不需要 關(guān)心整個(gè)系統(tǒng)結(jié)構(gòu) [14]，需要將模塊整合進(jìn)系統(tǒng)只需要寫一個(gè)注冊(cè)函數(shù)即可，連初始化時(shí)調(diào)用這個(gè)注冊(cè)函數(shù)都由腳本自動(dòng)完成了。 我想 也 正 是因?yàn)橛泻芎玫捏w系結(jié)構(gòu)，這個(gè)系統(tǒng)才能夠開發(fā)出如此多的協(xié)議解析器 。 但是， 網(wǎng)絡(luò)分析儀器用在網(wǎng)管手中是把雙刃劍，用好了可以幫你更好更有效的管理你的網(wǎng)絡(luò)環(huán)境，反之則會(huì)成為人們?cè)诰W(wǎng)絡(luò)上所說的“網(wǎng)絡(luò)嗅探器” 。 盡管 Ethereal是目前最好的開放源碼的網(wǎng)絡(luò)分析系統(tǒng)，但 Ethereal 仍然有一些可以改進(jìn)的地方，一個(gè)優(yōu)秀的網(wǎng)絡(luò)分析器，盡可能的正確分析出數(shù)據(jù)協(xié)議和高效的處理數(shù)據(jù)是兩個(gè)重要的指標(biāo)。在協(xié)議 識(shí)別方面 Ethereal 大多采用端口識(shí)別，有少量協(xié)議采用內(nèi)容識(shí)別。這就讓一些非標(biāo)準(zhǔn)端口的協(xié)議數(shù)據(jù)沒有正確解析出來。比如 FTP 協(xié)議如果不是 21 端口的話， Ethereal 就無法識(shí)別出來，只能作為 TCP 數(shù)據(jù)處理。另外對(duì)于內(nèi)容識(shí)別式。 Ethereal是將所以內(nèi)容識(shí)別的函數(shù)組成一張入口表。每次協(xié)議數(shù)據(jù)需要內(nèi)容識(shí)別時(shí)，按字母順序逐個(gè)調(diào)用表里的每個(gè)識(shí)別函數(shù)。比如對(duì)于識(shí)別 yahoo messenger 協(xié)議。由于協(xié)議名為 y 開頭。所以當(dāng)識(shí)別出協(xié)議時(shí)已經(jīng)把所有內(nèi)容識(shí)別函數(shù)調(diào)用了一遍。這些都是由于Ethereal 沒有實(shí)現(xiàn) TCP 協(xié)議 棧，無法做到流級(jí)別的識(shí)別。導(dǎo)致在協(xié)議識(shí)別方面有點(diǎn)缺陷。 不過我認(rèn)為只要今后它還一如既往的保持它的開源精神，那我們就永遠(yuǎn)不會(huì)失去IP 協(xié)議及 IPSec 協(xié)議安全分析 22 這么優(yōu)秀的網(wǎng)絡(luò)分析軟件。 Ethereal 源程序 結(jié)構(gòu) 分析 總體結(jié)構(gòu) Ethereal 結(jié)構(gòu)如圖 52 所示 ： 圖 52 Ethereal 功能模塊 首先，我們了解下 Ethereal 各功能模塊介紹： (1) GTK1/2 處理用戶的輸入輸出，源碼在 gtk 目錄 (2) Core 將其他模塊連接在一起，源碼在根目錄 (3) Epan Packet age Analyzing 包分析引擎，源碼在 epan 目錄。 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é)議解碼器。 ：一些協(xié)議解碼器以插件形式實(shí)現(xiàn)，源碼在 plugins 目錄。 (4) Capture 捕包引擎 (5) Wiretap 從文件中讀取數(shù)據(jù)包，支持多種文件格式，源碼在 wiretap 目錄 。 其次， Ethereal 各個(gè)模塊初始化流程 如下 ： (1) Capture_opts 初始化：讀取程序啟動(dòng)時(shí)參數(shù)以及從配 置文件中讀取信息； (2) Gtk 初始化； (3) Cf_callback_add： cf 回調(diào)函數(shù)初始化； (4) Epan 初始化： 初始化：全局變量 tvbuff_mem_chunk 指向用 memchunk 分配的固定大小的空閑內(nèi)存塊，每個(gè)內(nèi)存塊是 tvbufft 結(jié)構(gòu)，從空閑內(nèi)存塊中取出后，用來保存原始數(shù)據(jù)包。 ： 全局變量 proto_names， proto_short_names， proto_filter_names 以上三個(gè)全局變量主要用來判斷新注冊(cè)的協(xié)議名是否重復(fù)，如果重復(fù)，給出 提示信息，在協(xié)議解析過程中并沒有使用。 (5) Packet(包 )初始化 全局變量： 1. frame_handle：協(xié)議解析從 frame 開始，層層解析，直到所有的協(xié)議都解析完為止。 frame_handle 保存了 frame 協(xié)議的 handle。 ：有的協(xié)議無法從 frame 開始，那么就從 data 開始。 (6) Dfilter 模塊初始化 update_thread：這個(gè)線程和 tap 有關(guān) 取 配置文件 preference capture filter 和 display filter 文件，分別保存在全局變量 capture_filter 和display_filter 中。 4. 讀 disabled protocols 文件，保存全局變量 global_disabled_protos 和disabled_protos 中初始化全局變量 cfileCfile 是個(gè)重要的變量，數(shù)據(jù)類型為 capture file，它保存了數(shù)據(jù)包的所有信息，取得命令行啟動(dòng)時(shí)，參數(shù)列表，并進(jìn)行相應(yīng)的處理初始化 cfile 的 cinfo 字段 Gtk 相關(guān)初始化，顯示 Ethereal 主窗口，等待用戶IP 協(xié)議及 IPSec 協(xié)議安全分析 24 進(jìn)一步操作。 捕 包及讀文件模塊 首先分析下 Ethereal 的捕包流程： (1) 入口函數(shù)為 capture_start_cb (2) 捕包進(jìn)程和主程序是通過 PIPE 進(jìn)行傳遞數(shù)據(jù)的 (3) 捕包進(jìn)程和主程序之間沒有數(shù)據(jù)同步機(jī)制，也就是說，主程序不知道捕包程序是否丟包。當(dāng)主程序從捕包程序讀數(shù)據(jù)失敗時(shí)，返回。 (4) 主程序把捕獲的數(shù)據(jù)寫入到臨時(shí)文件中捕包進(jìn)程和主程序是同一個(gè)可執(zhí)行文件，只是通過文件名不同，執(zhí)行不同的操作。 (5) 其次，主程序在創(chuàng)建捕包進(jìn)程后的操作為：從 PIPE 中讀取數(shù)據(jù) ， 如果讀到的數(shù)據(jù)是新建文件，則新建一個(gè)文件 ， 如果是保存數(shù)據(jù)包，則將數(shù)據(jù)包寫入 剛 建立的文件 。 協(xié)議分析模塊 首先我們來分析下 Ethereal 的處理流程： (1) 從列表中選出一個(gè)數(shù)據(jù)包 (2) 提取選中數(shù)據(jù)包中的數(shù)據(jù)，填寫在數(shù)據(jù)結(jié)構(gòu)中 (3) 調(diào)用協(xié)議解析函數(shù) epan 的 Dissectors 進(jìn)行處理 實(shí)際上，這 才 是真正的協(xié)議解析過程 。 各協(xié)議分析模塊如圖 53 所示。 IP 協(xié)議及 IPSec 協(xié)議安全分析 25 圖 53 協(xié)議分析模塊 6 基于 IPSec 策略的網(wǎng)絡(luò)安全性分析 基于圖形化界面的 IPSec策略實(shí)現(xiàn) 試驗(yàn)拓?fù)鋱D 如圖 61 所示 ： 頁 1局 域 網(wǎng) 內(nèi) I P S e c 加 密 驗(yàn) 證F T P 服 務(wù) 器E t h e r e a l 測(cè) 試 機(jī)C l i P C 1C l i P C 2 圖 61 實(shí)驗(yàn)拓?fù)鋱D 從 Frame 協(xié)議開始 協(xié)議解析模塊 Hash 表 查找 Hash 表 判 斷是 否有 層協(xié) 議封裝 調(diào)用協(xié)議解析函數(shù)處理 將協(xié)議解析結(jié)果 程序初始化時(shí)生成 IP 協(xié)議及 IPSec 協(xié)議安全分析 26 首先， 我 來配置服務(wù)器端 FTP 站點(diǎn)。 要求：僅允許用管理員登陸 ，如圖 62 所示： 圖 62 登陸服務(wù)器顯示的信息 (1) 配置服務(wù)器端 IPSec 安全協(xié)議 要求： server 和 client 兩端 IPSec 要相互對(duì)應(yīng) (除目的地與原地址相反外，其他完全一致 。配置如圖 63 所示： 圖 63 Server 端 FTP 服務(wù)器源地址 IP 協(xié)議及 IPSec 協(xié)議安全分析 27 配置如圖 64 所示： 圖 64 Server 端 FTP 服務(wù)器目的地地址 (2) 之后要為這個(gè) IPSec 策略建立篩選器，這里 用帶完整性 (SHA_1 算法 )和加密(3DES 算法 )的協(xié)商安全，配置如圖 65 所示： 圖 65 協(xié)商安全時(shí)選擇的完整性和加密算法 (3) 要為雙方提供完全一致的預(yù)共享密鑰 ，配置如圖 66 所