基于suricata 的IEC104 插件設計與實現(xiàn)*

張周晶，申玲鈺

(1.中國電子科技網絡信息安全有限公司，四川 成都 610041；2.中國電子科技集團公司第三十研究所，成都 610041）

0 引言

隨著工業(yè)互聯(lián)網的發(fā)展，工業(yè)網絡單獨組網的狀態(tài)正在被改變，為了將人、數(shù)據(jù)和設備進行有效連接，國外眾多大型公司已根據(jù)其自身產品及產業(yè)特點構建了對應的工業(yè)互聯(lián)網平臺，我國在該領域也正在建立更加完善的框架。

中國工業(yè)互聯(lián)網聯(lián)盟設計并提出了工業(yè)互聯(lián)網平臺架構[1]，如圖1 所示，在該平臺架構設計中，工業(yè)安全防護貫穿了應用層、平臺層、Iaas 層以及邊緣層。在工業(yè)互聯(lián)網的架構中，互聯(lián)網可以訪問工業(yè)網絡的情況也變得更加普遍，工業(yè)互聯(lián)網的安全防護從底層到應用層都有關鍵技術，覆蓋工業(yè)互聯(lián)網全架構。在四個層面的安全防護中，數(shù)據(jù)安全包括數(shù)據(jù)存儲安全和數(shù)據(jù)傳輸安全是重點和難點。上傳和下發(fā)指令的工業(yè)協(xié)議會直接影響產品的質量、設備的運行狀態(tài)，如果指令不當，將對生產造成實際的損失，情況嚴重將毀壞生產設備，因此監(jiān)測防護設備對于工業(yè)協(xié)議的指令級行為監(jiān)測需求也在穩(wěn)步提高。

在工業(yè)協(xié)議中，IEC104 協(xié)議被廣泛應用于電力行業(yè)和軌道交通行業(yè)[2]。通過IEC104 協(xié)議，實體設備之間能夠通過數(shù)據(jù)傳輸進行設備的行為控制，例如控制主站能夠遠程讀取子站設備狀態(tài)，操作設備行為，調整設備參數(shù)，子站設備能夠主動定時上傳狀態(tài)及相關監(jiān)測數(shù)據(jù)。如果主站下達指令通過協(xié)議錯誤地發(fā)送給子站，會影響子站設備的正常行為，而子站上傳狀態(tài)錯誤則會影響主站對子站實際情況的監(jiān)測，因此IEC104 協(xié)議指令級的監(jiān)測、檢測和審計是工業(yè)環(huán)境中入侵檢測設備的必要功能。

圖1 工業(yè)互聯(lián)網平臺架構

在當前的入侵檢測軟件系統(tǒng)中，suricata 框架提供多平臺支持，能夠根據(jù)實際情況進行配置，并且具有高效的采集能力，自帶協(xié)議解析器引擎和基于snort 規(guī)則的檢測引擎，能夠滿足當前工業(yè)環(huán)境中的流量監(jiān)測、TCP 會話監(jiān)測及部分通用協(xié)議的指令監(jiān)測。因此在suricata 當前的解析器引擎、監(jiān)測引擎和輸出引擎內增加IEC104 協(xié)議的解析器、檢測器和日志輸出器能夠補充suricata 入侵檢測軟件框架在IEC104 協(xié)議監(jiān)測上的不足，為工業(yè)互聯(lián)網提供一個能夠進行指令級的可審計的入侵監(jiān)測系統(tǒng)。

1 Suricata 軟件框架

suricata 支持三種工作模式，分別是single 模式、autofp 模式和workers 模式。single 模式為單線程工作模式，即只啟動一個線程完成采集、分析、會話管理、檢測、日志輸出的功能；autofp 模式通常采用多采集線程，在采集和解析完成后發(fā)送給會話管理線程做后續(xù)處理；worker 模式采用多線程模式，每個線程完整地進行采集、每個線程獨立完成采集、分析、會話管理、檢測、輸出功能，驅動層就做了適當?shù)呢撦d均衡，單個數(shù)據(jù)包都在一個線程里處理。

