DPI深度報文檢測架構及關鍵技術實現

DPI深度報文檢測架構及關鍵技術實現

 

DPI深度報文檢測架構及關鍵技術實現

當前DPI(Deep Packet Inspect深度報文識別)技術是安全領域的關鍵技術點之一,圍繞DPI技術衍生出的安全產品類型也很是的多樣。在分析DPI的進一步技術實現以前,分析DPI對用戶的價值能夠看到主要體如今兩個方面:html

  • 從攻擊防護的角度看,Web類的安全風險正在成爲目前安全風險的主流攻擊形式,針對Web類應用層安全攻擊的防禦,依靠傳統的防火牆是沒法實現的,具有深度報文檢測能力的IPS設備或者WAF設備開始爲你們所熟知;算法

  • 從業務應用識別分析的角度看,單純的分析報文的頭字段內容沒法識別該報文所承載的具體的業務類型,要想深度瞭解報文所承載的業務應用類型及流量大小等信息,必需要跟蹤業務應用的協議交互過程,並對報文的負載payload進行深度的識別。若是用戶但願網絡安全設備具有針對應用層的風險防禦能力且可以對互聯網出口的流量應用進行精細化的管理控制,DPI技術的能很好的知足客戶的需求。安全

和傳統的防火牆域間策略的匹配查詢不一樣,DPI技術旨在藉助字符串特徵的逐包匹配來完成入侵檢測和流量控制的目的,在這個過程當中,深度報文檢測的引擎設計和豐富的規則特徵庫定義是核心設計環節。從檢測引擎設計的角度看,除了要有良好的設計框架以外,在收到須要檢測的報文後,涉及到報文的正規化處理、檢測引擎的協議解析、引擎對報文關鍵特徵提取和高效算法查詢等內容;從特徵庫的角度,涉及到對檢測規則的定義、特徵庫的提取和升級更新等內容,接下來咱們將針對其中的關鍵技術點進行說明。服務器

一、DPI技術實現的基本框架(Deep Inspect Management)
從控制管理層面上看,DPI的各個業務模塊的需求均可以抽象化成「規則」,基於這些規則定義能夠生成不一樣的「分類」對象;規則同時具備「使能狀態、報文動做」等屬性,內部還設置有特徵、選項等關鍵字部件。DIM的框架設計將業務模塊的公共業務需求進行抽象並處理。控制管理層面的工做在用戶態完成,主要工做包括:網絡

  • 統一開放格式的規則管理;架構

  • 統一開放格式的特徵庫加載和文件解析;併發

  • 配置變動和下發流程管理,包括引擎的編譯和下發、規則的下發,以及它們的板間同步(如圖1所示)。框架

從數據轉發層面上看,DPI的各個業務需求都須要對應用層協議進行解析、解碼和搜索。爲了保證高效轉發和單次報文處理,有別於傳統防火牆的設計思路,在新一代安全產品的實現過程當中必須有並行的檢測引擎,儘量保證只對報文進行一次處理。數據轉發層面的需求主要在內核態進行處理,涉及到的幾個功能模塊以下:性能

  • 協議解析器;大數據

  • 搜索算法引擎;

  • 檢測結果處理模塊,或者說報文動做處理模塊;通常是在I/O 接口的處理流程中(如圖1所示)。

圖1 DPI軟件設計架構示意圖(注:DIM, Deep Inspect Management)

這種將控制管理層和數據轉發層相互獨立的設計模型,使得CPU密集型的引擎預處理(編譯和下發)和高性能的搜索算法過程分離在用戶態和內核態,也可使得咱們的預處理和匹配在不一樣的單板甚至不一樣的設備上進行,易於保證轉發流程的檢測持續性和穩定性,匹配也易於由軟件查表擴展成硬件處理器來完成。

二、DPI控制管理層面的規則定義

三、DPI檢測引擎設計及典型算法模型
有別於傳統的DFA(Deterministic Finite Automaton)和NFA(Non-Deterministic Finite Automaton)算法,H3C 的DPI軟件引擎具備內存可伸縮特性。DIM用戶態可動態感知須要加載軟件引擎的單板或者子設備(的內核態)是否有充裕的內存,根據內存剩餘狀況和用戶的配置選擇最優的引擎存儲方式,而後啓動編譯線程完成編譯下發工做。海量特徵的編譯下發是一個CPU密集型過程,考慮到可能遇到的配置頻繁變動或者特徵庫升級調度,DIM的編譯線程設置了可中斷可重入機制,不須要用戶等待。

圖 3 DPI 檢測引擎在報文轉發中的流程示意圖

