深度包檢測(DPI)技術及其相關產品的評估，乍看之下似乎不難，然而，出于某些原因，還真就難以得出準確結論。

難點有多個方面。大多數公司不肯交出描述其DPI實現的代碼庫。于是，想要真正對比，就得進行黑箱測試，包括對每個設備來一場模糊測試。同時，不同協議有不同的復雜度和特性，各廠商可能有自己特定的函數或實現，未必會嚴格遵守協議規范，這些都是在部署DPI實現的時候應該納入考慮的內容。

產品對比中應考慮的因素遠不止上述這些。或許可以經由某種方法，或者至少構建一個框架，將定性的想法轉化為定量的比較體系。

首先，要搞懂控制平面和數據平面的概念。數據平面包括人機接口(HMI)讀寫指令，可從可編程邏輯控制器(PLC)讀取壓力或溫度數據，或者在時鐘間隔里向特定寄存器寫入數據。這就是PLC上跑的實際過程數據或梯形邏輯。同時，控制平面是能夠更新固件或完全停止控制器的全部操作。其指令包括了運行PLC的底層操作系統。這有點類似在 Windows PC 上執行Windows更新。由于很多PLC都利用與數據讀取相同的網絡流來更新固件版本，了解這一點是十分重要的。

基本上，控制平面和數據平面流量穿過的是同一個TCP連接，這也是為什么我們需要DPI的原因所在。因為用戶肯定想要從HMI收取數據，但又不想冒著自家PLC遭非授權攻擊者固件更新的風險。缺了DPI防火墻，你便無法區分數據平面和控制平面消息。

實現DPI防火墻的方法很多，包括完整協議實現、基于特征碼的方法、基于代理的方法、或者機器學習。各有優劣。

工業控制系統(ICS)領域里，基于特征碼的方法是很糟糕的機制。基于特征碼的方法僅僅是反應式機制。特征碼基于已發現的漏洞，意味著攻擊方法早已出現，且有可能影響正在運行的系統。特征碼只能提供淺薄的檢查，還要求特征碼數據庫不斷更新。(車間里有互聯網接入？想都別想。)一個特征碼通常專屬一個特定漏洞。攻擊方法只要修改了一個字節，就得新弄個特征碼出來緩解。

另外，該方法實際上就是建立了一張黑名單，而不是白名單。黑名單方法很糟糕。可以將之想象成構筑了一道1.8米高的墻，然后攻擊者架個2米的梯子就翻進來了。然后你把墻加高到2.3米，但是攻擊者又造了個2.5米的梯子，再次翻墻進來。畫面太美，不忍直視。這種被動防御的方法顯然是不符合時代發展需要的。主動方法更為有效。

實現的深度比廣度更重要。防火墻廠商可能宣稱支持500種協議，但支持到何種程度呢？驗證某個協議里的每一個字節并不意味著就支持該協議的DPI。

產品對比的評分方案是個不錯的選擇。我們怎么對比產品？DPI實現中最重要的因素是什么？80-90%的 ICS-CERT 漏洞都落入同一分類：惡意軟件/數據包模糊/緩沖區溢出/實現糟糕。

這些都歸結為一個問題：特定協議的包結構符合協議規范嗎？如果不符合，丟棄該數據包。

于是，結構良好的DPI實現應該包含哪些元素，是該好好列一列了。

1. 完整性檢查

DPI引擎理解協議完整性和數據包結構排列的能力。如果是 Ethernet/IP CIP 消息帶了個長度域，描述對“模擬輸入對象”和“獲取所有屬性”的操作，這意味著什么？允許的長度？還是說每個域的字節數？DPI實現必須知道內部和外部的協議，尤其是旨在捕獲那80-90%的 ICS-CERT 漏洞的時候。

2. 行為過濾

允許/拒絕特定功能代碼的能力，EtherNet/IP上的CIP服務，分布式網絡協議3(DNP3)中的DNP3對象等等。這是區分控制平面和數據平面操作的能力，讓用戶可以持續監測溫度或壓力儀表，同時確保固件更新操作不能進行。

3. 狀態檢查

調查響應是否有對應的請求。如果響應不是跟在初始請求之后回來的，那就是偽造的響應數據包，應丟棄。

4. 響應驗證

仔細看DNP3，你會發現，大多數已公布漏洞實際上攻擊的是HMI，而不是PLC或RTU(遠程終端單元)。這指示了響應消息應驗證的深度。

5. 廠商特定支持

另一種說法是廠商特定驗證。比如施奈爾的 Modbus FC 90 或者羅克韋爾的PCCC/CSPv4。如果DPI引擎理解你所用的廠商特定元素，那這就是一個重要的指標。

6. 管道支持

TCP/UDP消息包含多種ICS協議消息的地方。可以想象一下一幀數據里放進4條Modbus消息。DPI實現必須能處理這個，要能遍歷每條消息，確保沒有嵌入任何寫指令或固件更新。

上述六條的類型評分方案如下圖：

完整性檢查得分為4的依據是什么？有什么意義？這就是更難以解釋的部分了。如今，我們對要評估的方面有了共識，也有了分級評分機制。

基于該協議，”4″分意味著不是每一個域都被驗證了。比如說，Modbus FC15 (寫多個線圈)不驗證輸出的數量；或許就不驗證所有回復的數量。

Modbus FC15結構

而”6″分，就意味著DPI引擎驗證每一個域，確保數據包完全符合協議規范。

若缺乏產品細節，深度是個很難衡量的東西。公司愿意列出他們驗證協議的深度嗎？評分方案里的數字是很主觀的，每個DPI特性都可以再細分，得出更精準的視圖。

毫無疑問，DPI方法和基于特征碼的系統也可以與完全協議遵從或代理設置進行比較。另外，每個協議的DPI引擎深度可能各不相同，所以，按協議比較而不是各產品間進行比較，也是有意義的。通過檢查多個產品，產品間的關系也會改變，比如“產品X做這個比產品Y好“——這一點才是更有價值的。

最后，需要考慮的其他因素也還有。什么都支持，但用戶界面晦澀難懂的DPI引擎，對客戶而言也不是那么有用。

DPI引擎識別出無效幀時，有哪些操作是重要的呢？

這里沒提到吞吐量和延時，因為這不是關于產品速度而是關于功能的。然而，像GOOSE這種要求低延時的協議，這些至少應該考慮到。基本上，要記住，不是所有DPI實現都是一樣的。