專利名稱：基于流的IPSec VPN協(xié)議深度檢測方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種網(wǎng)絡(luò)安全技術(shù)領(lǐng)域中的檢測方法，具體是一種基于流的 IPSec VPN協(xié)議深度檢測方法。
背景技術(shù)：
IPSec是一種基礎(chǔ)設(shè)施性質(zhì)的安全技術(shù)。采用IPSec，可以提供原本IP協(xié) 議中沒有的安全特性機密性、完整性、身份驗證、抗流量分析等。而IPSec VPN 是采用IPSec安全協(xié)議建立VPN隧道，可以在公眾網(wǎng)上建立安全的虛擬通道以便 遠程訪問。IPSec VPN技術(shù)的各個方面都有很多國際標準，IPSec協(xié)議就有(IP Security -RFC 2401 2411, 2451)標準;加密有ESP DES和3DES (RFC 2406， 2451)標準，認證有X.509數(shù)字證書(RSA簽名)、共享密鑰、簡單證書登記協(xié) 議等標準；完整性有HMAC-MD5 & HMAC-SHA-l (RFC 2403-2404)等標準；密鑰 管理有互聯(lián)網(wǎng)密鑰交換(IKE) (RFC 2407-2409)等標準；還有證書管理、彈性、 管理選項、路由協(xié)議等等眾多標準。IPSec VPN設(shè)備制造商的VPN產(chǎn)品，大都遵 守以上的這些標準。
但是由于IPSec VPN和網(wǎng)絡(luò)地址轉(zhuǎn)換(NAT)穿越兼容性的問題的普遍存在， 很多VPN設(shè)備制造商采用了自己獨有的技術(shù)(比如UDP封裝或者HTTP封裝)來實 現(xiàn)IPSec VPN的NAT穿越。這就造成了 VPN設(shè)備之間的不兼容。為了改變這一狀 況，國家密碼管理局2008年1月8日發(fā)布了第14號公告《IPSec VPN技術(shù)規(guī) 范》，來規(guī)范IPSec VPN的架構(gòu)和各方面的具體實現(xiàn)。
由于IPSec VPN本身是加密的數(shù)據(jù)報文，而且由于為了實現(xiàn)IPSec的NAT 穿越，對標準的協(xié)議進行改動的情況也普遍存在。這就為在IPSec VPN中隱藏的 應(yīng)用層攻擊，或偽裝為IPSec報文欺騙防火墻和IDS 了留下了隱患。而深度檢測 技術(shù)，在原有的包過濾防火墻基于網(wǎng)絡(luò)層的安全檢查和狀態(tài)檢測防火墻上升到傳 輸層的安全檢查技術(shù)之上，進一步的上升到應(yīng)用層。按照Bivio Networks公司 CEO Elan Amir的說法，深度檢測技術(shù)是一種分析網(wǎng)絡(luò)流量的技術(shù)，不僅分析報文的頭部，而且進一步的去分析報文內(nèi)部的數(shù)據(jù)。
經(jīng)對現(xiàn)有技術(shù)的文獻檢索發(fā)現(xiàn)，清華大學的葉明江、崔勇等人在2007年的 軟件學報上發(fā)表的《基于有狀態(tài)Bloom filter引擎的高速分組檢測》提出了一 種基于有狀態(tài)Bloom filter引擎的高速分組檢測方法State Based Bloom filter engine (SABFE)。通過并行査找Bloom filter和前綴寄存器堆保持當前子串的匹 配狀態(tài)來檢測長的規(guī)則，能夠?qū)崿F(xiàn)線速的深度檢測。該方法雖然在速度和可擴展 性上都有優(yōu)點，但是對于非標準格式的報文，由于非標準的包頭的干擾，報文屬 于哪種協(xié)議類型都已經(jīng)變得不可識別，里面的字段內(nèi)容也因為非標準包頭全部錯 位，解析出來也會出錯，字符串匹配也派不上用場了。
進一步的檢索中，尚未發(fā)現(xiàn)針對IPSec VPN的深度檢測方法的文獻報道。