Suricata 系統(tǒng)[3]采用自定義信號—與槽機制，用中斷信號進行中斷，從而調用對應回調函數(shù)的方式觸發(fā)流程，因此在程序初始化時，即依據(jù)配置信息初始化了回調函數(shù)。以auto 模式為例，數(shù)據(jù)包在被接收后，數(shù)據(jù)的流向如圖3 所示。先查找包對應的流，再根據(jù)數(shù)據(jù)包的信息更新對應的流，在StreamTcp 中判斷包是否需要校驗，然后根據(jù)StreamTcpPacket 更新數(shù)據(jù)包對應的流以及應用層數(shù)據(jù)；在檢測[4]的時候根據(jù)流監(jiān)測結果采用DetectFlow 或者DetectNoFlow，根據(jù)會話信息和規(guī)則內容進行匹配。在數(shù)據(jù)檢測結束后，進行日志的輸出。

圖2 suricata 三種工作模式流程圖

因此，IEC104 協(xié)議的插件包括三個部分：解析插件、檢測插件和日志輸出插件。協(xié)議解析插件能夠完成對于IEC104 報文的十六進制碼的分析，將IEC104 協(xié)議的報文解析成具有可讀性的結構化數(shù)據(jù)；檢測插件部分能夠根據(jù)解析器輸出的結構化數(shù)據(jù)和規(guī)則進行匹配比對，從而對指令級別的內容進行檢測，并記錄警告；日志輸出插件能夠將每條IEC104 報文的可讀性指令輸出。

2 IEC104 解析模塊設計

2.1 IEC104 解析模塊注冊

在圖2 中可見，入口為AppLayerParseSetup 中調用的注冊函數(shù)RegisterIEC104Parse。其中包括以下內容：

（1）注冊協(xié)議端口和協(xié)議名稱；

（2）注冊預處理函數(shù)，預處理函數(shù)使用位置在AppLayer 層判斷數(shù)據(jù)包的應用層類型時調用，預處理協(xié)議即會將數(shù)據(jù)傳入對應的應用層協(xié)議解析器，進行十六進制數(shù)據(jù)包解析；

（3）注冊解析函數(shù)IEC104RequestParse 和IEC104ResponseParse，分別處理請求和響應數(shù)據(jù)包；

（4）注冊應用層會話管理函數(shù)IEC104State Alloc，IEC104StateFree，IEC104StateTxFree

分別管理應用層狀態(tài)空間的分配、清理以及清理每個會話中的傳輸對象；

圖3 suricata 內部插件調用流程

（5）注冊傳輸對象相關函數(shù)，如獲取當前傳輸對象IEC104GetTx，獲取總的傳輸對象個數(shù)IEC104GetTxCnt；

（6）注冊日志相關函數(shù)，如傳輸對象日志狀態(tài)IEC104GetTxLogged，IEC104SetTxLogged；

（7）注冊IEC104GetAlstateProgressCompletionS tatus，返回當前應用層會話狀態(tài)。

重點關注解析函數(shù)內部的實現(xiàn)，即IEC104Parser。

2.2 IEC104 協(xié)議說明及解析函數(shù)設計

IEC104 規(guī)約發(fā)布于1992 年，更新于2002 年，當前使用較多的是2002 年版本?；赥CP/IP 的IEC104協(xié)議格式稱為應用規(guī)約數(shù)據(jù)單元（Application Protocol Data Unit,APDU），其中分為應用規(guī)約控制信息（Application Protocol Control Information,APCI）和應用服務數(shù)據(jù)單元（Application Service Data Unit,ASDU），根據(jù)傳輸需求分為不編號的控制功能格式（U 幀）、編號的監(jiān)視功能格式（S 幀）和編號的信息傳輸格式（I 幀）。

I 幀用于傳輸應用數(shù)據(jù)，根據(jù)類型標識的不同，數(shù)據(jù)格式各有差異，一般而言為APCI+ASDU 兩部分組成，總格式見圖4，其中控制域1 和控制域2為發(fā)送序號，控制域3 和控制域4 為接收序號，類型標識定義了信息對象的結構類型和格式，傳送原因標識了協(xié)議發(fā)出的原因，詳表見表1。ASDU 包含公共體地址和信息體地址，其中公共體地址長度為2 字節(jié)，其低位表示標志裝置地址；信息體地址長度為3 字節(jié)，對應點表的點號。

