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

發(fā)明內(nèi)容
本發(fā)明的目的針對上述現(xiàn)有技術(shù)的不足，提供了一種基于報文偏移量匹配的 IPSec VPN協(xié)議深度檢測方法，能夠分析和識別非標(biāo)準(zhǔn)協(xié)議格式的IPSec VPN報 文，并且能夠IPSec自身的報文特征得出非標(biāo)準(zhǔn)格式的IPSec VPN報文和標(biāo)準(zhǔn)格 式的IPSec VPN報文之間的區(qū)別，并且能夠?qū)PSec應(yīng)用層數(shù)據(jù)關(guān)鍵字段進(jìn)行提 取，并做出相應(yīng)的處理。本發(fā)明提出的根據(jù)協(xié)議會話狀態(tài)的深度檢測方法有相當(dāng) 的智能性，可以分析未知格式的報文，而且實(shí)現(xiàn)簡單，性能穩(wěn)定，可以應(yīng)用在監(jiān) 察代理、防火墻、IDS等領(lǐng)域。
本發(fā)明是通過如下技術(shù)方案實(shí)現(xiàn)的，本發(fā)明包括如下步驟 步驟一在智能代理或者探針設(shè)備上把網(wǎng)卡設(shè)為混雜模式，并通過調(diào)用 libpcap網(wǎng)絡(luò)抓包庫函數(shù)進(jìn)行循環(huán)監(jiān)聽，設(shè)置BPF抓包過濾器來抓取所有UDP 500 端口和4500端口的報文，也即IPSec VPN報文，通過設(shè)置回調(diào)函數(shù)callback 為基于報文偏移量匹配的深度檢測函數(shù)，每次抓到報文就會自動調(diào)用基于報文偏 移量匹配的深度檢測函數(shù)進(jìn)行處理；回調(diào)函數(shù)callback是由系統(tǒng)接收到消息自 動調(diào)用的函數(shù)。
本發(fā)明把基于報文偏移量匹配的深度檢測的函數(shù)地址作為參數(shù)設(shè)置為回調(diào) 函數(shù)。因此，當(dāng)Libpcap抓到符合過濾規(guī)則(UDP 500和UDP 4500)的報文， 就會自動去調(diào)用基于報文偏移量匹配的深度檢測函數(shù)。
步驟二在回調(diào)函數(shù)也就是基于報文偏移量匹配的深度檢測函數(shù)中，首先按照標(biāo)準(zhǔn)的IPSec VPN報文格式去解析，試圖找到SA協(xié)商響應(yīng)報文，并嘗試在該 報文中提取VPN關(guān)鍵信息。如果能正確解析，那么該IPSecVPN報文格式是標(biāo)準(zhǔn) 的，如果不能解析，那么說明IPSecVPN報文是非標(biāo)準(zhǔn)的或者是偽造的。此時各 個字段內(nèi)容都被打亂，按標(biāo)準(zhǔn)協(xié)議格式無法得知確切的報文類型。這時根據(jù)報文 內(nèi)部的結(jié)構(gòu)特征去變換和匹配檢測出IPSec VPN非標(biāo)準(zhǔn)報文和標(biāo)準(zhǔn)報文之間的區(qū) 別，因?yàn)榉菢?biāo)準(zhǔn)報文也是在標(biāo)準(zhǔn)報文內(nèi)容里面添加了一些字段。格式總有很多是 相同的地方。然后找出協(xié)商響應(yīng)報文，再對非標(biāo)準(zhǔn)的報文進(jìn)行關(guān)鍵字段的提取， 如果根據(jù)報文偏移量特征匹配的方式還檢測不出來，認(rèn)為是偽造的IPSec VPN 報文，這時可以觸發(fā)相關(guān)安全事件進(jìn)行處理。
步驟三根據(jù)上個步驟根據(jù)上下文信息也即基于報文偏移量匹配的深度檢測 方法檢測出來的協(xié)商響應(yīng)報文，尋找協(xié)商響應(yīng)報文中的NextPayLoadType，解析 出標(biāo)準(zhǔn)或非標(biāo)準(zhǔn)的IPSec VPN報文中所采用的加密算法、哈希算法、認(rèn)證算法、 群組簽名算法等，檢測其中是否有不符合中國密碼管理委員會政策規(guī)定的算法， 或者是VPN生產(chǎn)廠家不按標(biāo)準(zhǔn)協(xié)議格式設(shè)計的非標(biāo)準(zhǔn)的IPSec VPN協(xié)議，或者是 偽造的IPSecVPN報文，并按照設(shè)置安全規(guī)則進(jìn)行相應(yīng)的處理。根據(jù)該基于報文 偏移量匹配的IPSecVPN深度檢測方法應(yīng)用的場合，這里的處理可以是報警、記 錄日志等等。
所述的進(jìn)行循環(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是一個與實(shí)現(xiàn)無關(guān)的訪問操作系統(tǒng)所提供的分組捕獲機(jī)制的分組捕獲 函數(shù)庫，用于訪問數(shù)據(jù)鏈路層。著名的ethereal抓包嗅探分析工具，也即現(xiàn)在 的wireshark，就是基于libpcap實(shí)現(xiàn)的。著名的開源IDS軟件，snort，也是 基于libpc即的0
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(Barkley Packet FiIter)來設(shè)置抓包條件(具體為UDP報文，端口 500和4500);調(diào)用pcap—compile 對抓包過濾條件(BPF)進(jìn)行編譯，變成匯編代碼(所以它的性能非常好)，然后調(diào)用pcap—setfilter實(shí)施該規(guī)則。
4) 處理特定分組
調(diào)用libpcap庫函數(shù)pcapjoop，將接收分組數(shù)設(shè)為-1，表示無限循環(huán)。
5) 設(shè)定回調(diào)函數(shù)(callback)
設(shè)定基于報文偏移量匹配的IPSecVPN深度檢測的方法為回調(diào)函數(shù)(指定了 回調(diào)函數(shù)之后，當(dāng)網(wǎng)卡上出現(xiàn)了符合過濾條件的報文，就會自動觸發(fā)中斷，由回 調(diào)函數(shù)對這個中斷進(jìn)行響應(yīng))。每次抓到一個符合過濾條件的數(shù)據(jù)包就循環(huán)調(diào)用 回調(diào)函數(shù)這里也既基于報文偏移量匹配的IPSec VPN深度檢測方法進(jìn)行分析和提 取。
6) 關(guān)閉監(jiān)聽
調(diào)用libpcap庫函數(shù)pcap—close，結(jié)束監(jiān)聽。
所述的基于報文偏移量模式匹配深度檢測，具體為利用報文自身的偏移量 模式特征，不依賴于上下文信息。在因?yàn)閳笪母袷椒菢?biāo)準(zhǔn)從而序列中所有報文都 無法解析其確切的類型的情況下，根據(jù)SA協(xié)商請求分組和協(xié)商響應(yīng)分組的報文
偏移量特征，找到哪個是非標(biāo)準(zhǔn)的協(xié)商響應(yīng)分組，并在非標(biāo)準(zhǔn)協(xié)商響應(yīng)分組中的 SA payload字段中提取其中包括加密算法、哈希算法等關(guān)鍵VPN信息。如果要 檢測IPSec VPN所使用的加密算法、哈希算法、認(rèn)證算法、組描述算法等參數(shù)， 在報文都是標(biāo)準(zhǔn)的情況下，只需要抓取協(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ā)起方進(jìn)行反饋，即利用IKE協(xié)議發(fā)送唯一認(rèn)可的一個傳輸方案，稱為協(xié)商響 應(yīng)分組。
所述的IKE (Internet Key Exchange, RFC2409):因特網(wǎng)密鑰交換協(xié)議是一個以受保護(hù)的方式動態(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， RFC2術(shù))組成。IKE分兩個階 段實(shí)現(xiàn)第一階段為建立ike本身使用的安全信道而相互交換sa(采用isakmp)， 第二階段利用第一階段建立的安全信道交換IPSec通信中使用的SA。
所述的ISAKMP協(xié)議(Internet Security Association and Key Management Protocol, RFC2407)，提供密鑰管理架構(gòu)，定義了 SA的建立、協(xié)商、修改、刪 除規(guī)程和分組格式，ISAKMP協(xié)議獨(dú)立于密鑰交換協(xié)議、加密算法和認(rèn)證方法， ISAKMP下層由UDP協(xié)議承載，端口號為500，如果有NAT存在，也可以是4500 端口。 ISAKMP協(xié)議交換4到6個報文，分三個步驟
1) 協(xié)商安全參數(shù)
2) Diffie-Hellman交換
3) 認(rèn)證實(shí)體
這三個步驟可以通過主模式也可以通過野蠻模式來完成。
所述的主模式(Main Mode)是按照以上三個步驟嚴(yán)格，安全的進(jìn)行密鑰交 換管理的。發(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: gabmodp{ "Alice" ， Proof I， m Alice}(力口密認(rèn)i正Alice
身份)
6) Bob+Alice: gab mod p{ "Bob" , Proof I， m Bob}(加密認(rèn)證Bob身
份)
所述的野蠻模式(Aggressive Mode):是用來簡化規(guī)程和提高處理效率的方式，發(fā)送3個報文(假設(shè)是Alice向Bob發(fā)起的)1) Alice">Bob: ga mod p， "Alice" , crypto proposal2) Bob~>Alice: gb mod p, crypto choice, proof I， m Bob3) Alice今Bob: Proof I' m Alice不論是在主模式下還是在野蠻模式下，SA協(xié)商請求分組、SA協(xié)商響應(yīng)分組 和其他IKE協(xié)議分組的區(qū)別特征都是一致的，如下表所示IKE協(xié)議類型Initiator CookieResponder CookieNext Payload TypeSA協(xié)商請求有無，即8字節(jié)01SA協(xié)商響應(yīng)有有1其他分組有有非l所述的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值。所述的以報文自身的偏移量模式特征進(jìn)行檢測，具體為ISAKMP數(shù)據(jù)包UDP 頭部中包含一個2字節(jié)的長度字段(設(shè)其值為A)，標(biāo)明了該UDP頭部以及后續(xù) 數(shù)據(jù)的長度。而在ISAKMP協(xié)議中也用一個4字節(jié)的長度字段(設(shè)其值為B)，標(biāo) 明了 ISAKMP數(shù)據(jù)的長度。在標(biāo)準(zhǔn)情況下，UDP的頭部后緊跟的就是ISAKMP數(shù)據(jù)。 故A-B就等于UDP頭部的長度。在某種非標(biāo)準(zhǔn)情況下，比如VPN廠商在UDP頭部 和ISAKMP數(shù)據(jù)中填充了長度不定的數(shù)據(jù)。因此A-B就應(yīng)等于UDP頭部的長度加 上插入數(shù)據(jù)的長度。由于ISAKMP長度字段的位置在整個ISAKMP數(shù)據(jù)中是確定的， 而ISAKMP數(shù)據(jù)的位置則是根據(jù)填充字符串長度而相應(yīng)向后移動。故可以先假設(shè) 填充字符串長度，然后到相應(yīng)的ISAKMP長度字段位置去讀取驗(yàn)證的方法來檢測 填充字符串的長度。而對于端口號為4500的數(shù)據(jù)包，其在UDP頭部和ISAKMP 數(shù)據(jù)之間添加了4字節(jié)的non-ESP標(biāo)記，故在標(biāo)準(zhǔn)情況下，A-B應(yīng)等于UDP頭部 長度與non-ESP標(biāo)記的長度。其非標(biāo)準(zhǔn)情況下的檢測原理與步驟與前面一致。本發(fā)明可以在多種網(wǎng)絡(luò)設(shè)備中得到應(yīng)用，如防火墻、IDS等各種網(wǎng)絡(luò)安全設(shè) 備，協(xié)議分析代理設(shè)備。在這樣的網(wǎng)絡(luò)安全設(shè)備中，應(yīng)用本發(fā)明，可以檢測標(biāo)準(zhǔn)和非標(biāo)準(zhǔn)的IPSec連接，并了解這些連接中使用的加密算法、哈希算法等信息。
通過應(yīng)用本發(fā)明，本來不能解析的非標(biāo)準(zhǔn)的IPSec VPN連接信息可以得到解析。
可以為網(wǎng)管提供更加準(zhǔn)確的VPN使用情況，以便對VPN進(jìn)行監(jiān)督。也可以防止偽
造的VPN報文進(jìn)行攻擊，提供更高的安全性。本方法既能檢測標(biāo)準(zhǔn)的ISAKMP數(shù)
據(jù)包，對于添加了未知長度填充數(shù)據(jù)的非標(biāo)準(zhǔn)IPSec的ISAKMP數(shù)據(jù)包也能正確
解析，實(shí)現(xiàn)了一種通用的IPSec信息的檢測方法。相同的思想可以推廣到其他的
協(xié)議檢測上，實(shí)現(xiàn)對未知攻擊類型的檢測。