發(fā)明內(nèi)容
本發(fā)明的目的針對上述現(xiàn)有技術(shù)的不足，提供了一種基于流的IPSec VPN 協(xié)議深度檢測方法，能夠分析和識別非標準協(xié)議格式的IPSec VPN報文，并且能 夠根據(jù)上下文信息也即協(xié)議會話的狀態(tài)結(jié)合報文特征得出非標準格式的IPSec VPN報文和標準格式的IPSec VPN報文之間的區(qū)別，并且能夠?qū)PSec應(yīng)用層數(shù) 據(jù)關(guān)鍵字段進行提取，并做出相應(yīng)的處理。本發(fā)明提出的根據(jù)協(xié)議會話狀態(tài)的深 度檢測方法有相當?shù)闹悄苄?，可以分析未知格式的報文，而且實現(xiàn)簡單，性能穩(wěn) 定，可以應(yīng)用在監(jiān)察代理、防火墻、IDS等領(lǐng)域。
本發(fā)明是通過以下技術(shù)方案實現(xiàn)的，本發(fā)明包括如下步驟
步驟一在智能代理或者探針設(shè)備上把網(wǎng)卡設(shè)為混雜模式，并通過調(diào)用 libpc即網(wǎng)絡(luò)抓包庫函數(shù)進行循環(huán)監(jiān)聽，設(shè)置BPF抓包過濾器來抓取所有UDP 500 端口和4500端口的報文，也即IPSec VPN報文，通過設(shè)置回調(diào)函數(shù)callback為 基于流的深度檢測函數(shù)，每次抓到報文就會自動調(diào)用基于流的深度檢測函數(shù)進 行處理；回調(diào)函數(shù)callback是由系統(tǒng)接收到消息自動調(diào)用的函數(shù)。
本發(fā)明把基于流的深度檢測的函數(shù)地址作為參數(shù)設(shè)置為回調(diào)函數(shù)。因此， 當Libpcap抓到符合過濾規(guī)則(UDP 500和UDP 4500)的報文，就會自動去調(diào) 用基于流的深度檢測函數(shù)。
步驟二在回調(diào)函數(shù)也就是基于流的深度檢測函數(shù)中把抓取到的IPSec VPN 報文序列都保持在數(shù)據(jù)結(jié)構(gòu)中，對IPSec VPN報文序列的上下文進行分析和檢測，首先按照標準的IPSec VPN報文序列格式去解析，定位SA協(xié)商請求報文和協(xié)商 響應(yīng)報文，并提取VPN關(guān)鍵信息。如果能正確解析，那么該IPSecVPN報文序列 是標準的，如果不能解析，.那么說明IPSecVPN報文序列是非標準的或者是偽造 的。此時各個字段內(nèi)容都被打亂，按標準協(xié)議格式無法得知哪些是SA協(xié)商請求 分組，哪些是協(xié)商響應(yīng)分組。所以這時根據(jù)上下文信息特征分析檢測出哪個報文 是協(xié)商響應(yīng)報文，再對這些非標準的報文進行關(guān)鍵字段的提取，如果根據(jù)上下文 特征還檢測不出來，認為是偽造的IPSecVPN報文，這時可以觸發(fā)相關(guān)安全事件 進行處理。
步驟三根據(jù)上個步驟上下文信息也即基于流的深度檢測方法檢測出來的 協(xié)商響應(yīng)報文，尋找協(xié)商響應(yīng)報文中的NextPayLoadType，解析出標準或非標準 的IPSecVPN報文中所采用的加密算法、哈希算法、認證算法、群組簽名算法等， 從而檢測出其中不符合中國密碼管理委員會政策規(guī)定的算法，或者是VPN生產(chǎn)廠 家不按標準協(xié)議格式設(shè)計的非標準的IPSec VPN協(xié)議，或者是偽造的IPSec VPN 報文，并按照設(shè)置安全規(guī)則進行相應(yīng)的處理。根據(jù)該基于流的深度檢測方法應(yīng)用 的場合，這里的處理可以是報警、記錄日志等等。
所述的進行循環(huán)監(jiān)聽，并抓取IPSec VPN報文，具體為以下幾個步驟
1) 指定網(wǎng)卡或査找網(wǎng)卡
通過調(diào)用libpcap網(wǎng)絡(luò)抓包庫函數(shù)pcap_lookupdev選擇監(jiān)聽的網(wǎng)卡設(shè)備。 libpcap是一個與實現(xiàn)無關(guān)的訪問操作系統(tǒng)所提供的分組捕獲機制的分組捕獲函 數(shù)庫，用于訪問數(shù)據(jù)鏈路層。著名的ethereal抓包嗅探分析工具，也即現(xiàn)在的 wireshark，就是基于libpcap實現(xiàn)的。著名的開源IDS軟件，snort，也是基于
libpcap的。
2) 打開設(shè)備監(jiān)聽
調(diào)用libpcap庫函數(shù)pc鄰—open—live,把網(wǎng)卡設(shè)置使用混雜模式。
3) 設(shè)定監(jiān)聽規(guī)則
通過設(shè)置libpcap網(wǎng)絡(luò)抓包庫提供的抓包過濾器BPF(Barkley Packet Fi 1 ter)來設(shè)置抓包條件(具體為UDP報文，端口 500和4500);調(diào)用pcap—compile 對抓包過濾條件(BPF)進行編譯，變成匯編代碼(所以它的性能非常好)，然后 調(diào)用pcap—setfilter實施該規(guī)則。4) 處理特定分組
調(diào)用libpcap庫函數(shù)pcap—loop,將接收分組數(shù)設(shè)為-1，表示無限循環(huán)。
5) 設(shè)定回調(diào)函數(shù)(callback)
設(shè)定基于流的IPSec VPN深度檢測的方法為回調(diào)函數(shù)(指定了回調(diào)函數(shù)之 后，當網(wǎng)卡上出現(xiàn)了符合過濾條件的報文，就會自動觸發(fā)中斷，由回調(diào)函數(shù)對這 個中斷進行響應(yīng))。每次抓到一個符合過濾條件的數(shù)據(jù)包就循環(huán)調(diào)用回調(diào)函數(shù)這 里也既基于流的IPSec VPN深度檢測方法進行分析和提取。
6) 關(guān)閉監(jiān)聽
調(diào)用libpcap庫函數(shù)pcap—close，結(jié)束監(jiān)聽。
所述的對IPSec VPN報文序列的上下文進行分析和檢測，具體為利用SA 協(xié)商請求在前，協(xié)商響應(yīng)分組在后的上下文特征，在因為非標準格式從而序列中 所有報文都無法解析的情況下，結(jié)合協(xié)商請求報文和協(xié)商響應(yīng)分組自身的報文特 征來分析和檢測，找到哪個是協(xié)商響應(yīng)分組，并在協(xié)商響應(yīng)分組中的SApayload 字段中提取其中包括加密算法、哈希算法等關(guān)鍵VPN信息。如果要檢測IPSec VPN 所使用的加密算法、哈希算法、認證算法、組描述算法等參數(shù)，在報文都是標準 的情況下，只需要抓取協(xié)商響應(yīng)分組即可。也就是不需要利用上下文信息。
這里所述的SA協(xié)商請求分組和協(xié)商響應(yīng)分組的特征具體為SA協(xié)商請求與 SA協(xié)商響應(yīng)的主要區(qū)別是是否存在8字節(jié)的Responder Cookie，有則是SA協(xié)商 響應(yīng)，否則為SA協(xié)商請求，而SA協(xié)商響應(yīng)與其他IKE分組的區(qū)別在于Next Payload Type值。
所述的協(xié)商請求分組和協(xié)商響應(yīng)分組，是指IPSec VPN采用IKE協(xié)議完成 密鑰協(xié)商過程，發(fā)起方VPN (Initiator)首先向接收方VPN (Responder)發(fā)起開始 ISAKMP SA協(xié)商的請求，即利用IKE協(xié)議發(fā)送包含多個包含不同加密算法、哈希 算法組合的傳輸方案，稱該網(wǎng)絡(luò)分組為協(xié)商請求分組。接收方VPN收到該分組后， 對發(fā)起方進行反饋，即利用IKE協(xié)議發(fā)送唯一認可的一個傳輸方案，稱為協(xié)商響 應(yīng)分組。
所述的IKE (Internet Key Exchange, RFC2409):因特網(wǎng)密鑰交換協(xié)議是 一個以受保護的方式動態(tài)協(xié)商SA (Secure Association安全關(guān)聯(lián))的協(xié)議。IKE 是一個混合的協(xié)議，它由Internet密鑰交換協(xié)議(IKE， RFC2409)、 Internet安全關(guān)聯(lián)和密鑰交換協(xié)議(ISAKMP， RFC2408)、 Oakley密鑰確定協(xié)議(RFC2412)、 IPSec Domain of Interpretation (IPSec DOI， RFC2407)組成。IKE分兩個階 段實現(xiàn)第一階段為建立IKE本身使用的安全信道而相互交換SA(采用ISAKMP)， 第二階段利用第一階段建立的安全信道交換IPSec通信中使用的SA。
所述的ISAKMP協(xié)議(Internet Security Association and Key Management Protocol, RFC2407)，提供密鑰管理架構(gòu)，定義了 SA的建立、協(xié)商、修改、刪 除規(guī)程和分組格式，ISAKMP協(xié)議獨立于密鑰交換協(xié)議、加密算法和認證方法， ISAKMP下層由UDP協(xié)議承載，端口號為500，如果有NAT存在，也可以是4500 端口。 ISAKMP協(xié)議交換4到6個報文，分三個步驟
1) 協(xié)商安全參數(shù)
2) Diffie-Hellman交換
3) 認證實體
這三個步驟可以通過主模式也可以通過野蠻模式來完成。
所述的主模式(Main Mode)是按照以上三個步驟嚴格，安全的進行密鑰交 換管理的。發(fā)送6個報文(假設(shè)是Alice向Bob發(fā)起)
1) Alice+Bob: Crypto suites I support發(fā)起方支持的加密方案(協(xié)商請 求分組)
2) Bob今Alice: Crypto suite I choose 接受方選中的加密方案(協(xié)商 響應(yīng)分組)
3) Alice+Bob: gamod p (Diffie-Hellman交換)
4) Bob+Alice: gb mod p (Diffie-Hellman交換)
5) Alice+Bob: gab mod p{ "Alice" ， Proof I， m Alice}(力口密認證Alice
身份)
6) Bob+Alice: gab mod p{ "Bob" 'Proof I， m Bob}(加密認證Bob身
份)
所述的野蠻模式(Aggressive Mode):是用來簡化規(guī)程和提高處理效率的 方式，發(fā)送3個報文(假設(shè)是Alice向Bob發(fā)起的)1) Alice》Bob: ga mod p， "Alice" ， crypto proposal
2) Bob+Alice: gb mod p， crypto choice, proof I， m Bob
3) Alice—Bob: Proof r ra Alice
不論是在主模式下還是在野蠻模式下，SA協(xié)商請求分組、SA協(xié)商響應(yīng)分組 和其他IKE協(xié)議分組的區(qū)別特征都是一致的，如下表所示
IKE協(xié)議類型Initiator CookieResponder CookieNext Payload Type
SA協(xié)商請求有無，即8字節(jié)01
SA協(xié)商響應(yīng)有有1
其他分組有有非l
所述的SA協(xié)商響應(yīng)分組的特征，有兩點1).相比于SA協(xié)商請求Responder Cookie不為0， 2).相比其他分組，Next Payload Type為l。而由于Responder Cookie為8字節(jié)隨機碼，在非標準IPSec中無法直接判斷。另外Next Payload Type只有一個字節(jié)，在非標準IPSec分組中無法定位。這兩點特征都沒有辦法 直接利用。
所述的結(jié)合協(xié)商請求報文和協(xié)商響應(yīng)分組自身的報文特征來分析和檢測是 把SA協(xié)商請求報文作為上文，SA協(xié)商響應(yīng)報文作為下文，然后是進一步的協(xié)商 分組。先搜索連續(xù)8個字節(jié)的0加一個字節(jié)1的Responder Cookie,能找到這 個特征標致的作為上文，也就是SA協(xié)商請求報文，通過比對和標準格式的差異， 確定該非標準協(xié)議做了哪些改動。通過相同的反改動就可以對包含Next Payload Type字段值為1的分組，也即下文SA協(xié)商響應(yīng)報文中提取想要提取的關(guān)鍵信 息。
本發(fā)明可以在多種網(wǎng)絡(luò)設(shè)備中得到應(yīng)用，如防火墻、IDS等各種網(wǎng)絡(luò)安全設(shè) 備，協(xié)議分析代理設(shè)備。在這樣的網(wǎng)絡(luò)安全設(shè)備中，應(yīng)用本發(fā)明，可以檢測標準 和非標準的IPSec連接，并了解這些連接中使用的加密算法、哈希算法等信息。 通過應(yīng)用本發(fā)明，本來不能解析的非標準的IPSec VPN連接信息可以得到解析。 可以為網(wǎng)管提供更加準確的VPN使用情況，以便對VPN進行監(jiān)督。也可以防止偽 造的VPN報文進行攻擊，提供更高的安全性。