例如請求和響應的十六進制數(shù)如下所示，解釋如括號中所示。

請求：68(啟動符) 12（APDU 長度）02 c7（發(fā)送序號）ce ca（接收序號） 01（type）02（可變結構限定詞）03

響應：00（傳送原因） 01 00 (公共體地址)，49 01 00 （信息體地址）01（信息體元素）4a 01 00(信息對象地址) 00（信息體元素）…

U 幀為控制用報文，其格式見圖6，只有APCI格式部分一共只有啟動/啟動確認、停止傳送/停止傳送確認以及鏈路測試/鏈路測試確認共3 類6種命令。

S 幀用于無應用數(shù)據(jù)可傳輸時確認對方的發(fā)送，只有APCI 部分，其控制域如圖5 所示，控制域1和控制域2 已經被固定，即不存在發(fā)送序號，只有接收序號。

圖4 IEC104 報文結構

圖5 IEC104 報文S 幀結構

圖6 IEC104 報文U 幀結構

IEC104 協(xié)議中，U 幀和S 幀只有APCI 部分，僅I 幀有ASDU 部分，因此將IEC104 的解析區(qū)分為APCIParser 和ASDUParser。APCIParser 需要解析啟動字符為0x68，APDU 長度，控制域1，控制域2，控制域3 和控制域4，每個控制域為一個字節(jié)。根據(jù)1.1 節(jié)可知，能夠通過控制域1 的低2 位來區(qū)分幀格式，若低2 位為0x00，則為I 幀，0x01 為S 幀，0x03 為U 幀。

ASDUParser 僅解析I 幀報文的ASDU 結構體，ASDU 為變長結構體和定長結構體兩部分，定長結構體能夠解析內容為報文類型，傳送質量、傳送信息體個數(shù)、原因、測試以及對象地址，變長部分為信息體地址及其結構體。由于變長部分有自定義內容，因此只檢查報文的完整性，不做內容具體解析。從應用層第7 字節(jié)開始，獲取定長結構體信息，再根據(jù)解析到的信息體個數(shù)完成已知信息體格式的結構體解析。

例如，若報文為I 類型報文，其應用層報文為：

68（啟動字符） 0e (長度) 04 00（RX） 00 00(TX)03 01 01 00 01 00 00 00 00 00

第一字節(jié)到第七字節(jié)由APCIParser 解析，剩余部分由ASDUParser 解析，解析結果如表1 所示。

表1 parser 處理內容及對應關系

在注冊完成后，流操作線程會根據(jù)數(shù)據(jù)流走向調用對應的已經注冊的IEC104 函數(shù)，從而進行創(chuàng)建、設置和解析。這也是suricata 框架的一大優(yōu)點，即解析器的狀態(tài)分配都是可以被流操作線程控制的。重點關注的是請求和響應的解析函數(shù)。由于IEC104 數(shù)據(jù)報文的請求和響應都是I 幀、U幀和S 幀，其實完成的是同一個IEC104Parser。IEC104Parser 的流程圖如圖所示，其總流程為：收到應用層數(shù)據(jù)包并檢測會話狀態(tài)、流狀態(tài)；然后解析APCI 頭部的固定格式，若完成解析則給當前State 創(chuàng)建Tx，根據(jù)APCI 頭部信息檢查包類型，若為I 幀，則調用ASDUParser 進行解析，直到解析完成，并處理可能存在的待組包層應用層信息。流程圖如圖6 所示。

3 IEC104 監(jiān)測模塊的設計

監(jiān)測模塊以解析模塊為基礎，輸入為解析結果，如自定義IEC104 結構transaction 等，IEC104 協(xié)議監(jiān)測模塊針對數(shù)據(jù)包類型PacketType 和TypeId。入口函數(shù)為SigTableSetup[5]，需要將PacketType 和TypeId 的三類函數(shù)，即setup，free，match 函數(shù)進行注冊，同時注冊IEC104 的監(jiān)測模塊到主引擎。

