1 引言
由于IEC61850標準是電力系統自動化領域唯一的全球通用標準。它通過標準的實現，實現了智能變電站的工程運作標準化，使得智能變電站的工程實施變得規范、統一和透明[1]。ICS領域本身的脆弱性，不管是基于內部進行攻擊還是由外部入侵者進來發起的攻擊，都將不可避免地造成生產損失，況且生產環節發生事故還特別容易威脅人身生命安全[2]。這些風險是看得見的本身就存在的，不可能短期內通過更換工控設備來解決，必須要通過工控防火墻來實施防護，從而扼殺掉這樣的風險[3][4]。自工業4.0的概念提出后，目前已經有許多基于IEC61850標準的系統投入運營，因此研究IEC61850標準的工控防火墻有其獨特的現實意義。
當前的安全廠商如綠盟科技、啟明星辰和安恒等都有工控的安全設備，大多實現了對IEC61850標準中的IEC104協議的檢測。而本文的基于iptables的工控防火墻不同于傳統意義的防火墻，它不僅能基于源目IP和端口等進行過濾，還實現了對IEC61850標準中的IEC9506制造商信息規范MMS和TCP握手包的深度檢測。接下來，將對MMS協議進行介紹和分析，并描述本文基于iptables的工控防火墻的實現原理。
2 IEC61850標準內容過濾的工控防火墻設計
2.1 運行環境
運行環境為Ubuntu 1 4 . 04，需要其他組件如Iptables、Mongodb和Tornado等。
2.2 系統架構圖
基于Iptables的IEC61850協議內容過濾的工控防火墻主要被部署在變電站通信體系的站控層和間隔層之間，其不僅能基于源目地址等過濾普通的TCP或UDP數據包，而且能識別IEC61850標準中的IEC 9506制造商信息規范MMS協議，利用Iptalbes防火墻的Netfilter queue擴展將MMS協議的數據包從內核層提取到用戶層，對數據包內容進行深度檢測，并將日志記錄到數據庫中并在web界面進行展示。其系統架構圖如1所示。
圖1 web頁面實現規則添加
2.3 主要模塊
2.3.1 前端
規則添加：
前端用html+css構成，登陸界面上使用加入了placeholder來增加用戶的登陸體驗。管理員登陸后，web頁面中可以查看系統狀態、防火墻規則和入侵檢測；添加規則用于前端到后端的配合，首先用switch.css設計開關按鈕，這個按鈕的實質是一個checkbox，通過checkbox是否為checked狀態來判斷該開關的開啟或關閉。如圖2所示。
圖2 web頁面實現規則添加
2.3.2 后端
使用Tornado框架實現對前端請求響應：后端的tornado框架采用的是多進程+非阻塞+epoll+prefork模型。
使用Mongodb數據庫記錄日志：Mongodb數據庫中詳細記錄了觸發告警的數據包的源目IP、端口號和協議等，如圖3所示，為使用Mongodb數據庫記錄日志并在前端的web頁面顯示。
圖3 Mongodb數據庫記錄數據日志并在前端web頁面顯示
2.3.3 Iptables架構
Iptalbes總共有四表五鏈，用于實現具體的訪問控制。Netfilter queue擴展用于將數據包從內核空間提取到用戶空間，對數據包進行深度檢測。
Iptalbes四種表功能如下：
filter表：主要用于對數據包進行過濾，根據具體的規則決定是否放行該數據包；
nat表：主要用于修改數據包的IP地址、端口號等信息；
mangle表：主要用于修改數據包的TOS、TTL值以及為數據包設置Mark標記；
raw表：是自1.2.9以后版本的Iptables新增的表，主要用于決定數據包是否被狀態跟蹤機制處理。
Iptalbes五種規則鏈功能如下：
INPUT鏈：當接收到防火墻本機地址的數據包（入站）時，應用此鏈中的規則；
OUTPUT鏈：當防火墻本機向外發送數據包（出站）時，應用此鏈中的規則；
FORWARD鏈：當接收到需要通過防火墻發送給其他地址的數據包（轉發）時，應用此鏈中的規則；
PREROUTING鏈：在對數據包作路由選擇之前，應用此鏈中的規則，如DNAT；
POSTROUTING鏈：在對數據包作路由選擇之后，應用此鏈中的規則，如SNAT。
其處理數據包的方式為：ACCEPT：允許數據包通過；DROP：直接丟棄數據包，不給任何回應信息；REJECT：拒絕數據包通過，必要時會給數據發送端一個響應的信息。數據包處理流程如圖4所示。
圖4 數據包處理流程
Netfilter queue擴展可加在圖4中的任意五鏈中，具體可由用戶定義。
2.4 MMS協議的深度分析
2.4.1 MMS協議深度分析之拆包
由具體函數完成對數據包的拆包、握手包深度檢測和mms協議的深度檢測。
利用python的dpkt庫完成對三層及以上的拆包處理。對于接收到的數據包拆包過程如下：首先利用get_payload()函數獲取三層及以上數據包的東西，然后利用hexdump()函數完成對數據包的unicode解碼，之后使用正則去除空格等特殊字符，將數據包中內容放入列表。
2.4.2 MMS協議深度分析之TCP包深度分析
此部分代碼對TCP包進行了深度解析和判斷（黑名單原則）：握手包中syn和fin標記位不能同時為1；握手包中標記位不能都為0；握手包中不存在fin標記位為1且ack標記位為0的情況。
2.4.3 MMS協議深度分析之initiate請求報文深度分析
MMS協議在S-C端通信前都會先由client端發送initiate請求給server端，之后server端回一個initiate數據包給client端。
通過分析initiate請求數據包的特征，將其應用層中的為true的功能碼記錄下來，并記錄該數據包源IP、源端口和目的端口。則后續的s-c端通信中，將所有的非initiate數據包進行深度檢測，發送的功能碼、源IP、源端口和目的端口必須為記錄中的，否則視為非法數據包。
根據大量MMS的initiate報文的深度分析和總結，發現其有以下特征：init包目的端口號為COTP層PDU Type為f0；init包ISO 8327-1層SPDU type為0d；init包ISO 8823層presentation context identifier值為01；init包ISO 8650-1層aso context name為28ca220203。并且，一個正常的MMS協議的initiate請求報文各層數據長度除了應用層均固定，如圖5所示。
圖5 MMS協議initiate請求報文
從圖5中可以看出：二層數據長度為14字節；三層數據長度為20字節；四層數據長度為32字節；TPKT層數據長度為4字節；ISO COTP層數據長度為3字節；ISO 8327-1層數據長度為24字節；ISO 8823層數據長度為69字節；ISO 8650-1層數據長度為47字節。
MMS協議中總共有90個功能碼，常用功能碼有6種，initiate請求報文中的功能碼描述如圖6所示，分為ture和false：
圖6 MMS協議非initiate請求數據包中功能碼
2.4.4 MMS協議深度分析之非initiate請求報文功能碼深度分析
通過分析initiate請求數據包的特征，將其應用層中的為true的功能碼記錄下來，在后續的s-c端通信中，將所有的非initiate數據包進行深度檢測，發送的功能碼必須為記錄中的，否則視為非法數據包。
根據大量MMS的initiate報文的深度分析和總結，發現其有以下特征：非initi a te包目的端口號為COTP層PDU Type為f0；非initiate包兩個ISO8327-1層內容必為0100；非initiate包ISO 8823層presentation context identifier值為03a。且一個正常的MMS協議的非initiate請求報文各層數據長度除了應用層均固定，如圖7所示。
圖7 MMS協議非initiate請求數據包
從圖7中可以看出：二層數據長度為14字節；三層數據長度為20字節；四層數據長度為32字節；TPKT層數據長度為4字節；ISO COTP層數據長度為3字節；ISO 8327-1層數據長度為2字節；ISO 8327-1層數據長度為2字節；ISO 8823層數據長度為9字節。
其中本次防火墻可以識別的功能碼有6種，分別為read、write、getNameList、fileDirectory、fileOpen和fileRead，它們也是最常用的六種。
3 總結與展望
從工業網絡安全整體的考慮，現在的這些生產網由于擴大的規模、連接的無線、遠程的運維、現場的管理和數據的傳輸，已經使生產線完全暴露在攻擊者面前[5]。對于企業的運營者以及安全的防護者，工業網絡安全的建設任重道遠，必須從全局上看，整體上看，著重于頂層設計，實施縱深防御的安全戰略。工控防火墻是這個體系的第一道防線，是工業網絡安全的重要組成部分[6]。因此本次對于基于IEC61850標準的MMS協議內容過濾的工控防火墻設計具有十分重要的現實意義。