建站
咨詢
售后
建站咨詢
新聞中心
深度包檢測(DPI)技術及其相關產(chǎn)品的評估，乍看之下似乎不難，然而，出于某些原因，還真就難以得出準確結論。
難點有多個方面。大多數(shù)公司不肯交出描述其DPI實現(xiàn)的代碼庫。于是，想要真正對比，就得進行黑箱測試，包括對每個設備來一場模糊測試。同時，不同協(xié)議有不同的復雜度和特性，各廠商可能有自己特定的函數(shù)或實現(xiàn)，未必會嚴格遵守協(xié)議規(guī)范，這些都是在部署DPI實現(xiàn)的時候應該納入考慮的內容。
產(chǎn)品對比中應考慮的因素遠不止上述這些?；蛟S可以經(jīng)由某種方法，或者至少構建一個框架，將定性的想法轉化為定量的比較體系。
首先，要搞懂控制平面和數(shù)據(jù)平面的概念。數(shù)據(jù)平面包括人機接口(HMI)讀寫指令，可從可編程邏輯控制器(PLC)讀取壓力或溫度數(shù)據(jù)，或者在時鐘間隔里向特定寄存器寫入數(shù)據(jù)。這就是PLC上跑的實際過程數(shù)據(jù)或梯形邏輯。同時，控制平面是能夠更新固件或完全停止控制器的全部操作。其指令包括了運行PLC的底層操作系統(tǒng)。這有點類似在 Windows PC 上執(zhí)行Windows更新。由于很多PLC都利用與數(shù)據(jù)讀取相同的網(wǎng)絡流來更新固件版本，了解這一點是十分重要的。
基本上，控制平面和數(shù)據(jù)平面流量穿過的是同一個TCP連接，這也是為什么我們需要DPI的原因所在。因為用戶肯定想要從HMI收取數(shù)據(jù)，但又不想冒著自家PLC遭非授權攻擊者固件更新的風險。缺了DPI防火墻，你便無法區(qū)分數(shù)據(jù)平面和控制平面消息。
實現(xiàn)DPI防火墻的方法很多，包括完整協(xié)議實現(xiàn)、基于特征碼的方法、基于代理的方法、或者機器學習。各有優(yōu)劣。
工業(yè)控制系統(tǒng)(ICS)領域里，基于特征碼的方法是很糟糕的機制?；谔卣鞔a的方法僅僅是反應式機制。特征碼基于已發(fā)現(xiàn)的漏洞，意味著攻擊方法早已出現(xiàn)，且有可能影響正在運行的系統(tǒng)。特征碼只能提供淺薄的檢查，還要求特征碼數(shù)據(jù)庫不斷更新。(車間里有互聯(lián)網(wǎng)接入?想都別想。)一個特征碼通常專屬一個特定漏洞。攻擊方法只要修改了一個字節(jié)，就得新弄個特征碼出來緩解。
另外，該方法實際上就是建立了一張黑名單，而不是白名單。黑名單方法很糟糕?？梢詫⒅胂蟪蓸嬛艘坏?.8米高的墻，然后攻擊者架個2米的梯子就翻進來了。然后你把墻加高到2.3米，但是攻擊者又造了個2.5米的梯子，再次翻墻進來。畫面太美，不忍直視。這種被動防御的方法顯然是不符合時代發(fā)展需要的。主動方法更為有效。
實現(xiàn)的深度比廣度更重要。防火墻廠商可能宣稱支持500種協(xié)議，但支持到何種程度呢?驗證某個協(xié)議里的每一個字節(jié)并不意味著就支持該協(xié)議的DPI。
產(chǎn)品對比的評分方案是個不錯的選擇。我們怎么對比產(chǎn)品?DPI實現(xiàn)中最重要的因素是什么?80-90%的 ICS-CERT 漏洞都落入同一分類：惡意軟件/數(shù)據(jù)包模糊/緩沖區(qū)溢出/實現(xiàn)糟糕。
這些都歸結為一個問題：特定協(xié)議的包結構符合協(xié)議規(guī)范嗎?如果不符合，丟棄該數(shù)據(jù)包。
于是，結構良好的DPI實現(xiàn)應該包含哪些元素，是該好好列一列了。
1. 完整性檢查
DPI引擎理解協(xié)議完整性和數(shù)據(jù)包結構排列的能力。如果是 Ethernet/IP CIP 消息帶了個長度域，描述對“模擬輸入對象”和“獲取所有屬性”的操作，這意味著什么?允許的長度?還是說每個域的字節(jié)數(shù)?DPI實現(xiàn)必須知道內部和外部的協(xié)議，尤其是旨在捕獲那80-90%的 ICS-CERT 漏洞的時候。
2. 行為過濾
允許/拒絕特定功能代碼的能力，EtherNet/IP上的CIP服務，分布式網(wǎng)絡協(xié)議3(DNP3)中的DNP3對象等等。這是區(qū)分控制平面和數(shù)據(jù)平面操作的能力，讓用戶可以持續(xù)監(jiān)測溫度或壓力儀表，同時確保固件更新操作不能進行。
3. 狀態(tài)檢查
調查響應是否有對應的請求。如果響應不是跟在初始請求之后回來的，那就是偽造的響應數(shù)據(jù)包，應丟棄。
4. 響應驗證
仔細看DNP3，你會發(fā)現(xiàn)，大多數(shù)已公布漏洞實際上攻擊的是HMI，而不是PLC或RTU(遠程終端單元)。這指示了響應消息應驗證的深度。
5. 廠商特定支持
另一種說法是廠商特定驗證。比如施奈爾的 Modbus FC 90 或者羅克韋爾的PCCC/CSPv4。如果DPI引擎理解你所用的廠商特定元素，那這就是一個重要的指標。
6. 管道支持
TCP/UDP消息包含多種ICS協(xié)議消息的地方。可以想象一下一幀數(shù)據(jù)里放進4條Modbus消息。DPI實現(xiàn)必須能處理這個，要能遍歷每條消息，確保沒有嵌入任何寫指令或固件更新。
上述六條的類型評分方案如下圖：
完整性檢查得分為4的依據(jù)是什么?有什么意義?這就是更難以解釋的部分了。如今，我們對要評估的方面有了共識，也有了分級評分機制。
基于該協(xié)議，"4"分意味著不是每一個域都被驗證了。比如說，Modbus FC15 (寫多個線圈)不驗證輸出的數(shù)量;或許就不驗證所有回復的數(shù)量。
Modbus FC15結構
而"6"分，就意味著DPI引擎驗證每一個域，確保數(shù)據(jù)包完全符合協(xié)議規(guī)范。
若缺乏產(chǎn)品細節(jié)，深度是個很難衡量的東西。公司愿意列出他們驗證協(xié)議的深度嗎?評分方案里的數(shù)字是很主觀的，每個DPI特性都可以再細分，得出更精準的視圖。
毫無疑問，DPI方法和基于特征碼的系統(tǒng)也可以與完全協(xié)議遵從或代理設置進行比較。另外，每個協(xié)議的DPI引擎深度可能各不相同，所以，按協(xié)議比較而不是各產(chǎn)品間進行比較，也是有意義的。通過檢查多個產(chǎn)品，產(chǎn)品間的關系也會改變，比如“產(chǎn)品X做這個比產(chǎn)品Y好“——這一點才是更有價值的。
最后，需要考慮的其他因素也還有。什么都支持，但用戶界面晦澀難懂的DPI引擎，對客戶而言也不是那么有用。
DPI引擎識別出無效幀時，有哪些操作是重要的呢?
- 丟棄該幀?
- 發(fā)送TCP重置?
- 產(chǎn)生事件消息?
這里沒提到吞吐量和延時，因為這不是關于產(chǎn)品速度而是關于功能的。然而，像GOOSE這種要求低延時的協(xié)議，這些至少應該考慮到?；旧?，要記住，不是所有DPI實現(xiàn)都是一樣的。
【本文是專欄作者“”李少鵬“”的原創(chuàng)文章，轉載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權】
戳這里，看該作者更多好文
網(wǎng)頁題目：你的深度包檢測有多深：DPI技術評估提案
鏈接地址：http://www.5511xx.com/article/dpciipc.html
