《電子技術(shù)應(yīng)用》
您所在的位置:首頁(yè) > 通信與網(wǎng)絡(luò) > 業(yè)界動(dòng)態(tài) > IEC61850協(xié)議內(nèi)容過(guò)濾的工控防火墻設(shè)計(jì)

IEC61850協(xié)議內(nèi)容過(guò)濾的工控防火墻設(shè)計(jì)

2018-08-16

  1 引言

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

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

  2 IEC61850標(biāo)準(zhǔn)內(nèi)容過(guò)濾的工控防火墻設(shè)計(jì)

  2.1 運(yùn)行環(huán)境

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

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

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

11509704095873545.jpg

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

  2.3 主要模塊

  2.3.1 前端

  規(guī)則添加:

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

21509704108337971.jpg

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

  2.3.2 后端

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

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

31509704120279104.jpg

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

  2.3.3 Iptables架構(gòu)

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

  Iptalbes四種表功能如下:

  filter表:主要用于對(duì)數(shù)據(jù)包進(jìn)行過(guò)濾,根據(jù)具體的規(guī)則決定是否放行該數(shù)據(jù)包;

  nat表:主要用于修改數(shù)據(jù)包的IP地址、端口號(hào)等信息;

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

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

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

  INPUT鏈:當(dāng)接收到防火墻本機(jī)地址的數(shù)據(jù)包(入站)時(shí),應(yīng)用此鏈中的規(guī)則;

  OUTPUT鏈:當(dāng)防火墻本機(jī)向外發(fā)送數(shù)據(jù)包(出站)時(shí),應(yīng)用此鏈中的規(guī)則;

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

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

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

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

41509704135699481.jpg

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

  Netfilter queue擴(kuò)展可加在圖4中的任意五鏈中,具體可由用戶定義。

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

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

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

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

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

  此部分代碼對(duì)TCP包進(jìn)行了深度解析和判斷(黑名單原則):握手包中syn和fin標(biāo)記位不能同時(shí)為1;握手包中標(biāo)記位不能都為0;握手包中不存在fin標(biāo)記位為1且ack標(biāo)記位為0的情況。

  2.4.3 MMS協(xié)議深度分析之initiate請(qǐng)求報(bào)文深度分析

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

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

  根據(jù)大量MMS的initiate報(bào)文的深度分析和總結(jié),發(fā)現(xiàn)其有以下特征:init包目的端口號(hào)為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。并且,一個(gè)正常的MMS協(xié)議的initiate請(qǐng)求報(bào)文各層數(shù)據(jù)長(zhǎng)度除了應(yīng)用層均固定,如圖5所示。

51509704150103629.jpg

  圖5 MMS協(xié)議initiate請(qǐng)求報(bào)文

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

  MMS協(xié)議中總共有90個(gè)功能碼,常用功能碼有6種,initiate請(qǐng)求報(bào)文中的功能碼描述如圖6所示,分為ture和false:

 61509704161104352.jpg

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

  2.4.4 MMS協(xié)議深度分析之非initiate請(qǐng)求報(bào)文功能碼深度分析

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

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

71509704173137899.jpg

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

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

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

  3 總結(jié)與展望

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


本站內(nèi)容除特別聲明的原創(chuàng)文章之外,轉(zhuǎn)載內(nèi)容只為傳遞更多信息,并不代表本網(wǎng)站贊同其觀點(diǎn)。轉(zhuǎn)載的所有的文章、圖片、音/視頻文件等資料的版權(quán)歸版權(quán)所有權(quán)人所有。本站采用的非本站原創(chuàng)文章及圖片等內(nèi)容無(wú)法一一聯(lián)系確認(rèn)版權(quán)者。如涉及作品內(nèi)容、版權(quán)和其它問(wèn)題,請(qǐng)及時(shí)通過(guò)電子郵件或電話通知我們,以便迅速采取適當(dāng)措施,避免給雙方造成不必要的經(jīng)濟(jì)損失。聯(lián)系電話:010-82306118;郵箱:aet@chinaaet.com。