suricata 引擎首先確定了回調函數(shù)的參數(shù)，應用層協(xié)議注冊監(jiān)測模塊時，setup、free、match 的回調函數(shù)需要按照固定參數(shù)注冊。在PacketType 中對I 幀、U 幀、S 幀進行告警。若I 幀進行警告日志的輸出，在初始化時，s 引擎將該規(guī)則轉換成可用數(shù)據(jù)，存儲在DetectIEC104 結構中，通過與解析結果進行比對，即可得到結果。PacketType 的檢測流程為：通過match 函數(shù)獲取解析結構transaction 和預置規(guī)則結構DetectIEC104，通過比對transaction 中packetType 和檢測結構中的packetType 即可得出結果，若相同則返回1，表示需要輸出警告信息，否則輸出0，不進行警告信息輸出。

4 IEC104 日志模塊的設計

suricata 框架的日志模塊為獨立模塊，在worker模式下日志模塊的結構圖如圖8 所示。注冊的table包括告警表、應用層協(xié)議日志表等，在應用層日志輸出時，在調用時按照數(shù)據(jù)包日志表、傳輸日志表、文件日志表、文件內容日志表及流日志表的順序輪詢，在查到傳輸數(shù)據(jù)表時也按照圖8 第二行注冊的表信息依次輪詢，首先找到alert 表，查看alert 表是否有警告信息需要輸出，若有則調用回調函數(shù)進行輸出，若沒有，則繼續(xù)查詢到應用層日志事件表，若有輸出，則調用輸出函數(shù)進行輸出，5 張數(shù)據(jù)表中都注冊有一到多個子表。

IEC104 日志模塊通過OutputRegisterLoggers()調用IEC104 的日志注冊函數(shù)，注冊函數(shù)JsonIE C104Register 注冊了ToServer 和ToClient 的線程啟停管理函數(shù)，配置讀取函數(shù)及日志輸出函數(shù)，并在Init 時通過AppLayerParserRegisterLogger 將IEC104的日志模塊注冊到日志的module 里。在軟件初始化時，調用狀態(tài)初始化函數(shù)JsonIEC104LogInitCtx初始化讀取到的配置信息，配置信息包括文件類型、文件狀態(tài)，根據(jù)配置信息完成文件創(chuàng)建、文件狀態(tài)初始化，JsonIEC104LogDeInitCtx 完成文件的清理。JsonIEC104LoggerToClient 和JsonIEC104 LoggerToServer 分別生成請求及響應的報文日志。在生成日志前，傳入參數(shù)傳輸對象Tx，Tx 中存儲解析后的內容，如APCI 頭部結構，ASDU 內部結構，通過讀取Tx 結構體能夠將關心的參數(shù)如typeId，causeTx 等信息提取至json 格式中。通過調用CreateJSONHeader，能夠將該數(shù)據(jù)包的流信息輸出到json 格式中暫存，通過OutputJSONBuffer 將js數(shù)據(jù)寫入buffer 中，并將buffer 通過LogFileWrite 的方式輸出，輸出結構是根據(jù)配置信息中的logType進行區(qū)分，根據(jù)配置和依賴項可以支持寫入syslog文件、unix socket 或者redis 服務器上。

圖7 解析函數(shù)設計流程圖

圖8 日志模塊數(shù)據(jù)結構設計

5 IEC104 插件實現(xiàn)結果

IEC104 插件實現(xiàn)后，會有以下日志結果發(fā)生變化。首先是suricata 的運行日志，其中會增加應用層IEC104 的數(shù)據(jù)解析個數(shù)、transaction 個數(shù)信息。其示例如圖9 所示。

圖9 stats 增加數(shù)據(jù)結構

其次，能夠在日志中看到iec104 的日志信息，其示例如下：

6 結語

通過在suricata 軟件框架下設計及實現(xiàn)IEC104插件，當前的版本能夠統(tǒng)計IEC104 的報文個數(shù)、流量情況，能根據(jù)IEC104 解析器解析結果報告指令、傳輸原因和公共體地址信息。該設計增強了suricata 的功能，提供了針對性的檢測和告警信息。能夠完成工業(yè)互聯(lián)網的指令級檢測。