1　引言

　　由于IEC61850標準是電力系統(tǒng)自動化領(lǐng)域唯一的全球通用標準。它通過標準的實現(xiàn)，實現(xiàn)了智能變電站的工程運作標準化，使得智能變電站的工程實施變得規(guī)范、統(tǒng)一和透明[1]。ICS領(lǐng)域本身的脆弱性，不管是基于內(nèi)部進行攻擊還是由外部入侵者進來發(fā)起的攻擊，都將不可避免地造成生產(chǎn)損失，況且生產(chǎn)環(huán)節(jié)發(fā)生事故還特別容易威脅人身生命安全[2]。這些風險是看得見的本身就存在的，不可能短期內(nèi)通過更換工控設(shè)備來解決，必須要通過工控防火墻來實施防護，從而扼殺掉這樣的風險[3][4]。自工業(yè)4.0的概念提出后，目前已經(jīng)有許多基于IEC61850標準的系統(tǒng)投入運營，因此研究IEC61850標準的工控防火墻有其獨特的現(xiàn)實意義。

　　當前的安全廠商如綠盟科技、啟明星辰和安恒等都有工控的安全設(shè)備，大多實現(xiàn)了對IEC61850標準中的IEC104協(xié)議的檢測。而本文的基于iptables的工控防火墻不同于傳統(tǒng)意義的防火墻，它不僅能基于源目IP和端口等進行過濾，還實現(xiàn)了對IEC61850標準中的IEC9506制造商信息規(guī)范MMS和TCP握手包的深度檢測。接下來，將對MMS協(xié)議進行介紹和分析，并描述本文基于iptables的工控防火墻的實現(xiàn)原理。

　　2　IEC61850標準內(nèi)容過濾的工控防火墻設(shè)計

　　2.1　運行環(huán)境

　　運行環(huán)境為Ubuntu 1 4 . 04，需要其他組件如Iptables、Mongodb和Tornado等。

　　2.2　系統(tǒng)架構(gòu)圖

　　基于Iptables的IEC61850協(xié)議內(nèi)容過濾的工控防火墻主要被部署在變電站通信體系的站控層和間隔層之間，其不僅能基于源目地址等過濾普通的TCP或UDP數(shù)據(jù)包，而且能識別IEC61850標準中的IEC 9506制造商信息規(guī)范MMS協(xié)議，利用Iptalbes防火墻的Netfilter queue擴展將MMS協(xié)議的數(shù)據(jù)包從內(nèi)核層提取到用戶層，對數(shù)據(jù)包內(nèi)容進行深度檢測，并將日志記錄到數(shù)據(jù)庫中并在web界面進行展示。其系統(tǒng)架構(gòu)圖如1所示。

　　圖1 web頁面實現(xiàn)規(guī)則添加

　　2.3　主要模塊

　　2.3.1　前端

　　規(guī)則添加：

　　前端用html+css構(gòu)成，登陸界面上使用加入了placeholder來增加用戶的登陸體驗。管理員登陸后，web頁面中可以查看系統(tǒng)狀態(tài)、防火墻規(guī)則和入侵檢測；添加規(guī)則用于前端到后端的配合，首先用switch.css設(shè)計開關(guān)按鈕，這個按鈕的實質(zhì)是一個checkbox，通過checkbox是否為checked狀態(tài)來判斷該開關(guān)的開啟或關(guān)閉。如圖2所示。

　　圖2 web頁面實現(xiàn)規(guī)則添加

　　2.3.2　后端

　　使用Tornado框架實現(xiàn)對前端請求響應(yīng)：后端的tornado框架采用的是多進程+非阻塞+epoll+prefork模型。

　　使用Mongodb數(shù)據(jù)庫記錄日志：Mongodb數(shù)據(jù)庫中詳細記錄了觸發(fā)告警的數(shù)據(jù)包的源目IP、端口號和協(xié)議等，如圖3所示，為使用Mongodb數(shù)據(jù)庫記錄日志并在前端的web頁面顯示。

