工控通信協(xié)議書分析_第1頁
工控通信協(xié)議書分析_第2頁
工控通信協(xié)議書分析_第3頁
工控通信協(xié)議書分析_第4頁
工控通信協(xié)議書分析_第5頁
已閱讀5頁,還剩18頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

典型的工業(yè)控制系統(tǒng)通信協(xié)議的安全性分析./WORD格式可編輯典型工業(yè)控制系統(tǒng)通信協(xié)議安全性分析報告啟明星辰集團工控安全事業(yè)部2015/10/26目錄TOC\o"1-2"\h\z\u前言21ModbusTCP協(xié)議31.1協(xié)議簡介31.2協(xié)議規(guī)范41.3協(xié)議安全性分析62OPC協(xié)議82.1協(xié)議簡介82.2協(xié)議安全性分析143DNP3協(xié)議163.1協(xié)議簡介163.2協(xié)議規(guī)范163.3協(xié)議安全性分析184Ethernet/IP協(xié)議204.1協(xié)議簡介204.2協(xié)議規(guī)范204.3協(xié)議安全性分析215EtherCAT協(xié)議235.1協(xié)議簡介235.2協(xié)議規(guī)范235.3協(xié)議安全性分析25前言網(wǎng)絡協(xié)議是計算機網(wǎng)絡中進行數(shù)據(jù)交換而建立的規(guī)則、標準或約定。要理解工業(yè)網(wǎng)絡如何工作,首先要了解他們所使用的底層通信協(xié)議,及其應用場景和選擇這些協(xié)議的原因。目前,已有的許多工業(yè)控制專用協(xié)議,大多是為了提高效率和可靠性而設計的,以滿足大規(guī)模分布式控制系統(tǒng)的運行需要。同時,令人堪憂的是為了提升效率,而放棄了協(xié)議的安全特性,例如:要求額外開銷的認證和加密等措施。更有許多工控協(xié)議為了能夠適應以太網(wǎng)運行做了修改,使得協(xié)議存在可以被利用的漏洞。因此,啟明星辰對常見的ModbusTCP、OPC、DNP3、Ethernet/IP、EtherCAT這五種常見協(xié)議進行安全性分析,以期發(fā)現(xiàn)基于協(xié)議漏洞的攻擊方式。歡迎各位專家提寶貴意見。技術聯(lián)系人:鄭凌鵬:孟雅輝:ModbusTCP協(xié)議協(xié)議簡介Modbus是由Modicon<現(xiàn)為施耐德電氣公司的一個品牌>在1979年發(fā)明的,是一個劃時代、里程碑式的網(wǎng)絡協(xié)議,作為上個世紀第一個在工業(yè)現(xiàn)場總線發(fā)揮作用的工業(yè)總線協(xié)議,Modbus協(xié)議由于其免費、開放、簡單等優(yōu)點,至今仍然活躍在工業(yè)、建筑、基礎設施等領域中。隨著時代的發(fā)展和需求的變化,Modbus己經(jīng)衍生出ModbusPlus.ModbusTCP/IP等協(xié)議,其已經(jīng)發(fā)展成一個協(xié)議簇。在我國,已制定國家標準GB/T19582-2008《基于Modbus協(xié)議的工業(yè)自動化網(wǎng)絡規(guī)范》。Modbus協(xié)議是應用于電子控制器上的一種通用語言。通過此協(xié)議,控制器相互之間、控制器經(jīng)由網(wǎng)絡〔例如以太網(wǎng)和其它設備之間可以通信。使用Modbus協(xié)議,不同廠商生產(chǎn)的控制設備在各種網(wǎng)絡體系結構內(nèi)進行簡單通信,每種設備<PLC、HMI、控制面板、驅動程序、動作控制、輸入\輸出設備>都能使用Modbus協(xié)議來啟動遠程操作,在基于串行鏈路和以太TCP/IP網(wǎng)絡的MODBUS上可以進行相同通信。ModbusTCP以一種比較簡單的方式將Modbus幀嵌入TCP幀中。IANA<互聯(lián)網(wǎng)編號分配管理機構>給Modbus協(xié)議賦予TCP端口502。如下圖所示,每種設備都能使用Modbus協(xié)議來啟動遠程操作,在基于串行鏈路和以太網(wǎng)TCP/IP的Modbus上可以進行相同的通信,一些網(wǎng)關允許在幾種使用Modbus協(xié)議的總線或網(wǎng)絡之間進行通信。圖1-1ModbusTCP通信網(wǎng)絡協(xié)議規(guī)范ModbusTCP是OSI通信參考模型第七層上的應用層報文傳輸協(xié)議,它在連接至不同類型總線或網(wǎng)絡的設備之間提供客戶機/服務器通信。如下圖所示:協(xié)議格式如下:MBAP報文頭功能代碼數(shù)據(jù)圖1-2ModbusTCP協(xié)議應用數(shù)據(jù)單元的結構Modbus協(xié)議的功能碼分為三類:〔1公共功能碼是較好地被定義的功能碼;保證是唯一的;MODBUS組織可改變的;公開證明的;具有可用的一致性測試;MBIETFRFC中證明的;包含已被定義的公共指配功能碼和未來使用的未指配保留供功能碼。〔2用戶定義功能碼有兩個用戶定義功能碼的定義范圍,即65至72和十進制100至110;用戶沒有MODBUS組織的任何批準就可以選擇和實現(xiàn)一個功能碼;不能保證被選功能碼的使用是唯一的;如果用戶要重新設置功能作為一個公共功能碼,那么用戶必須啟動RFC,以便將改變引入公共分類中,并且指配一個新的公共功能碼?!?保留功能碼一些公司對傳統(tǒng)產(chǎn)品通常使用的功能碼,并且對公共使用是無效的功能碼。圖1-3Modbus功能碼分類典型的工業(yè)控制系統(tǒng)通信協(xié)議的安全性分析.WORD格式可編輯圖1-4公共功能碼定義協(xié)議安全性分析沒有認證機制在網(wǎng)絡連接方面,利用的是TCP協(xié)議。在知道目標IP地址的情況下,只要通過502端口就可以發(fā)起并建立通信連接。如果應用數(shù)據(jù)單元攜帶的功能碼是Modbus設備所支持的,那么就可以建立起一個合法的Modbus會話。沒有消息校驗<只有ModbusTCP存在該問題>。在某些ModbusTCP實現(xiàn)中,校驗和是在傳輸層而非應用層生成,從而使得假冒命令更加容易。沒有權限區(qū)分對于任何人,只要他能夠連接到目標Modbus設備上,那么他就可以執(zhí)行所有Modbus設備所具有的功能。數(shù)據(jù)明文傳輸Modbus協(xié)議封裝的是ADU,傳輸?shù)囊彩沁@個ADU,在網(wǎng)絡上都是以明文的形式傳輸,通過抓包技術就可以獲取并解析出里面的數(shù)據(jù)。由于工廠生產(chǎn)環(huán)境特殊性,不到萬不得已的地步,工廠很難做到隨時停工停產(chǎn)進行生產(chǎn)設備的更新?lián)Q代,因此在現(xiàn)有條件基礎上對Modbus協(xié)議以上三點缺點進行安全加固工作很有必要。沒有廣播抑制<只有串行Modbus變體存在該問題>串行連接的所有設備都會收到所有消息,意味著在串行連接設備鏈中,可以通過對不明地址進行廣播,有效地實現(xiàn)拒絕服務<Dos>攻擊。可編程性Modbus最危險的特點是它為編程控制器設計的,因此可以用來向RTU或PLC中注入惡意代碼,該問題也存在于許多其他工業(yè)協(xié)議中。一些需要特別關注的Modbus消息的例子包括:強制從設備轉到"只聽"<ListenOnly>模式的功能碼重啟通信的功能碼清除、擦除或重置診斷信息<如計數(shù)器與診斷寄存器>的功能碼請求關于Modbus服務器、PLC配置或其他敏感信息的功能碼對定義點列表及其值的Modbus請求<配置掃描>請求從站標志信息請求從站附加信息大小或長度有問題的ModbusTCP數(shù)據(jù)包??赡艿木芙^服務攻擊從服務器到多個節(jié)點的Modbus流量,可能的拒絕服務攻擊TCP端口502上的非Modbus或缺陷Modbus報文從設備忙異常代碼延遲〔異常碼06,可能的拒絕服務攻擊確認異常代碼延遲〔異常碼05,可能的拒絕服務攻擊不正確的報文長度〔最大253,可能的拒絕服務攻擊配置掃描〔例如定義的點列及其值〔30秒內(nèi)5個異常碼02可用功能碼掃描〔60秒內(nèi)3個異常碼01修改分隔符〔08-03周期較短〔實際閾值待定的無意義命令,暴力拒絕服務廣播性質的報文或一個主站向多個從站的請求包含在異常協(xié)議數(shù)據(jù)單元中的信息列出所有可用功能碼的命令<功能掃描>OPC協(xié)議OPC<OLEforProcessControl,用于過程控制的OLE>是一個工業(yè)標準,管理這個標準國際組織是OPC基金會,OPC基金會現(xiàn)有會員已超過220家。遍布全球,包括世界上所有主要的自動化控制系統(tǒng)、儀器儀表及過程控制系統(tǒng)的公司?;谖④浀腛LE<現(xiàn)在的ActiveX>、COM〔部件對象模型和DCOM〔分布式部件對象模型技術。OPC包括一整套接口、屬性和方法的標準集,用于過程控制和制造業(yè)自動化系統(tǒng)。OPC的出現(xiàn)解決了控制系統(tǒng)突破"信息孤島"的瓶頸問題。OPC技術建立了一組符合工業(yè)控制要求的接口規(guī)范,將現(xiàn)場信號按照統(tǒng)一的標準與SCADA,HMI等軟件無縫連接起來,同時將硬件和應用軟件有效地分離開。只要硬件開發(fā)商提供帶有OPC接口的服務器,任何支持OPC接口的客戶程序均可采用統(tǒng)一的方式對不同硬件廠商的設備進行存取,無須重復開發(fā)驅動程序。這樣大大提高了控制系統(tǒng)的互操作性和適應性。1995年,由Fisher-Rosemount、RockwellSoftware、Opto22、Intellution和IntuitiveTechnology發(fā)起成立OPC基金會。第一份OPC標準草案于1995年12月發(fā)布,第二份草案于1996年3月發(fā)布,第二份草案成功的吸引了大量開發(fā)人員的注意,并將其理念推向世界。OPC規(guī)范1.0版本于1996年8月29日正式出版,開始了全球范圍的活動。截止2011年,OPC國際基金會總共擁有440余位公司成員/80多位最終用戶成員,3500多家致力于開發(fā)OPC產(chǎn)品的公司,超過22000種產(chǎn)品,擁有3000多種產(chǎn)品資料,在包括中國在內(nèi)的全球52個國家和地區(qū)擁有眾多分支機構。隨著技術的發(fā)展和市場的需求,OPC技術的發(fā)展經(jīng)歷了三個主要階段,即經(jīng)典OPC、OPCXML-DA和OPCUA。協(xié)議簡介經(jīng)典OPCOPC第一階段的技術稱為經(jīng)典的OPC。根據(jù)工業(yè)應用的不同需求,經(jīng)典OPC包括的規(guī)范:DataAccess<DA>,Alarm&Events<A&E>,HistoricalDataAccess<HDA>,OPCBatch,OPCSecurity,OPCDX和OPCComplexData。其中應用較多的有DA,AE和HAD。DA指出如何訪問當前的過程數(shù)據(jù),A&E提供了基于事件信息的接口,HDA描述了如何訪問已存檔的數(shù)據(jù)。所有的接口都提供通過地址空間導航獲取可用數(shù)據(jù)的方法。OPCDAOPCDA即OPC數(shù)據(jù)訪問規(guī)范,它是由OPC基金會定義的其中一種通信規(guī)范,定義了實時數(shù)據(jù)如何在數(shù)據(jù)源和數(shù)據(jù)接收體〔比如PLC,HMI之間,在不知道彼此特定通信協(xié)議的情況下仍然進行交換、傳輸。年份版本備注19961.0初始規(guī)范19971.0a數(shù)據(jù)訪問,該名稱用于區(qū)分與其并行開發(fā)的其它19982.0-2.05a多處規(guī)范澄清和修改20033.0進一步補充和修改表2-1OPCDA規(guī)范主要版本OPC數(shù)據(jù)存取規(guī)范定義了OPC服務器中一組COM對象及其接口,并規(guī)定了客戶程序對服務器程序進行數(shù)據(jù)存取時需要遵循的標準。OPC數(shù)據(jù)存取規(guī)范以OPC對象模型邏輯為基礎,該模型包含三類對象:OPC服務器對象,OPC組對象和OPC項對象。OPC服務器對象并作為OPC組對象的包容器維護有關服務器的信息,OPC服務器對象主要實現(xiàn)IUnknown和IOPCServer接口,OPC客戶程序通過OPC服務器的接口與OPC對象進行通信,存取數(shù)據(jù)源,數(shù)據(jù)源可以是現(xiàn)場設備,也可以是應用程序,服務器內(nèi)部封裝了與I/O控制設備通訊及操作的具體實現(xiàn)過程;OPC組對象維護有關其自身的信息,提供包容OPC項的機制,并管理OPC項,它提供了一種客戶程序組織數(shù)據(jù)的手段,例如一個組中可以包括一個設備中所有的數(shù)據(jù)項,客戶程序和數(shù)據(jù)項之間可以建立基于"訂閱"的連接;有兩種類型的組,公共組和局域組,公共組可以被多個客戶共享,而局域組只能被一個客戶使用,每個組中都可以定義一個或多個OPC項。圖2-1OPCDA中的對象〔3OPCHDAOPCHDA即OPC歷史數(shù)據(jù)存取規(guī)范,提供了一種統(tǒng)一的在各種不同的應用層面之間傳遞數(shù)據(jù)的方式,但跟OPCDA完全不同的是,OPCHDA在不同角色之間傳遞的是非實時數(shù)據(jù),即不是當下的時刻,而是過去某點或某段時間內(nèi)的過程數(shù)據(jù)。任何支持OPCHDA規(guī)范的數(shù)據(jù)可視化、數(shù)據(jù)分析或者趨勢匯報的軟件,都可以從任何一個支持OPCHDA的過程歷史數(shù)據(jù)庫中讀取數(shù)據(jù)。因為OPCHDA已經(jīng)是一種非常之成熟的OPC訪問規(guī)范,所以現(xiàn)在市場上的主要過程歷史數(shù)據(jù)庫都支持OPCHDA,即使用戶所用的歷史數(shù)據(jù)庫沒有提供OPC通信,現(xiàn)在各大OPC供應商也都有為不同歷史數(shù)據(jù)庫提供OPC接口的軟件??梢钥闯銎鋺弥饕煌牡胤皆谟谒呛瓦^程數(shù)據(jù)庫進行數(shù)據(jù)交換,其余的應用和之前的OPCDA規(guī)范基本相同,是為了適應新需求而升級的規(guī)范。OPC歷史數(shù)據(jù)服務器對象實現(xiàn)了與歷史服務器進行讀取或寫入數(shù)據(jù)的功能,數(shù)據(jù)類型取決于服務器。通過接口可以獲取所有的COM對象,客戶端只能看到這些COM對象?!?OPCA&EOPCA&E即OPC報警事件規(guī)范,提供了基于事件信息的接口。OPC支持兩種類型的報警事件服務器:簡單的和復雜的。簡單服務器監(jiān)測報警或事件,并提供給報警事件客戶;復雜服務器從多個數(shù)據(jù)源處<包括簡單服務器>監(jiān)測報警或事件信息,并向報警事件客戶提供信息。報警事件客戶也分為三類:操作站、報警事件管理子系統(tǒng)和報警事件logging組件。OPC報警事件服務器包含一系列的對象和接口,這些對象和接口向客戶提供報警事件信息。OPC報警事件服務器中涉及以下幾個概念:報警〔Alarm:報警是一種非正常的狀態(tài)。狀態(tài)〔Condition:狀態(tài)是OPC報警事件服務器定義的,每個狀態(tài)還可以包含若干個子狀態(tài),狀態(tài)最終是和現(xiàn)場數(shù)據(jù)項聯(lián)系的。每一個狀態(tài)都包含一個或多個子狀態(tài)、屬性和質量等屬性。OPC報警事件服務器中定義狀態(tài)機處理相應的狀態(tài)或子狀態(tài)之間的變化。事件:OPC規(guī)范中定義了三種事件。條件事件:定義描述了狀態(tài)的變化。跟蹤事件:指當客戶與OPC事件服務器中定義的數(shù)據(jù)項之間發(fā)生交互時引發(fā)的事件。簡單事件:指除以上兩種事件以外的任何事件,例如,服務器中定義的物理系統(tǒng)和設備的錯誤等。OPCA&E服務器主要包括OPC事件服務器對象、OPC事件訂閱對象和OPC事件區(qū)域瀏覽對象。〔5OPCXML-DAOPCXML-DA是OPC基金會提出的一個基于XML規(guī)范和SOAP技術的接口規(guī)范,OPCXML-DA將要交換的結構化數(shù)據(jù)信息組織為SOAP消息來傳送。基于XML技術和SOAP技術的特征使得它可以更好地促進工業(yè)現(xiàn)場數(shù)據(jù)跨越Internet的傳輸,簡化不同應用間的互操作性,并將現(xiàn)場數(shù)據(jù)統(tǒng)一到企業(yè)層的運用中,實現(xiàn)諸如MES和ERP等系統(tǒng)的一體化連接,XML在OPC規(guī)范中的引入,為控制系統(tǒng)到信息系統(tǒng)之間的數(shù)據(jù)交換搭建了一個橋梁。控制系統(tǒng)現(xiàn)場采用XML描述的數(shù)據(jù)可以被管理信息系統(tǒng)中的標準XML解析器解析,而不需要根據(jù)不同的控制系統(tǒng)數(shù)據(jù)描述開發(fā)多種解析器,這使得統(tǒng)一和標準化的數(shù)據(jù)傳輸成為可能。OPCXML-DA支持8種服務,每種服務都包括1個請求和1個響應。通過對這些服務的定義,提供了訪問工業(yè)現(xiàn)場數(shù)據(jù)的標準接口,請求和響應按照SOAP協(xié)議標準被包裝成SOAP信封,信封標題說明消息如何被處理,信封正文則包含工業(yè)過程信息。OPCXML-DA支持的服務類型具體包括:GetStatus:返回關于服務器、版本、當前模式、運行狀態(tài)等信息;Browse:在服務器的命名空間里搜索所有可獲取的項的名字;GetProperties:返回1個或多個項的屬性相關信息;Write:向1個或多個項中寫入新值;Read:返回1個或多個項的值、品質和時間戳;Subscribe:指定1個客戶希望持續(xù)更新的項列表;SubscriptionCancel:刪除在前一個Subscrible調(diào)用中指定的項列表;SubscriptionPolledRefresh:返回上次調(diào)用以來在項列表中數(shù)值發(fā)生變化的所有項。〔6OPCUAOPC通信標準的核心是互通性<Interoperability>和標準化<Standardization>問題。傳統(tǒng)的OPC技術在控制級別很好地解決了硬件設備間的互通性問題,在企業(yè)層面的通信標準化是同樣需要的。OPCUA之前的訪問規(guī)范都是基于微軟的COM/DCOM技術,這會給新增層面的通信帶來不可根除的弱點。隨著傳統(tǒng)OPC技術不夠靈活、平臺局限等問題逐漸凸顯,OPC基金會于2006年發(fā)布了最新的OPC技術規(guī)范—OPC統(tǒng)一體系架構<OPCUA>,涵蓋了OPC實時數(shù)據(jù)訪問規(guī)范<OPCDA>、OPC歷史數(shù)據(jù)訪問規(guī)范<OPCHDA>、OPC報警事件訪問規(guī)范<OPCA&E>和OPC安全協(xié)議<OPCSecurity>的不同方面,但在其基礎之上進行了功能擴展。OPCUA是在傳統(tǒng)OPC技術取得很大成功之后的又一個突破,讓數(shù)據(jù)采集、信息模型化以及工廠底層與企業(yè)層面之間的通訊更加安全、可靠,它是未來OPC技術的核心發(fā)展技術規(guī)范。OPCUA的幾大優(yōu)勢:與平臺無關,可在任何操作系統(tǒng)上運行為未來的先進系統(tǒng)做好準備,與保留系統(tǒng)繼續(xù)兼容配置和維護更加方便基于服務的技術可見性增加通信范圍更廣通信性能提高OPCUA有效地將現(xiàn)有的OPC規(guī)范〔DA、A&E、HDA、命令、復雜數(shù)據(jù)和對象類型集成進來,成為現(xiàn)在的新的OPCUA規(guī)范。OPCUA提供了一致、完整的地址空間和服務模型,解決了過去同一系統(tǒng)的信息不能以統(tǒng)一方式被訪問的問題。通信性高OPCUA規(guī)范可以通過任何單一端口進行通信。這讓穿越防火墻不再是OPC通信的路障,并且為提高傳輸性能控制工程網(wǎng)版權所有,OPCUA消息的編碼格式可以是XML文本格式或二進制格式,也可使用多種傳輸協(xié)議進行傳輸,比如:TCP和通過HTTP的網(wǎng)絡服務??煽啃?、冗余性OPCUA的開發(fā)含有高度可靠性和冗余性的設計??烧{(diào)試的逾時設置控制工程網(wǎng)版權所有,錯誤發(fā)現(xiàn)和自動糾正等新特征,都使得符合OPCUA規(guī)范的軟件產(chǎn)品可以很自如地處理通信錯誤和失敗。OPCUA的標準冗余模型也使得來自不同廠商的軟件應用可以同時被采納并彼此兼容。標準安全模型OPCUA訪問規(guī)范明確提出了標準安全模型,每個OPCUA應用都必須執(zhí)行OPCUA安全協(xié)議,這在提高互通性的同時降低了維護和額外配置費用。用于OPCUA應用程序之間傳遞消息的底層通信技術提供了加密功能和標記技術,保證了消息的完整性,也防止信息的泄漏。平臺無關OPCUA軟件的開發(fā)不再依靠和局限于任何特定的操作平臺。過去只局限于Windows平臺的OPC技術拓展到了Linux、Unix、Mac等各種其它平臺?;贗nternet的WebService服務架構<SOA>和非常靈活的數(shù)據(jù)交換系統(tǒng),OPCUA的發(fā)展不僅立足于現(xiàn)在控制工程網(wǎng)版權所有,更加面向未來。OPCUA定義了一系列服務器所能提供的服務,特定的服務器需要向客戶端詳細說明它們所支持的服務;信息通過使用標準的和宿主程序定義的數(shù)據(jù)類型進行表達,服務器定義客戶端可識別的對象模型,服務器可以提供查看實時數(shù)據(jù)和歷史數(shù)據(jù)的接口,并且由報警和事件組件來通知客戶端重要的變量或事件變化,OPCUA可以被映射到一種通信協(xié)議上并且數(shù)據(jù)可以以不同的形式進行編碼來達到傳輸便捷和高效的目的。OPCUA的總體架構如下圖所示。圖2-3OPCUA總體架構協(xié)議安全性分析由于使用DCOM與RPC、OPC與OLE受到同樣漏洞的影響,從而導致OPC很容易受到攻擊。此外,OPC基于Windows操作系統(tǒng),很容易受到針對windows漏洞的攻擊影響。雖然OPC及相關控制系統(tǒng)漏洞只有ICS-CERT授權會員才能獲得,但大量現(xiàn)存OLE與RPC漏洞早已廣為人知。因為在工業(yè)網(wǎng)絡中為產(chǎn)品系統(tǒng)打補丁存在困難,所以目前正在使用的工控系統(tǒng)依然存在許多這樣的漏洞,哪怕微軟公司已經(jīng)提供了相應的補丁,但這種安全狀態(tài)一直沒有得到改變。而且由于OPC基于Windows系統(tǒng),通常的主機安全問題也會影響OPC系統(tǒng)。大量OPC主機使用弱安全認證機制,即使啟用了認證機制也常使用弱口令。許多系統(tǒng)啟用了與SCADA系統(tǒng)無關的額外Windows服務,導致非必需的運行進程和開放端口。這些問題將OPC系統(tǒng)廣泛暴露于攻擊之下。令問題更嚴重的是,由于Windows2000/XP審計設置默認不會記錄DCOM連接請求,因此攻擊發(fā)生時,日志記錄往往不充分甚至缺失,無法提供足夠的詳細證據(jù)。也就是說,與前述的簡單且目的單一的協(xié)議不同,OPC必須使用最新操作系統(tǒng)與網(wǎng)絡安全手段,將其作為大型系統(tǒng)對待。由于OPC依賴于微軟公司授權機制,因而弱口令是威脅OPC服務器安全的最嚴重脆弱性之一。另一個主要問題是,由于windows2000/XP的審計設置默認不會記錄DCOM的連接請求、SMB登錄以及訪問系統(tǒng)對象的嘗試,從而導致日志記錄不充分。其他OPC安全問題包括:過時的授權服務。受限于維護窗口、解釋性問題等諸多因素,工業(yè)網(wǎng)絡系統(tǒng)升級困難,導致不安全的授權機制仍在使用。例如,在許多系統(tǒng)中,仍在使用默認的Windows2000LanMan<LM>和WindowsNTLanMan<NTLM>機制,這些機制與其他過時的授權機制過于脆弱而易受攻擊。RPC漏洞。由于OPC使用RPC,因而易受所有RPC相關漏洞影響,包括幾個在授權前就暴露的漏洞。攻擊底層RPC漏洞可以導致非法執(zhí)行代碼或DoS攻擊。不必要的端口與服務。OPC支持除TCP/IP外的其他網(wǎng)絡協(xié)議,包括NetBEUI、在Ipx協(xié)議上面向連接的NetBIOS和HTTP互聯(lián)網(wǎng)服務等。OPC服務器完整性。攻擊者可以創(chuàng)建一個假冒OPC服務器,并使用這個服務器進行服務干擾、DoS攻擊、通過總線監(jiān)聽竊取信息或注入惡意代碼。通過監(jiān)控OPC網(wǎng)絡或OPC服務器〔服務器活動可以通過采集與分析Windows日志監(jiān)控可疑行為可以檢測多種威脅,包括:從OPC服務器發(fā)起的使用非OPC的端口與服務。出現(xiàn)已知OPC<包括底層OLERPC與DCOM>攻擊。來自未知OPC服務器的OPC服務<意味著存在假冒服務器>。OPC服務器上的失敗授權嘗試或其他授權異常。OPC服務器上由未知或未授權用戶發(fā)起的成功授權嘗。DNP3協(xié)議協(xié)議簡介DNP〔DistributedNetworkProtocol,分布式網(wǎng)絡協(xié)議是HARRIS公司推出的一種遠動通信協(xié)議,是目前電力系統(tǒng)自動化產(chǎn)品市場上的一種主流通信協(xié)議。DNP3.0是美國IEEE電力工程協(xié)會<PES>在IEC的基礎上制定的國家標準。DNP3.0的開發(fā)是HARRIS公司集其多年SCADA通信規(guī)約應用經(jīng)驗,并參與了多個標準委員會的經(jīng)驗交流的結果<如IEEE,IEC,EPRI/UCA,MMSForum,AMRA,ANSI,CCAC,CIGRE等標準委員會組織>。協(xié)議規(guī)范DNP3.0基于IEC870-5標準,采用了ISO七層模型中的三層:物理層、數(shù)據(jù)鏈路層和應用層,其結構為增強協(xié)議結構。這種分層結構使得數(shù)據(jù)傳送的可靠性大大提高,同時也便于軟件編程的模塊化。物理層一般采用普通的RS232或RS485;鏈路層采用CRC校驗;為了滿足較長數(shù)據(jù)包的傳送,又增加了一個偽傳輸層。發(fā)送數(shù)據(jù)時它可以將較長的應用層報文拆分為多個短幀然后多幀傳送,反之,接收時將短幀組裝成完整的應用層報文。 圖3-1DNP3通信協(xié)議結構圖DNP3.0的數(shù)據(jù)鏈路層協(xié)議規(guī)定了DNP3.0版的數(shù)據(jù)鏈路層,鏈路協(xié)議數(shù)據(jù)單元<LPDU>以及數(shù)據(jù)鏈路服務和傳輸規(guī)程。數(shù)據(jù)采用一種可變幀長格式:FT3。一個FT3幀被定義為一個固定長度的報頭,隨后是可以選用的數(shù)據(jù)塊,每個數(shù)據(jù)塊附有一個16位的CRC校驗碼。固定的報頭含有2個字節(jié)的起始字,一個字節(jié)的長度〔LENGH,一個字節(jié)的鏈路層控制字〔CONTROL,一個16位的目的地址,一個16位的源地址和一個16位的CRC校驗碼,共10個字節(jié)。圖3-2DNP3數(shù)據(jù)鏈路層協(xié)議格式傳輸層協(xié)議DNP的傳輸層是一個偽傳輸層。偽傳輸層功能專門設計用于在原方站和從方站之間傳送超出鏈路規(guī)約數(shù)據(jù)單元〔LPDU定義長度的信息。其格式如下:圖3-3DNP3傳輸層協(xié)議格式其中:傳輸層報頭:傳輸控制字,1個字節(jié)數(shù)據(jù)塊:應用用戶數(shù)據(jù)1-249個字節(jié)應用層規(guī)約:DNP3.0應用層歸約定義了應用層報文<APDU>的格式。這里,主站被定義為發(fā)送請求報文的站,而從站則為從屬設備。被請求回送報文的RTU或智能終端,只有被指定的主站能夠發(fā)送應用層的請求報文,而從站則只能發(fā)送應用層的響應報文。應用請求報文的格式:圖3-4DNP3應用層響應報文格式請求〔響應報頭:標識報文的目的,包含應用規(guī)約控制信息〔ACPI;對象標題:標識隨后的數(shù)據(jù)對象;數(shù)據(jù):在對象標題內(nèi)的指定的數(shù)據(jù)對象;應用報文報頭字段的定義:請求報頭有兩個字段。每個字段為8位的字節(jié),說明如下:圖3-5DNP3應用層請求報文報頭響應報頭有三個字段。前兩個字段為8位的字節(jié),第三個字段為兩個字節(jié),說明如下:圖3-6DNP3應用層響應報文報頭協(xié)議安全性分析DNP3的主要關注點集中在數(shù)據(jù)幀完整性方面,而它并沒有使用授權或加密機制<盡管在安全DNP3中有>。由于DNP3功能代碼與數(shù)據(jù)類型都已經(jīng)明確定義,因此篡改DNP3會話變得相當容易。不過,在DNP3協(xié)議中引入安全機制的同時帶來復雜度的增加,也為協(xié)議增加了出現(xiàn)漏洞的可能。ICS-CERT已報告了幾個DNP3漏洞。由于存在已知漏洞,而且DNP3協(xié)議已得到廣泛使用,因此建議對DNP3互聯(lián)進行適當滲透測試和補丁修復操作。一些常針對DNP3進行攻擊的實例包括使用MITM攻擊來竊取地址然后用于操縱系統(tǒng)。實例如下:關閉自主報告以癱瘓告警。向主控站發(fā)送虛假自發(fā)響應事件,并欺騙操作員采取不當行為。通過注入廣播數(shù)據(jù),在DNP3系統(tǒng)內(nèi)制造廣播風暴進行DoS攻擊篡改時間同步數(shù)據(jù),導致同步失鎖與通信錯誤。典型的工業(yè)控制系統(tǒng)通信協(xié)議的安全性分析.WORD格式可編輯篡改或阻塞確認信息,導致持續(xù)重傳。發(fā)起未授權的停止、重啟或其他可能擾亂工控系統(tǒng)運行的指令通過監(jiān)控DNP3會話,監(jiān)視特定功能碼和行為可以檢測多種威脅:在DNP3端口上使用非DNP3通信<TCP與UDP端口20000>。使用配置功能代碼23<禁用自發(fā)響應>。使用控制功能代碼4、5或6<操作、直接操作、無確認的直接操作>。使用應用程序控制功能18<停止應用程序>。大量超時自發(fā)響應<響應風暴>。對需要授權的操作進行任何非法嘗試。任何授權失敗。任何源自或去向一個未顯式定義為主/從設備的DNP3通信。Ethernet/IP協(xié)議協(xié)議簡介Ethernet/IP是由ODVA<OpenDeviceNetVendorsAssociation>和ControlNetInternational兩大國際工業(yè)組織所推出的面向工業(yè)自動化應用的工業(yè)應用層協(xié)議。Ethernet/IP是一個面向工業(yè)自動化應用的工業(yè)應用層協(xié)議。它建立在標準UDP/IP與TCP/IP協(xié)議之上,利用固定的以太網(wǎng)硬件和軟件,為配置、訪問和控制工業(yè)自動化設備定義了一個應用層協(xié)議。協(xié)議基于標準的以太網(wǎng)技術,使用所有傳統(tǒng)的以太網(wǎng)協(xié)議和標準的TCP/IP協(xié)議,并且采用了通用工業(yè)協(xié)議<CommonIndustrialProtocol,CIP>,共同構成Ethernet/IP協(xié)議的體系結構。協(xié)議規(guī)范Ethernet/IP協(xié)議各層結構如下圖所示:圖4-1Ethernet/IP協(xié)議結構圖在物理層和數(shù)據(jù)鏈路層采用標準以太網(wǎng)技術意味著Ethernet/IP可以和現(xiàn)在所有的標準以太網(wǎng)設備透明銜接工作,并且保證了Ethernet/IP會隨著以太網(wǎng)技術的發(fā)展而進一步發(fā)展。在網(wǎng)絡層和傳輸層,采用UDP協(xié)議傳送對實時性要求較高的隱式報文,將UDP報文映射到IP多播傳送。實現(xiàn)高效I/O交換。用TCP協(xié)議的流量控制和點對點特性通過TCP通道傳輸非實時性的顯式報文?;跇藴实腡CP/IP協(xié)議,在TCP或UDP報文的數(shù)據(jù)部分嵌入了CIP封裝協(xié)議。CIP協(xié)議是一個端到端的面向對象并提供了工業(yè)設備和高級設備之間連接的協(xié)議,獨立于物理層和數(shù)據(jù)鏈路層。使得連接在以太網(wǎng)上的各種設備具有較好的一致性,從而使不同供應商的產(chǎn)品能夠互相交互。Ethernet/IP工業(yè)以太網(wǎng)有著Devicenet現(xiàn)場總線和Controlnet現(xiàn)場總線都不具備的特點,即其不僅采用了OSI模型中的物理層、數(shù)據(jù)鏈路層和應用層,還涉及網(wǎng)絡層和傳輸層,并采用了TCP/IP協(xié)議。而Devicenet現(xiàn)場總線和Controlnet現(xiàn)場總線只對物理層、數(shù)據(jù)鏈路層和應用層進行了定義。Ethernet/IP通信協(xié)議模型在應用層的基礎上新增加了用戶層,并對工業(yè)控制中的功能塊進行了標準化操作,事先對其輸入、輸出、算法和參數(shù)等進行規(guī)定,并組成為能夠在現(xiàn)場設備中實現(xiàn)執(zhí)行功能的應用進程,目的是為了實現(xiàn)不同類型制造商的設備進行混合組態(tài)。CIP通用工業(yè)協(xié)議是Ethernet/IP、Devicenet和Controlnet3種網(wǎng)絡的交叉點,從而使3種網(wǎng)絡之間實現(xiàn)共享,并借由工業(yè)路由器連接起來。Ethernet/IP封裝協(xié)議Encapsulation位于TCP/IP和CIP協(xié)議之間,基于TCP/IP協(xié)議的Encapsulation協(xié)議數(shù)據(jù)包結構如下圖所示,其中封裝信息EncapsulationMessage包括封裝頭Encapsulationheader和命令數(shù)據(jù)Commandspecificdata兩部分組成。圖4-2Ether/IP協(xié)議格式協(xié)議安全性分析Ethernet/IP是實時以太網(wǎng)協(xié)議,容易受以太網(wǎng)漏洞影響。由于UDP之上的Ethernet/IP是無法連接的,因此沒有內(nèi)在的網(wǎng)絡層機制來保證可靠性、順序性或進行數(shù)據(jù)完整性檢查。同時CIP明確的對象模型也帶來如下的特有安全問題:CIP未定義任何顯式或隱式的安全機制;使用通用必需對象進行設備標識,為攻擊者進行設備識別與枚舉創(chuàng)造了條件;使用通用應用對象進行設備信息交換與控制,可能擴大遭受工業(yè)攻擊的范圍,令攻擊者可以操縱更多的工業(yè)設備;Ethernet/IP使用UDP與廣播數(shù)據(jù)進行實時傳輸,兩者都缺少傳輸控制,攻擊者易于注入偽造數(shù)據(jù)或使用注入IGMP控制報文操縱傳輸途徑。EtherCAT協(xié)議協(xié)議簡介EtherCAT技術是德國倍福<Beckhof>公司提出的實時工業(yè)以太網(wǎng)技術,它基于標準的以太網(wǎng)技術,具備靈活的網(wǎng)絡拓撲結構,系統(tǒng)配置簡單,具有高速、高有效數(shù)據(jù)率等特點,是一種開放式實時以太網(wǎng)在自動化控制技術領域,EtherCAT已經(jīng)成為一種全球范圍內(nèi)先進的技術標準。EtherCAT技術組〔ETG成立于2003年11月,截至2009

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論