DPI內核態的檢測引擎可能出如今入接口業務點、域間策略業務點或者出接口業務點,任何涉及DPI業務的配置啓用都會開啓轉發流程中的DPI業務點,若是用戶有多種相關配置,DPI會在報文轉發流程中最先的業務點生效,其他點則不生效。在DPI的入接口處理時,數據轉發層面的處理流程如協議解析、算法引擎和檢測結果處理是其工做重點【圖3】。

在具體的DPI檢測引擎設計時,其在內核態的位置如圖4所示。能夠看出,DPI檢測引擎包含了多種檢測算法,典型的如Aho-Crassick , Boyer ,Moore算法以及PCRE算法等等,經過這些算法的配合能夠有效實現關鍵特徵的快速查找匹配,提高了查找效率。

圖 4 DPI 檢測引擎在內核態的部件示意圖

四、DPI檢測引擎的協議解析器設計模型
檢測引擎自身包括三個部件:協議解析器、算法引擎和檢測結果處理,下面主要對其關鍵部分的協議解析器進行說明。現階段額度協議解析器的職責主要有:
1)協議確認: 進入HTTP、HTTPS等協議解析器的條件都是固定端口映射。但愈來愈多的互聯網應用正試圖經過80、443等傳統端口來逃逸傳統網絡設備的檢測和控制。所以必要的協議確認是防止這種逃逸的前提。

2)協議切分: 協議切分是在流(會話)的基礎上進一步細分出「檢測流」或者叫「事物」的概念。例如:HTTP的一次transaction、FTP的一次用戶登陸行爲、SMTP/POP3的一次郵件發送/接收等,都抽象成一條「檢測流」。有時一條流能夠傳輸屢次檢測流,甚至同時有併發的檢測流出現。協議切分對於關心檢測流的業務模塊有着重要意義,例如內容過濾和應用審計。

3)協議域切分:協議域切分是在最小的粒度上細分報文。將檢測流分紅Header和Body部分,Header還要細分紅各個Field,包含Field Value和Field Data部分。協議域切分有助於判別該頭域是否須要檢測,斷定該頭域命中的特徵與之定義是否吻合,以及識別提取審計日誌信息的關鍵位置。

圖 5 HTTP請求報文的協議域切分示意圖

4)解碼: HTTP的URI部分和郵件協議的Subject部分等進行了編碼,須要協議解析器進行解碼,大多數狀況下須要咱們將解碼後的字段送入算法引擎。有些狀況又有個別特徵基於編碼前定義,須要咱們將原始字段送入算法引擎,但同時發生會對性能產生必定損耗。

5)解壓縮:HTTP能夠用gzip、x-gzip、deflate等方式傳送壓縮後的數據內容,在用戶的配置要求下解析器會將內容解壓縮後送入算法引擎,以幫助咱們發現壓縮數據中的須要被檢測出的特徵。

6)SSL卸載:在用戶的配置要求下,能夠經過SSL卸載技術儘量還原HTTPS中的原始流量,進行更加全面的檢測和控制。

7)協商協議識別:FTP、SIP以及不少加密方式的P2P協議都採用協商甚至屢次協商的方式來進行數據傳輸。對應的協議解析器須要可以經過控制通道報文的解析識別出協商協議的數據通道的五元組特徵,經過協商關聯表的匹配來識別其數據通道。

固然,基於這些協議分析完成以後,經過算法引擎能夠匹配查找能夠發現相關的檢測結果,同時送到後續的動做設計模塊進行處理。在內核態,DPI支持大量的動做以及它們的組合,各個DPI的業務模塊均可以基於規則或者規則分類來配置報文的動做。這些動做包括Permit/deny、Drop丟掉後續報文、Redirect或者發送雙向TCP Reset斷開鏈接、生成攻擊日誌告警等。
五、特徵庫的設計模型
在進行DPI特徵庫的設計時,通常都是採用統一的文件頭結構和開放式TLV架構,易於軟件統一處理和後續業務擴展。同時考慮到不一樣產品對存儲空間、轉發性能、併發規格的不一樣要求,爲不一樣的產品(不限於NGFW)量身定製了不一樣的特徵庫。而且,爲了可以快速完成升級,在服務器上放置了鄰近舊版本的增量庫(補丁包)。

圖 6 DPI設備特徵庫升級流程示意圖

結束語DPI技術的應用和發展是一個動態不斷完善的過程:一方面攻擊類型在不斷的發展變化,由此致使的攻擊特徵漏洞的提取也要與時俱進不斷更新,另外一方面隨着攻擊類型的增長,除了攻擊特徵漏洞匹配和應用層協議解析以外,未知的不能識別的攻擊類型報文也會逐漸增長,目前已經出現的雲端的未知攻擊的檢測識別技術能夠爲設備側的DPI檢測提供很好的補充,基於大數據的雲端安全分析平臺也會逐漸成爲安全的核心競爭力,配合安全設備終端造成完整的DPI防禦解決方案。

相關文章
相關標籤/搜索