　　圖3 Mongodb數(shù)據(jù)庫記錄數(shù)據(jù)日志并在前端web頁面顯示

　　2.3.3　Iptables架構(gòu)

　　Iptalbes總共有四表五鏈，用于實現(xiàn)具體的訪問控制。Netfilter queue擴展用于將數(shù)據(jù)包從內(nèi)核空間提取到用戶空間，對數(shù)據(jù)包進行深度檢測。

　　Iptalbes四種表功能如下：

　　filter表：主要用于對數(shù)據(jù)包進行過濾，根據(jù)具體的規(guī)則決定是否放行該數(shù)據(jù)包；

　　nat表：主要用于修改數(shù)據(jù)包的IP地址、端口號等信息；

　　mangle表：主要用于修改數(shù)據(jù)包的TOS、TTL值以及為數(shù)據(jù)包設(shè)置Mark標記；

　　raw表：是自1.2.9以后版本的Iptables新增的表，主要用于決定數(shù)據(jù)包是否被狀態(tài)跟蹤機制處理。

　　Iptalbes五種規(guī)則鏈功能如下：

　　INPUT鏈：當接收到防火墻本機地址的數(shù)據(jù)包（入站）時，應(yīng)用此鏈中的規(guī)則；

　　OUTPUT鏈：當防火墻本機向外發(fā)送數(shù)據(jù)包（出站）時，應(yīng)用此鏈中的規(guī)則；

　　FORWARD鏈：當接收到需要通過防火墻發(fā)送給其他地址的數(shù)據(jù)包（轉(zhuǎn)發(fā)）時，應(yīng)用此鏈中的規(guī)則；

　　PREROUTING鏈：在對數(shù)據(jù)包作路由選擇之前，應(yīng)用此鏈中的規(guī)則，如DNAT；

　　POSTROUTING鏈：在對數(shù)據(jù)包作路由選擇之后，應(yīng)用此鏈中的規(guī)則，如SNAT。

　　其處理數(shù)據(jù)包的方式為：ACCEPT：允許數(shù)據(jù)包通過；DROP：直接丟棄數(shù)據(jù)包，不給任何回應(yīng)信息；REJECT：拒絕數(shù)據(jù)包通過，必要時會給數(shù)據(jù)發(fā)送端一個響應(yīng)的信息。數(shù)據(jù)包處理流程如圖4所示。

　　圖4 數(shù)據(jù)包處理流程

　　Netfilter queue擴展可加在圖4中的任意五鏈中，具體可由用戶定義。

　　2.4　MMS協(xié)議的深度分析

　　2.4.1　MMS協(xié)議深度分析之拆包

　　由具體函數(shù)完成對數(shù)據(jù)包的拆包、握手包深度檢測和mms協(xié)議的深度檢測。

　　利用python的dpkt庫完成對三層及以上的拆包處理。對于接收到的數(shù)據(jù)包拆包過程如下：首先利用get_payload()函數(shù)獲取三層及以上數(shù)據(jù)包的東西，然后利用hexdump()函數(shù)完成對數(shù)據(jù)包的unicode解碼，之后使用正則去除空格等特殊字符，將數(shù)據(jù)包中內(nèi)容放入列表。

　　2.4.2　MMS協(xié)議深度分析之TCP包深度分析

　　此部分代碼對TCP包進行了深度解析和判斷（黑名單原則）：握手包中syn和fin標記位不能同時為1；握手包中標記位不能都為0；握手包中不存在fin標記位為1且ack標記位為0的情況。

　　2.4.3　MMS協(xié)議深度分析之initiate請求報文深度分析

　　MMS協(xié)議在S-C端通信前都會先由client端發(fā)送initiate請求給server端，之后server端回一個initiate數(shù)據(jù)包給client端。

　　通過分析initiate請求數(shù)據(jù)包的特征，將其應(yīng)用層中的為true的功能碼記錄下來，并記錄該數(shù)據(jù)包源IP、源端口和目的端口。則后續(xù)的s-c端通信中，將所有的非initiate數(shù)據(jù)包進行深度檢測，發(fā)送的功能碼、源IP、源端口和目的端口必須為記錄中的，否則視為非法數(shù)據(jù)包。