圖1本發(fā)明實(shí)施例應(yīng)用架構(gòu)圖 圖2本發(fā)明實(shí)施例IKE協(xié)議格式； 圖3本發(fā)明實(shí)施例的流程圖。
具體實(shí)施例方式
下面結(jié)合附圖對本發(fā)明的實(shí)施例作詳細(xì)說明本實(shí)施例在以本發(fā)明技術(shù)方案 為前提下進(jìn)行實(shí)施，給出了詳細(xì)的實(shí)施方式和具體的操作過程，但本發(fā)明的保護(hù) 范圍不限于下述的實(shí)施例。
如圖1所示，IPSecVPN監(jiān)察系統(tǒng)分為中心端和代理端兩部分，結(jié)合IPSec VPN 監(jiān)察系統(tǒng)具體說明本實(shí)施例
代理端分布配置在各單位邊界網(wǎng)絡(luò)中的交換機(jī)鏡像端口 ，代理端有兩個網(wǎng)絡(luò) 接口， 一個用來抓包， 一個用來和中心端通信。IPSec VPN流量會流經(jīng)邊界網(wǎng)絡(luò) 的交換機(jī)，并被監(jiān)察系統(tǒng)代理端所抓取到，其中包括IPSec VPN的ISAKMP協(xié)議 報文，其報文格式如圖2所示。監(jiān)察代理按照基于報文偏移量匹配的IPSec VPN 深度檢測方法進(jìn)行分析，提取其中的關(guān)鍵信息，并把分析出的數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送 到中心端，而中心端主要負(fù)責(zé)將各個代理點(diǎn)匯報的數(shù)據(jù)進(jìn)行匯總、分析和數(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)一的編程接口。
代理端分為兩個模塊，主模塊負(fù)責(zé)向中心端通報IPSec信息，接受來自中心 端的配置更新等命令。子模塊則負(fù)責(zé)在特定端口抓包，并進(jìn)行分析和提取。子模200810039182.8說明書第8/9頁塊的具體過程如下如圖3所示，本實(shí)施例包括如下步驟步驟一，抓取UDP 500端口和UDP 4500端口的數(shù)據(jù)包，這是ISAKMP協(xié)議所 使用的端口；步驟二，找到并保存數(shù)據(jù)包中UDP頭部的長度信息。在UDP之后就是ISAKMP 數(shù)據(jù)。步驟三，設(shè)置一個名為偏移量的變量，初始值為0。根據(jù)當(dāng)前偏移量，匹配 ISAKMP協(xié)議中長度信息；因?yàn)樵摲椒ㄊ峭ㄟ^報文偏移量循環(huán)匹配的方式來檢測 的，若成功，說明當(dāng)前的偏移量已經(jīng)找到，跳轉(zhuǎn)執(zhí)行步驟五，否則執(zhí)行步驟四； 步驟四當(dāng)前偏移量加一，跳轉(zhuǎn)執(zhí)行步驟三； 步驟五提取IPSec中加密算法、哈希算法和認(rèn)證方法等信息。以一個端口號為500的ISAKMP數(shù)據(jù)包為例，其UDP頭部中包含一個2字節(jié) 的長度字段(設(shè)為A)，標(biāo)明了該UDP頭部以及后續(xù)數(shù)據(jù)的長度。而在ISAKMP協(xié) 議中也用一個4字節(jié)的長度字段(設(shè)為B)，標(biāo)明了 ISAKMP數(shù)據(jù)的長度。在標(biāo)準(zhǔn) 情況下，UDP的頭部后緊跟的就是ISAKMP數(shù)據(jù)。故A-B就等于UDP頭部的長度。 在某種非標(biāo)準(zhǔn)情況下，比如VPN廠商在UDP頭部和ISAKMP數(shù)據(jù)中填充了長度不 定的數(shù)據(jù)。因此A-B就應(yīng)等于UDP頭部的長度加上插入數(shù)據(jù)的長度。由于ISAKMP 長度字段的位置在整個ISAKMP數(shù)據(jù)中是確定的，而ISAKMP數(shù)據(jù)的位置則是根據(jù) 填充字符串長度而相應(yīng)向后移動。故可以先假設(shè)填充字符串長度，然后到相應(yīng)的 ISAKMP長度字段位置去讀取驗(yàn)證的方法來檢測填充字符串的長度。而對于端口 號為4500的數(shù)據(jù)包，其在UDP頭部和ISAKMP數(shù)據(jù)之間添加了 4字節(jié)的non-ESP 標(biāo)記，故在標(biāo)準(zhǔn)情況下，A-B應(yīng)等于UDP頭部長度與non-ESP標(biāo)記的長度。其非 標(biāo)準(zhǔn)情況下的檢測原理與步驟與前面一致。該IPSec VPN監(jiān)察系統(tǒng)能夠?qū)?biāo)準(zhǔn)的IPSec VPN協(xié)議進(jìn)行深度檢測，也能夠 對非標(biāo)準(zhǔn)的IPSec VPN協(xié)議進(jìn)行深度檢測，甚至能檢測出一些偽造的IPSec VPN 協(xié)議。該監(jiān)察系統(tǒng)使用的基于報文偏移量匹配的IPSec VPN協(xié)議深度檢測方法簡 單，易于實(shí)現(xiàn)，并且檢測速度很塊?？梢詮V泛應(yīng)用到防火墻，入侵檢測系統(tǒng)，以 及各種智能代理或探針中。該系統(tǒng)使用了一款基于酷睿2平臺的雙千兆口工控主 機(jī)，能夠?qū)崿F(xiàn)千兆線速的IPSec VPN抓包速度。該系統(tǒng)的準(zhǔn)確性用誤報率和漏檢率兩個指標(biāo)來衡量。 誤報率分析-
該深度檢測方法能識別出非標(biāo)準(zhǔn)協(xié)議和標(biāo)準(zhǔn)協(xié)議之間的區(qū)別，被識別為非標(biāo) 準(zhǔn)協(xié)議格式的誤報率幾乎為0，但是有可能把某些非標(biāo)準(zhǔn)協(xié)議認(rèn)為是偽造的 IPSecVPN報文，如果非標(biāo)準(zhǔn)協(xié)議與標(biāo)準(zhǔn)協(xié)議差異太大的話，具體的說，是加入 了不止一段的自定義字段。這種情況通常比較少見。
漏檢率分析
如果非標(biāo)準(zhǔn)協(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ù)進(jìn)行循環(huán)監(jiān)聽，設(shè)置BPF抓包過濾器來抓取所有UDP 500端口和4500端口的報文，也即IPSec VPN報文，通過設(shè)置回調(diào)函數(shù)callback為基于報文偏移量匹配的深度檢測函數(shù)，每次抓到報文就會自動調(diào)用基于報文偏移量匹配的深度檢測函數(shù)進(jìn)行處理；回調(diào)函數(shù)callback是由系統(tǒng)接收到消息自動調(diào)用的函數(shù)，把基于報文偏移量匹配的深度檢測的函數(shù)地址作為參數(shù)設(shè)置為回調(diào)函數(shù)，因此，當(dāng)Libpcap抓到符合過濾規(guī)則的報文，就會自動去調(diào)用基于報文偏移量匹配的深度檢測函數(shù)；所述的基于報文偏移量模式匹配深度檢測，具體為利用報文自身的偏移量模式特征，不依賴于上下文信息，在因?yàn)閳笪母袷椒菢?biāo)準(zhǔn)從而序列中所有報文都無法解析的情況下，根據(jù)協(xié)商響應(yīng)分組和協(xié)商請求分組的偏移量特征，找到哪個是非標(biāo)準(zhǔn)的協(xié)商響應(yīng)分組，并在非標(biāo)準(zhǔn)的協(xié)商響應(yīng)分組中的SA payload字段中提取其中算法信息，如果要檢測IPSec VPN所使用的算法參數(shù)，在報文都是標(biāo)準(zhǔn)的情況下，只需要抓取協(xié)商響應(yīng)分組；步驟二在基于報文偏移量匹配的深度檢測函數(shù)中，首先按照標(biāo)準(zhǔn)的IPSecVPN報文格式去解析，定位SA協(xié)商響應(yīng)報文，并在該報文中提取VPN關(guān)鍵信息，如果能正確解析，那么該IPSec VPN報文格式是標(biāo)準(zhǔn)的，如果不能解析，那么說明IPSec VPN報文是非標(biāo)準(zhǔn)的或者是偽造的，此時各個字段內(nèi)容都被打亂，按標(biāo)準(zhǔn)協(xié)議格式無法得知確切的報文類型，這時根據(jù)報文內(nèi)部的結(jié)構(gòu)特征去變換和匹配檢測出IPSec VPN非標(biāo)準(zhǔn)報文和標(biāo)準(zhǔn)報文之間的區(qū)別，然后找出協(xié)商響應(yīng)報文，再對非標(biāo)準(zhǔn)的報文進(jìn)行關(guān)鍵字段的提取，如果根據(jù)報文偏移量特征匹配的方式還檢測不出來，認(rèn)為是偽造的IPSec VPN報文，這時觸發(fā)相關(guān)安全事件進(jìn)行處理；步驟三根據(jù)上個步驟根據(jù)上下文信息也即基于報文偏移量匹配的深度檢測方法檢測出來的協(xié)商響應(yīng)報文，尋找協(xié)商響應(yīng)報文中的NextPayLoadType，解析出標(biāo)準(zhǔn)或非標(biāo)準(zhǔn)的IPSec VPN報文中所采用算法，檢測其中是否有不符合中國密碼管理委員會政策規(guī)定的算法，或者是VPN生產(chǎn)廠家不按標(biāo)準(zhǔn)協(xié)議格式設(shè)計的非標(biāo)準(zhǔn)的IPSec VPN協(xié)議，或者是偽造的IPSec VPN報文，并按照設(shè)置安全規(guī)則進(jìn)行報警或記錄日志的處理。
2、 根據(jù)權(quán)利要求1所述的基于報文偏移量匹配的IPSec VPN協(xié)議深度檢測 方法，其特征是，所述的進(jìn)行循環(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是一個與實(shí)現(xiàn)無關(guān)的訪問操作系統(tǒng)所提供的分組捕獲機(jī)制的分組捕獲 函數(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對抓包過濾條件進(jìn)行編譯， 變成匯編代碼，然后調(diào)用pcap_setfilter實(shí)施該規(guī)則；4) 處理特定分組調(diào)用libpcap庫函數(shù)pc印—lo叩，將接收分組數(shù)設(shè)為-1，表示無限循環(huán)；5) 設(shè)定回調(diào)函數(shù)(callback)設(shè)定基于報文偏移量匹配的IPSec VPN深度檢測的方法為回調(diào)函數(shù)，指定了 回調(diào)函數(shù)之后，當(dāng)網(wǎng)卡上出現(xiàn)了符合過濾條件的報文，就會自動觸發(fā)中斷，由回 調(diào)函數(shù)對這個中斷進(jìn)行響應(yīng)，每次抓到一個符合過濾條件的數(shù)據(jù)包就循環(huán)調(diào)用回 調(diào)函數(shù)這里也既基于報文偏移量匹配的IPSec VPN深度檢測方法進(jìn)行分析和提 ??；6) 關(guān)閉監(jiān)聽調(diào)用libpcap庫函數(shù)pcap—close，結(jié)束監(jiān)聽。
3、 根據(jù)權(quán)利要求1所述的基于報文偏移量匹配的IPSec VPN協(xié)議深度檢測 方法，其特征是，所述的以報文自身的偏移量模式特征進(jìn)行檢測，具體為ISAKMP 數(shù)據(jù)包UDP頭部中包含一個2字節(jié)的長度字段，設(shè)其值為A，標(biāo)明了該UDP頭部 以及后續(xù)數(shù)據(jù)的長度，而在ISAKMP協(xié)議中也用一個4字節(jié)的長度字段，設(shè)其值 為B，標(biāo)明了 ISAKMP數(shù)據(jù)的長度；在標(biāo)準(zhǔn)情況下，UDP的頭部后緊跟的就是ISAKMP數(shù)據(jù)，故A-B就等于UDP 頭部的長度；在VPN廠商在UDP頭部和ISAKMP數(shù)據(jù)中填充了長度不定的數(shù)據(jù)，A-B就應(yīng) 等于UDP頭部的長度加上插入數(shù)據(jù)的長度，由于ISAKMP長度字段的位置在整個 ISAKMP數(shù)據(jù)中是確定的，而ISAKMP數(shù)據(jù)的位置則是根據(jù)填充字符串長度而相應(yīng) 向后移動，故先假設(shè)填充字符串長度，然后到相應(yīng)的ISAKMP長度字段位置去讀 取驗(yàn)證的方法來檢測填充字符串的長度；而對于端口號為4500的數(shù)據(jù)包，其在UDP頭部和ISAKMP數(shù)據(jù)之間添加了 4 字節(jié)的non-ESP標(biāo)記，故在標(biāo)準(zhǔn)情況下，A-B應(yīng)等于UDP頭部長度與non-ESP標(biāo) 記的長度，其非標(biāo)準(zhǔn)情況下的檢測與前面相同。
4、 根據(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值。
5、 根據(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ā)起方 進(jìn)行反饋，即利用IKE協(xié)議發(fā)送唯一認(rèn)可的一個傳輸方案，稱為協(xié)商響應(yīng)分組。
全文摘要
一種基于報文偏移量匹配的IPSec VPN協(xié)議深度檢測方法，用于網(wǎng)絡(luò)安全領(lǐng)域。本發(fā)明首先在智能代理或探針機(jī)器上打開網(wǎng)卡的混雜模式進(jìn)行循環(huán)監(jiān)聽，并且設(shè)置BPF過濾器抓取IPSec VPN報文。對IPSec VPN報文進(jìn)行深度檢測。該算法能夠識別和分析IPSec VPN報文是否為偽造，是否是非標(biāo)準(zhǔn)格式報文，本方法既能檢測標(biāo)準(zhǔn)的ISAKMP數(shù)據(jù)包，對于添加了未知長度填充數(shù)據(jù)的非標(biāo)準(zhǔn)IPSec的ISAKMP數(shù)據(jù)包也能正確解析，實(shí)現(xiàn)了一種通用的IPSec信息的檢測方法。相同的思想可以推廣到其他的協(xié)議檢測上。
文檔編號H04L12/56GK101296227SQ20081003918
公開日2008年10月29日 申請日期2008年6月19日 優(yōu)先權(quán)日2008年6月19日
發(fā)明者周志洪, 張?jiān)聡? 蔣興浩, 偉 蔡, 鵬 黃 申請人:上海交通大學(xué)