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

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

產(chǎn)品對比中應(yīng)考慮的因素遠(yuǎn)不止上述這些。或許可以經(jīng)由某種方法，或者至少構(gòu)建一個框架，將定性的想法轉(zhuǎn)化為定量的比較體系。

首先，要搞懂控制平面和數(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)絡(luò)流來更新固件版本，了解這一點是十分重要的。

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

實現(xiàn)DPI防火墻的方法很多，包括完整協(xié)議實現(xiàn)、基于特征碼的方法、基于代理的方法、或者機器學(xué)習(xí)。各有優(yōu)劣。

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

另外，該方法實際上就是建立了一張黑名單，而不是白名單。黑名單方法很糟糕?？梢詫⒅胂蟪蓸?gòu)筑了一道1.8米高的墻，然后攻擊者架個2米的梯子就翻進(jìn)來了。然后你把墻加高到2.3米，但是攻擊者又造了個2.5米的梯子，再次翻墻進(jìn)來。畫面太美，不忍直視。這種被動防御的方法顯然是不符合時代發(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)糟糕。

這些都?xì)w結(jié)為一個問題：特定協(xié)議的包結(jié)構(gòu)符合協(xié)議規(guī)范嗎？如果不符合，丟棄該數(shù)據(jù)包。

于是，結(jié)構(gòu)良好的DPI實現(xiàn)應(yīng)該包含哪些元素，是該好好列一列了。

1. 完整性檢查

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

2. 行為過濾

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

3. 狀態(tài)檢查

調(diào)查響應(yīng)是否有對應(yīng)的請求。如果響應(yīng)不是跟在初始請求之后回來的，那就是偽造的響應(yīng)數(shù)據(jù)包，應(yīng)丟棄。

4. 響應(yīng)驗證

仔細(xì)看DNP3，你會發(fā)現(xiàn)，大多數(shù)已公布漏洞實際上攻擊的是HMI，而不是PLC或RTU(遠(yuǎn)程終端單元)。這指示了響應(yīng)消息應(yīng)驗證的深度。

5. 廠商特定支持

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

6. 管道支持

TCP/UDP消息包含多種ICS協(xié)議消息的地方?？梢韵胂笠幌乱粠瑪?shù)據(jù)里放進(jìn)4條Modbus消息。DPI實現(xiàn)必須能處理這個，要能遍歷每條消息，確保沒有嵌入任何寫指令或固件更新。

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

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

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

Modbus FC15結(jié)構(gòu)

而”6″分，就意味著DPI引擎驗證每一個域，確保數(shù)據(jù)包完全符合協(xié)議規(guī)范。

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

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

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

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

這里沒提到吞吐量和延時，因為這不是關(guān)于產(chǎn)品速度而是關(guān)于功能的。然而，像GOOSE這種要求低延時的協(xié)議，這些至少應(yīng)該考慮到?；旧?，要記住，不是所有DPI實現(xiàn)都是一樣的。