圖l本發(fā)明實施例應(yīng)用架構(gòu)圖； 圖2本發(fā)明實施例IKE協(xié)議格式； 圖3本發(fā)明實施例的流程圖。
具體實施例方式
下面結(jié)合附圖對本發(fā)明的實施例作詳細說明本實施例在以本發(fā)明技術(shù)方 案為前提下進行實施，給出了詳細的實施方式和具體的操作過程，但本發(fā)明的保 護范圍不限于下述的實施例。
如圖1所示，IPSecVPN監(jiān)察系統(tǒng)分為中心端和代理端兩部分，結(jié)合IPSec VPN 監(jiān)察系統(tǒng)具體說明本實施例
代理端分布配置在各單位邊界網(wǎng)絡(luò)中的交換機鏡像端口，代理端有兩個網(wǎng) 絡(luò)接口， 一個用來抓包， 一個用來和中心端通信。IPSec VPN流量會流經(jīng)邊界網(wǎng) 絡(luò)的交換機，并被監(jiān)察系統(tǒng)代理端所抓取到，其中包括IPSec VPN的ISAKMP協(xié) 議報文，其報文格式如圖2所示。監(jiān)察代理按照基于流的IPSec VPN深度檢測方 法進行分析，提取其中的關(guān)鍵信息，并把分析出的數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送到中心端， 而中心端主要負責將各個代理點匯報的數(shù)據(jù)進行匯總、分析和數(shù)據(jù)挖掘以及報警 管理，并向前臺管理員用戶把抓到的各IPSec VPN關(guān)鍵信息以圖形化方式展示。
代理端以2. 6內(nèi)核以上Linux系統(tǒng)為基礎(chǔ)，并在Linux系統(tǒng)中安裝了Libpcap 的網(wǎng)絡(luò)抓包庫。Libpcap是一個C語言庫，英文意思為Packet Capture library, 其功能是通過網(wǎng)卡抓取以太網(wǎng)中的數(shù)據(jù)包，為不同平臺提供了統(tǒng)一的編程接口。
代理端分為兩個模塊，主模塊負責向中心端通報IPSec信息，接受來自中 心端的配置更新等命令。子模塊則負責在特定端口抓包，并進行分析和提取。子 模塊的具體過程如下
如圖3所示，本實施例包括如下步驟
步驟一，抓取UDP 500端口和UDP 4500端口的數(shù)據(jù)包，這是ISAKMP協(xié)議 所使用的端口；
步驟二，根據(jù)數(shù)據(jù)包的源IP地址，目的IP地址，源端口號和目的端口號 去數(shù)據(jù)庫(此處的數(shù)據(jù)庫指的是代理端為了維護上下文信息建立的數(shù)據(jù)庫)中査 詢該VPN連接的狀態(tài)。若沒有査到相關(guān)記錄，則執(zhí)行步驟三，如果査到，且狀態(tài)為未取得SA協(xié)商響應(yīng)，則執(zhí)行步驟四；若査到狀態(tài)為已取得SA協(xié)商響應(yīng)，則執(zhí) 行步驟五；
步驟三，從UDP數(shù)據(jù)包開始尋找連續(xù)8個字節(jié)的0，連續(xù)的8個字節(jié)的0是 Initiator Cookie的標志，表明這很可能是SA協(xié)商請求報文。這是從上文得出 的信息，但并不知道每個數(shù)據(jù)包是什么類型的IPSecVPN報文。若找到，那假設(shè) 找到的這個報文就是IPSec VPN的協(xié)商請求報文，如果抓到的報文是個非標準的 ISAKMP報文，而且假設(shè)在上下文中每個非標準的報文和標準報文之間的區(qū)別是 一致的，根據(jù)前述8個字節(jié)的0在報文中的位置，得出所抓取的ISAKMP報文和 標準協(xié)議報文的差異，這里體現(xiàn)在一個偏移量的值，這個值等于非標準協(xié)議報文 添加的一些信息。把這個偏移量值與源IP地址，目的IP地址，源端口號和目的 端口號一起存入數(shù)據(jù)庫，并執(zhí)行步驟五，若沒有找到，則直接結(jié)束，并向中心端 上報一個警告。不能按照基于流的IPSecVPN協(xié)議深度檢測方法去解析，抓到的 IPSec VPN報文認為是偽造的；
步驟四，根據(jù)這個偏移量值，把非標準協(xié)議的報文偏移成標準協(xié)議報文格 式，按照標準協(xié)議報文的上下文關(guān)系，在ISAKMP協(xié)議的下文中去尋找Next Pay load Type字段，看看值是否為1，來進一步驗證上文的信息。若是這樣，那 么后面的payload字段中就有該IPSec VPN的關(guān)鍵信息，如加密算法，哈希算法， 認證算法等，并跳轉(zhuǎn)執(zhí)行步驟五，如果不是這樣，那說明上下文中的信息還不夠 用來分析，就再接著積累上下文信息，直接執(zhí)行五；
步驟五，將系統(tǒng)當前時間寫入數(shù)據(jù)庫(還是那個上述維護上下文信息的數(shù) 據(jù)庫)；
步驟六，定期清理數(shù)據(jù)庫，將最后訪問時間早于某一閾值的記錄項全部清空。
該IPSec VPN監(jiān)察系統(tǒng)能夠?qū)藴实腎PSec VPN協(xié)議進行深度檢測，也能 夠?qū)Ψ菢藴实腎PSec VPN協(xié)議進行深度檢測，甚至能檢測出一些偽造的IPSec VPN 協(xié)議。該監(jiān)察系統(tǒng)使用的基于流的IPSec VPN協(xié)議深度檢測方法簡單，易于實現(xiàn)， 并且檢測速度很塊。可以廣泛應(yīng)用到防火墻，入侵檢測系統(tǒng)，以及各種智能代理 或探針中。該系統(tǒng)使用了一款基于酷睿2平臺的雙千兆口工控主機，能夠?qū)崿F(xiàn)千 兆線速的IPSec VPN抓包速度。該系統(tǒng)的準確性用誤報率和漏檢率兩個指標來衡量。 誤報率分析
該深度檢測方法能識別出非標準協(xié)議和標準協(xié)議之間的區(qū)別，被識別為非 標準協(xié)議格式的誤報率幾乎為0，但是有可能把某些非標準協(xié)議認為是偽造的 IPSecVPN報文，如果非標準協(xié)議與標準協(xié)議差異太大的話，具體的說，是加入 了不止一段的自定義字段。這種情況通常比較少見。
漏檢率分析
如果非標準協(xié)議使用了除了 500端口和4500端口以外的端口 。那該IPSec VPN監(jiān)察系統(tǒng)可能會漏過對這個IPSec VPN的分析。這種情況也比較少見。
權(quán)利要求
1、 一種基于流的IPSec VPN協(xié)議深度檢測方法，其特征在于，包括如下步驟步驟一在智能代理或者探針設(shè)備上把網(wǎng)卡設(shè)為混雜模式，并通過調(diào)用libpcap網(wǎng)絡(luò)抓包庫函數(shù)進行循環(huán)監(jiān)聽，設(shè)置BPF抓包過濾器來抓取所有UDP 500端口和4500端口的報文，也即IPSec VPN報文，設(shè)置回調(diào)函數(shù)callback為基于流的深度檢測函數(shù)，每次抓到報文就會自動調(diào)用基于流的深度檢測函數(shù)進行處理；所述回調(diào)函數(shù)callback是由系統(tǒng)接收到消息自動調(diào)用的函數(shù)，將基于流的深度檢測的函數(shù)地址作為參數(shù)設(shè)置為回調(diào)函數(shù)，當Libpcap抓到符合過濾規(guī)則UDP 500和UDP 4500的報文，就會自動去調(diào)用基于流的深度檢測函數(shù)；步驟二在回調(diào)函數(shù)也就是基于流的深度檢測函數(shù)中把抓取到的IPSec VPN報文序列都保持在數(shù)據(jù)結(jié)構(gòu)中，對IPSec VPN報文序列的上下文進行分析和檢測，首先按照標準的IPSec VPN報文序列格式去解析，定位SA協(xié)商請求報文和協(xié)商響應(yīng)報文，并提取VPN關(guān)鍵信息；如果能正確解析，那么該IPSec VPN報文序列是標準的，如果不能解析，那么說明IPSec VPN報文序列是非標準的或者是偽造的，此時各個字段內(nèi)容都被打亂，按標準協(xié)議格式無法得知哪些是SA協(xié)商請求分組，哪些是協(xié)商響應(yīng)分組，這時根據(jù)上下文信息特征分析檢測出哪個報文是協(xié)商響應(yīng)報文，再對這些非標準的報文進行關(guān)鍵字段的提取，如果根據(jù)上下文特征還檢測不出來，則認為是偽造的IPSec VPN報文，這時觸發(fā)相關(guān)安全事件進行處理；步驟三根據(jù)上個步驟上下文信息也即基于流的深度檢測方法檢測出來的協(xié)商響應(yīng)報文，尋找協(xié)商響應(yīng)報文中的NextPayLoadType，解析出標準或非標準的IPSec VPN報文中所采用算法，從而檢測出其中不符合中國密碼管理委員會政策規(guī)定的算法，或者是VPN生產(chǎn)廠家不按標準協(xié)議格式設(shè)計的非標準的IPSec VPN協(xié)議，或者是偽造的IPSec VPN報文，并按照設(shè)置安全規(guī)則進行報警、或者記錄日志處理。
2、 根據(jù)權(quán)利要求l所述的基于流的IPSec VPN協(xié)議深度檢測方法，其特征是，所述的進行循環(huán)監(jiān)聽，并抓取IPSec VPN報文，具體為以下幾個步驟 1)指定網(wǎng)卡或査找網(wǎng)卡通過調(diào)用libpc即網(wǎng)絡(luò)抓包庫函數(shù)pcapJook叩dev選擇監(jiān)聽的網(wǎng)卡設(shè)備， libpcap是一個與實現(xiàn)無關(guān)的訪問操作系統(tǒng)所提供的分組捕獲機制的分組捕獲函數(shù)庫，用于訪問數(shù)據(jù)鏈路層；2) 打開設(shè)備監(jiān)聽調(diào)用libpcap庫函數(shù)pcap—open—live，把網(wǎng)卡設(shè)置使用混雜模式；3) 設(shè)定監(jiān)聽規(guī)則通過設(shè)置libpcap網(wǎng)絡(luò)抓包庫提供的抓包過濾器BPF來設(shè)置抓包條件，具體 為UDP報文，端口 500和4500;調(diào)用pcap—compile對抓包過濾條件進行編譯， 變成匯編代碼，然后調(diào)用pcap一setfilter實施該規(guī)則；4) 處理特定分組調(diào)用libpcap庫函數(shù)pcap」o叩，將接收分組數(shù)設(shè)為-1，表示無限循環(huán)；5) 設(shè)定回調(diào)函數(shù)callback設(shè)定基于流的IPSecVPN深度檢測的方法為回調(diào)函數(shù)，指定了回調(diào)函數(shù)之后， 當網(wǎng)卡上出現(xiàn)了符合過濾條件的報文，就會自動觸發(fā)中斷，由回調(diào)函數(shù)對這個中 斷進行響應(yīng)，每次抓到一個符合過濾條件的數(shù)據(jù)包就循環(huán)調(diào)用回調(diào)函數(shù)這里也既 基于流的IPSec VPN深度檢測方法進行分析和提取；6) 關(guān)閉監(jiān)聽調(diào)用libpc即庫函數(shù)pcap—close,結(jié)束監(jiān)聽。
3、 根據(jù)權(quán)利要求1所述的基于流的IPSec VPN協(xié)議深度檢測方法，其特征 是，所述的對IPSec VPN報文序列的上下文進行分析和檢測，具體為利用SA 協(xié)商請求在前，協(xié)商響應(yīng)分組在后的上下文特征，在因為非標準格式從而序列中 所有報文都無法解析的情況下，結(jié)合協(xié)商請求報文和協(xié)商響應(yīng)分組自身的報文特 征來分析和檢測，找到哪個是協(xié)商響應(yīng)分組，并在協(xié)商響應(yīng)分組中的SApayload 字段中提取其中關(guān)鍵VPN信息；如果要檢測IPSec VPN所使用的加密算法、哈希 算法、認證算法、組描述算法，在報文都是標準的情況下，只需要抓取協(xié)商響應(yīng)分組，不需要利用上下文信息。
4、 根據(jù)權(quán)利要求3所述的基于流的IPSec VPN協(xié)議深度檢測方法，其特征是，所述的結(jié)合協(xié)商請求報文和協(xié)商響應(yīng)分組自身的報文特征來分析和檢測是把 SA協(xié)商請求報文作為上文，SA協(xié)商響應(yīng)報文作為下文，然后是進一步的協(xié)商分 組先搜索連續(xù)8個字節(jié)的0加一個字節(jié)1的Responder Cookie,能找到這個 特征標致的作為上文，也就是SA協(xié)商請求報文，通過比對和標準格式的差異， 確定該非標準協(xié)議做了哪些改動，通過相同的反改動就可以對包含Next Payload Type字段值為1的分組，也即下文SA協(xié)商響應(yīng)報文中提取想要提取的關(guān)鍵信 息。
5、 根據(jù)權(quán)利要求1所述的基于流的IPSec VPN協(xié)議深度檢測方法，其特征 是，所述的SA協(xié)商請求分組和協(xié)商響應(yīng)分組的特征具體為SA協(xié)商請求與SA 協(xié)商響應(yīng)的主要區(qū)別是是否存在8字節(jié)的Responder Cookie,有則是SA協(xié)商響 應(yīng)，否則為SA協(xié)商請求，而SA協(xié)商響應(yīng)與其他IKE分組的區(qū)別在于Next Payload Type值。
6、 根據(jù)權(quán)利要求1所述的基于流的IPSec VPN協(xié)議深度檢測方法，其特征 是，所述的協(xié)商請求分組和協(xié)商響應(yīng)分組，是指IPSec VPN采用IKE協(xié)議完成 密鑰協(xié)商過程，發(fā)起方VPN首先向接收方VPN發(fā)起開始ISAKMP SA協(xié)商的請求， 即利用IKE協(xié)議發(fā)送包含多個包含不同加密算法、哈希算法組合的傳輸方案，稱 該網(wǎng)絡(luò)分組為協(xié)商請求分組；接收方VPN收到該分組后，對發(fā)起方進行反饋，即 利用IKE協(xié)議發(fā)送唯一認可的一個傳輸方案，稱為協(xié)商響應(yīng)分組。
7、 根據(jù)權(quán)利要求1所述的基于流的IPSec VPN協(xié)議深度檢測方法，其特征 是，所述的ISAKMP協(xié)議，提供密鑰管理架構(gòu)，定義了SA的建立、協(xié)商、修改、 刪除規(guī)程和分組格式，ISAKMP協(xié)議獨立于密鑰交換協(xié)議、加密算法和認證方法， ISAKMP下層由UDP協(xié)議承載，端口號為500，如果有NAT存在，也可以是4500 端口， ISAKMP協(xié)議交換4到6個報文，分三個步驟1) 協(xié)商安全參數(shù)2) Diffie-Hellman交換3) 認證實體這三個步驟通過主模式或者野蠻模式來完成。
全文摘要
一種基于流的IPSec VPN協(xié)議深度檢測方法，用于網(wǎng)絡(luò)安全領(lǐng)域。本發(fā)明首先在智能代理或探針機器上打開網(wǎng)卡的混雜模式進行循環(huán)監(jiān)聽，并且設(shè)置BPF過濾器抓取IPSec VPN報文。對IPSec報文序列流存儲并進行深度檢測，識別和分析IPSec VPN報文是否為偽造，是否是非標準格式報文，并且能夠根據(jù)IPSec VPN報文序列流的上下文解析出非標準格式報文和標準格式報文之間的區(qū)別。本發(fā)明提出的根據(jù)協(xié)議會話狀態(tài)的深度檢測方法有相當?shù)闹悄苄?，可以分析未知格式的報文，而且實現(xiàn)簡單，性能穩(wěn)定，可以應(yīng)用在監(jiān)察代理、防火墻、IDS等領(lǐng)域。
文檔編號H04L29/06GK101286896SQ20081003855
公開日2008年10月15日 申請日期2008年6月5日 優(yōu)先權(quán)日2008年6月5日
發(fā)明者周志洪, 張月國, 李建華, 蔣興浩, 訾小超 申請人:上海交通大學