　　根據(jù)大量MMS的initiate報文的深度分析和總結(jié)，發(fā)現(xiàn)其有以下特征：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協(xié)議的initiate請求報文各層數(shù)據(jù)長度除了應(yīng)用層均固定，如圖5所示。

　　圖5 MMS協(xié)議initiate請求報文

　　從圖5中可以看出：二層數(shù)據(jù)長度為14字節(jié)；三層數(shù)據(jù)長度為20字節(jié)；四層數(shù)據(jù)長度為32字節(jié)；TPKT層數(shù)據(jù)長度為4字節(jié)；ISO COTP層數(shù)據(jù)長度為3字節(jié)；ISO 8327-1層數(shù)據(jù)長度為24字節(jié)；ISO 8823層數(shù)據(jù)長度為69字節(jié)；ISO 8650-1層數(shù)據(jù)長度為47字節(jié)。

　　MMS協(xié)議中總共有90個功能碼，常用功能碼有6種，initiate請求報文中的功能碼描述如圖6所示，分為ture和false：

　　圖6 MMS協(xié)議非initiate請求數(shù)據(jù)包中功能碼

　　2.4.4　MMS協(xié)議深度分析之非initiate請求報文功能碼深度分析

　　通過分析initiate請求數(shù)據(jù)包的特征，將其應(yīng)用層中的為true的功能碼記錄下來，在后續(xù)的s-c端通信中，將所有的非initiate數(shù)據(jù)包進行深度檢測，發(fā)送的功能碼必須為記錄中的，否則視為非法數(shù)據(jù)包。

　　根據(jù)大量MMS的initiate報文的深度分析和總結(jié)，發(fā)現(xiàn)其有以下特征：非initi a te包目的端口號為COTP層PDU Type為f0；非initiate包兩個ISO8327-1層內(nèi)容必為0100；非initiate包ISO 8823層presentation context identifier值為03a。且一個正常的MMS協(xié)議的非initiate請求報文各層數(shù)據(jù)長度除了應(yīng)用層均固定，如圖7所示。

　　圖7 MMS協(xié)議非initiate請求數(shù)據(jù)包

　　從圖7中可以看出：二層數(shù)據(jù)長度為14字節(jié)；三層數(shù)據(jù)長度為20字節(jié)；四層數(shù)據(jù)長度為32字節(jié)；TPKT層數(shù)據(jù)長度為4字節(jié)；ISO COTP層數(shù)據(jù)長度為3字節(jié)；ISO 8327-1層數(shù)據(jù)長度為2字節(jié)；ISO 8327-1層數(shù)據(jù)長度為2字節(jié)；ISO 8823層數(shù)據(jù)長度為9字節(jié)。

　　其中本次防火墻可以識別的功能碼有6種，分別為read、write、getNameList、fileDirectory、fileOpen和fileRead，它們也是最常用的六種。

　　3　總結(jié)與展望

　　從工業(yè)網(wǎng)絡(luò)安全整體的考慮，現(xiàn)在的這些生產(chǎn)網(wǎng)由于擴大的規(guī)模、連接的無線、遠程的運維、現(xiàn)場的管理和數(shù)據(jù)的傳輸，已經(jīng)使生產(chǎn)線完全暴露在攻擊者面前[5]。對于企業(yè)的運營者以及安全的防護者，工業(yè)網(wǎng)絡(luò)安全的建設(shè)任重道遠，必須從全局上看，整體上看，著重于頂層設(shè)計，實施縱深防御的安全戰(zhàn)略。工控防火墻是這個體系的第一道防線，是工業(yè)網(wǎng)絡(luò)安全的重要組成部分[6]。因此本次對于基于IEC61850標準的MMS協(xié)議內(nèi)容過濾的工控防火墻設(shè)計具有十分重要的現(xiàn)實意義。