趙國新 ，丁若凡，游建舟，呂世超，彭 鋒，李 菲，孫利民

（1.北京石油化工學院信息工程學院，北京 102617；2.北京化工大學信息科學與技術(shù)學院，北京 100020；3.中國科學院信息工程研究所，北京 100089）

0 引言

隨著“中國制造2025”的推進，傳統(tǒng)工業(yè)開始了信息化、數(shù)字化、智能化的產(chǎn)業(yè)升級。與此同時，隨著大量工業(yè)設備不可避免地接入互聯(lián)網(wǎng)，工業(yè)控制系統(tǒng)信息安全也面臨著日益嚴重的挑戰(zhàn)和威脅［1］。自2010 年震網(wǎng)事件以來，工控信息安全問題一直備受國內(nèi)外各界關(guān)注。從國家互聯(lián)網(wǎng)應急中心［2］發(fā)布的《2017 年中國互聯(lián)網(wǎng)網(wǎng)絡安全報告》可知，世界各國越來越重視工控網(wǎng)絡信息安全?；诠た匕踩I域相關(guān)研究［3-4］表明，為了應對互聯(lián)網(wǎng)中潛在的威脅，僅僅依靠被動防御是不夠的，應用蜜罐技術(shù)進行主動防御是工控安全防護領域的殺手锏［5-6］。

蜜罐技術(shù)是一種安全威脅的主動檢測技術(shù)，它通過設置誘餌性質(zhì)的虛擬系統(tǒng)來吸引攻擊者入侵并對其進行攻擊捕獲。蜜罐技術(shù)在近十幾年內(nèi)呈現(xiàn)交互能力由低到高、兼容功能由少到多的趨勢。事實上，蜜罐的分類方式最常用的是按照其與外界的交互能力分為低、中、高交互蜜罐，其區(qū)別在于提供交互的空間是否覆蓋完整的操作系統(tǒng)。

由于工控系統(tǒng)的設計封閉性和架構(gòu)特殊性，上述以通用服務器為對象的分類標準難以評估工控的過程控制特性。因此，本文從架構(gòu)特點出發(fā)，劃分了工控設備的交互層次，提出一種新的工控蜜罐分類方法。低交互工控蜜罐具備網(wǎng)絡層的基礎協(xié)議棧的通信能力。中交互工控蜜罐具備操作系統(tǒng)層指令模擬能力，如開機關(guān)機、代碼上傳/下載等。高交互工控蜜罐具備生產(chǎn)現(xiàn)場業(yè)務過程控制的仿真能力。

基于上述分類標準，本文設計并實驗驗證了一種可編程邏輯控制器（Programmable Logic Controller，PLC）蜜罐框架，主要工作如下：

1）設計了基于工控業(yè)務仿真的PLC 蜜罐系統(tǒng)框架，由工控業(yè)務模塊、數(shù)據(jù)轉(zhuǎn)存模塊和信息服務模塊三部分組成。

2）提出了工控私有協(xié)議的解析與模擬方法，實現(xiàn)了S7comm 私有功能拓展。通過與西門子S7-300 PLC 設備的交互實驗結(jié)果，新增了11種S7comm私有功能。

3）提出了Simulink 的工控業(yè)務實時仿真方法，其提供的仿真數(shù)據(jù)與S7comm 私有功能相互協(xié)同，有效實現(xiàn)控制指令的執(zhí)行與響應。在交互層次上貫穿了信息域和物理域，大大增強蜜罐的業(yè)務真實度和可靠性。

1 相關(guān)工作

國內(nèi)外各信息安全領域的研究者一直致力于蜜罐技術(shù)的發(fā)展。2004 年Cisco 公司以honeyd［7］為基礎首先實現(xiàn)了具有Modbus 服務的工控蜜罐系統(tǒng)［8］。2011 年Tamminen［9］提出的Kippo 是一款基于Python 并支持多操作系統(tǒng)的蜜罐工具。2013 年Glastopf 蜜網(wǎng)項目［10］發(fā)布了首個開源工控蜜罐框架Conpot，使用Python 編寫，主要實現(xiàn)了對Modbus、S7comm、簡單網(wǎng)絡管理協(xié)議（Simple Network Management Protocol，SNMP）、超文本傳輸協(xié)議（HyperText Transfer Protocol，HTTP）等多種工控協(xié)議和互聯(lián)網(wǎng)協(xié)議的仿真。2014 年Buza 等［11］實現(xiàn)的CryPLH以S7comm服務為基礎，擴展實現(xiàn)了SNMP、HTTP服務，增強了蜜罐的交互性。2015年實現(xiàn)的Cowrie［12］是Kippo的繼承者，擴展了對安全拷貝協(xié)議（Secure Copy Protocol，SCP）、安全外殼協(xié)議（Secure SHell，SSH）文件傳輸協(xié)議（SSH File Transfer Protocol，SFTP）和Telnet 協(xié)議的支持。2016 年Lau等［13］提出的XPOT實現(xiàn)了對Nmap等系統(tǒng)指紋識別工具的欺騙，作者指出如果能結(jié)合工業(yè)過程模擬，會進一步提升蜜罐的交互性。同年Litchfield 等［14］提出了HoneyPhy，該框架考慮了信息物理系統(tǒng)（Cyber-Physical System，CPS）過程和設備的行為，進行了簡單的理論驗證和實驗。2017 年Kyung 等［15］提出一種基于軟件定義網(wǎng)絡（Software Defined Network，SDN）的蜜網(wǎng)系統(tǒng)HoneyProxy，支持低高交互蜜罐動態(tài)轉(zhuǎn)換。而國內(nèi)對蜜罐技術(shù)的研究起步較晚，北京大學計算機研究所“狩獵女神”項目組于2004 年開始捕獲并深入分析攻擊案例。近年來，中國科學院信息工程研究所研究并實現(xiàn)了針對電力系統(tǒng)的IEC104 規(guī)約蜜罐、人機接口（Human Machine Interface，HMI）電力調(diào)度系統(tǒng)蜜罐等與行業(yè)緊密結(jié)合的蜜罐。

從工控特有的分類看，上述工控蜜罐主要在信息域交互方面進行拓展和開發(fā)，或僅實現(xiàn)了理論設計，未實現(xiàn)有效的實驗驗證和應用部署。因此，現(xiàn)有工控蜜罐工作應當被歸類為中交互工控蜜罐，主要缺乏物理域交互能力。

2 高交互PLC蜜罐系統(tǒng)架構(gòu)設計

針對現(xiàn)有工控蜜罐存在無法與攻擊者交互，或者有交互但數(shù)據(jù)、系統(tǒng)可信度低的問題，本文基于工控業(yè)務仿真的固有特征，設計了一種高交互PLC蜜罐系統(tǒng)架構(gòu)，為蜜罐通信提供真實的實時生產(chǎn)數(shù)據(jù)和生產(chǎn)環(huán)境來欺騙攻擊者，從而在全新領域?qū)崿F(xiàn)了蜜罐的交互能力突破。

如圖1 所示，本文設計的高交互PLC 蜜罐總體架構(gòu)分為信息服務仿真模塊、過程控制仿真模塊和數(shù)據(jù)轉(zhuǎn)存模塊3 個部分，數(shù)據(jù)流動分為服務仿真循環(huán)和過程仿真循環(huán)兩條路線。

信息服務仿真模塊通過部署Conpot 蜜罐來仿真西門子S7-300PLC 設備，使用Conpot 內(nèi)置的S7comm 服務器與外界進行交互，并以此為基礎開發(fā)實現(xiàn)了多種S7comm 私有服務的仿真。S7comm 私有服務仿真能夠根據(jù)攻擊者的請求，調(diào)用相應函數(shù)，通過讀取數(shù)據(jù)轉(zhuǎn)存模塊中實時生產(chǎn)數(shù)據(jù)庫里的數(shù)據(jù)并組入響應數(shù)據(jù)包，或者將攻擊者提供的控制指令寫入實時控制數(shù)據(jù)庫，以滿足交互需求。本模塊與數(shù)據(jù)轉(zhuǎn)存模塊之間的數(shù)據(jù)流通構(gòu)成了服務仿真循環(huán)。

過程控制仿真模塊對燃氣管網(wǎng)過程進行了仿真建模。通過在Simulink 中運行該仿真模型，系統(tǒng)能夠生成實時生產(chǎn)數(shù)據(jù)，并通過仿真?zhèn)鞲衅鲗崟r輸出，最終寫入到數(shù)據(jù)轉(zhuǎn)存模塊的實時生產(chǎn)數(shù)據(jù)庫中；同時該系統(tǒng)具備仿真的閥門輸入接口，會接收實時控制數(shù)據(jù)庫實時發(fā)送的數(shù)據(jù)作為系統(tǒng)的控制信號。本模塊與數(shù)據(jù)轉(zhuǎn)存模塊的數(shù)據(jù)流通構(gòu)成了過程仿真循環(huán)。

數(shù)據(jù)轉(zhuǎn)存模塊是上述兩個模塊的交互中轉(zhuǎn)站，也是兩個數(shù)據(jù)仿真循環(huán)的核心。數(shù)據(jù)轉(zhuǎn)存模塊中建立了兩個不同的數(shù)據(jù)庫，分別為實時生產(chǎn)數(shù)據(jù)庫和實時控制數(shù)據(jù)庫，使用腳本程序來實現(xiàn)一系列讀取、存儲和發(fā)送的功能。通過這里的數(shù)據(jù)存儲、流通，信息服務仿真模塊能夠讀取到過程控制仿真模塊的實時生產(chǎn)數(shù)據(jù)，過程控制仿真模塊也能夠根據(jù)信息服務仿真模塊下達的實時指令改變生產(chǎn)狀態(tài)，以此實現(xiàn)了控制過程仿真運行狀況的閉環(huán)邏輯。

3 關(guān)鍵技術(shù)

3.1 S7comm私有協(xié)議解析與實現(xiàn)方法

S7comm 協(xié)議是西門子S7 系列PLC 內(nèi)部集成的一種私有不公開協(xié)議，屬于傳輸控制協(xié)議/網(wǎng)際協(xié)議（Transmission Control Protocol/Internet Protocol，TCP/IP）協(xié)議族的一種。它運行在應用層中，經(jīng)過特殊優(yōu)化，用于西門子設備之間或者與外界進行通信。S7comm 協(xié)議常用的通信方式是基于以太網(wǎng)的客戶端/服務端模式：PLC 設備作為服務端，接收外界訪問請求數(shù)據(jù)包并執(zhí)行相應服務，返回響應數(shù)據(jù)包；外界訪問者作為客戶端，與PLC進行通信，發(fā)送請求數(shù)據(jù)包并接收響應數(shù)據(jù)包。本文針對Conpot 的S7comm 服務器進行了深度開發(fā)，從協(xié)議仿真的角度開發(fā)實現(xiàn)了更多S7comm 私有服務功能，從而符合本文設計的PLC蜜罐系統(tǒng)的需求。

3.1.1 S7私有協(xié)議的解析和模擬

S7comm 協(xié)議不同設備間使用S7 數(shù)據(jù)包進行通信。如圖2 所示，S7 數(shù)據(jù)包使用了多種協(xié)議進行協(xié)議數(shù)據(jù)單元（Protocol Data Unit，PDU）封裝，S7 數(shù)據(jù)在經(jīng)過面向連接的傳輸協(xié)議（Connection-Oriented Transport Protocol，COTP）協(xié)議和應用程數(shù)據(jù)傳輸協(xié)議（ISO transport services on top of the TCP，TPKT）協(xié)議打包后，由TCP/IP協(xié)議進行連接和輸送。

圖2 S7comm協(xié)議包頭格式Fig.2 S7comm protocol packet header format

如圖3 所示，S7comm 協(xié)議服務端和客戶端之間的通信流程分為三次握手。第一次握手是經(jīng)過客戶端和服務端COTP請求與應答，建立基于國際標準化組織傳輸協(xié)議（International Organization for Standardization_Transport Protocols，ISO_TP）的連接；第二次握手進行S7 通信設置，建立S7comm 連接；第三次握手進行S7comm 服務的應答交互，最終服務端會生成基于特定S7comm 私有功能的響應數(shù)據(jù)包返回給客戶端。

圖3 S7comm協(xié)議通信流程Fig.3 S7comm protocol communication process

根據(jù)以上對S7comm 協(xié)議通信三次握手原理的解析，Conpot 通過對S7 通信系統(tǒng)中服務端功能進行模擬，建立了S7comm 服務器。如圖4 所示，其處理信息的流程主要分為以下幾步：

1）S7comm 服務器從Conpot獲取執(zhí)行流，與客戶端建立連接。然后，進入會話處理流程，開始循環(huán)接收數(shù)據(jù)包，為客戶端提供服務。

2）S7comm 服務器會接收握手信息的前四個字節(jié)：如果接收的數(shù)據(jù)為空，S7comm 服務器會結(jié)束本次會話；否則，會接收握手信息的剩余信息。然后，S7comm 服務器會解析包頭，提取出length 參數(shù)，用于判定是否是非法的S7comm 數(shù)據(jù)包請求。

3）S7comm 服務器完成第一次握手，建立ISO_TP 連接。ISO_TP握手信息的標識tpdu_type參數(shù)值為0xe0，只有通過本次握手，ISO_TP連接才能建立起來。

4）S7comm 服務器完成第二次握手，建立S7comm 連接。S7comm握手信息的標識tpdu_type參數(shù)值為0xf0，只有通過本次握手，S7comm連接才能建立起來。

5）S7comm 服務器開始第三次握手，開始接收S7comm 的數(shù)據(jù)循環(huán)。服務器解析TPKT 和COTP 層數(shù)據(jù)，當請求數(shù)據(jù)的tpdu_type 參數(shù)值為0xf0 時，表明該PDU 是通信數(shù)據(jù)（而非握手信息），S7comm 會解析此數(shù)據(jù)并據(jù)此生成響應數(shù)據(jù)包；然后，將響應數(shù)據(jù)包發(fā)送給客戶端，完成第三次握手；最后，S7comm服務器會準備接收本次會話的下一個數(shù)據(jù)包。

S7comm 服務器具備完整的信息交互機能，通過扮演PLC設備的角色來取信于外界攻擊者。除此之外，S7comm 服務器還集成了日志記錄功能，研究者可以通過分析日志來獲取攻擊者信息、研究攻擊模式、提升防護能力。

圖4 Conpot中S7comm服務器工作流程Fig.4 Workflow of S7comm server in Conpot

3.1.2 新增S7comm私有功能

S7 功能碼是S7comm 協(xié)議數(shù)據(jù)包中用來標明自身所代表何種S7comm 私有功能的數(shù)字碼，每個功能碼代表一種S7comm 私有功能。在Conpot 的S7comm 服務器通信過程中，當客戶端向服務端發(fā)送請求數(shù)據(jù)包時，數(shù)據(jù)包中S7Data 包含的功能碼將告訴服務端需要執(zhí)行的是哪種服務。服務端會據(jù)此調(diào)用不同的功能碼程序來產(chǎn)生特定數(shù)據(jù)。這些數(shù)據(jù)經(jīng)過處理后會被組入響應數(shù)據(jù)包，最終返回給客戶端。

Conpot雖然搭建了S7comm 服務器的交互框架，卻并沒有廣泛地實現(xiàn)S7comm 協(xié)議內(nèi)的諸多S7comm 私有功能。目前為止，S7comm 協(xié)議中解析了12 種主功能碼，20 種次級功能碼，而Conpot除了簡單的次級功能“讀取系統(tǒng)狀態(tài)列表”外，其余功能碼對應的S7comm 私有功能均未實現(xiàn)，因此實際上無法正常進行S7 通信，也就無法返回攻擊者客戶端正常的響應數(shù)據(jù)包。

2019 年游建舟等［16］關(guān)注并初步進行了S7comm 私有功能的開發(fā)工作，本文在其基礎上進行了進一步的方法整理和代碼重構(gòu)。如表1 所示，通過與真實PLC 設備做交互實驗，在Conpot中新增了11種S7comm私有服務。

表1 在Conpot中新增的S7comm服務器功能碼Tab.1 New S7comm function codes added in Conpot

S7comm私有功能擴展的開發(fā)流程如下：

1）主機PC 連接西門子S7-300PLC。其中PC 的IP 要與PLC配置在同一網(wǎng)段內(nèi)。

2）根據(jù)S7comm 協(xié)議的握手機制向PLC 發(fā)送包含待實現(xiàn)功能碼的三段請求數(shù)據(jù)包，建立S7comm通信。

3）用wireshark抓取PLC設備的響應數(shù)據(jù)包。

4）分析Conpot 源碼中對S7 數(shù)據(jù)包的解析過程，對執(zhí)行程序進行修改和完善，確保其對新增S7comm 私有功能的兼容性。

5）基于之前捕捉到的PLC的響應，在S7comm服務器中添加實現(xiàn)對應功能碼的數(shù)據(jù)生成器。其任務是根據(jù)功能碼對應的不同S7comm 私有功能，輸出特定parament 值和data 值，將其寫入S7data，再交給S7comm 客戶端中其他模塊進行進一步的協(xié)議封裝。

在設置對應S7comm 私有功能的功能碼響應數(shù)據(jù)時，單純的信息重放是不足以欺騙攻擊者的，需要根據(jù)數(shù)據(jù)包字段結(jié)構(gòu)來對響應數(shù)據(jù)包進行編輯。以Read 功能碼和Write 功能碼為例，通過上述流程，獲得其響應數(shù)據(jù)包如下：

表2 分別是其數(shù)據(jù)包字段解析示例，前者由服務端輸出蜜罐能夠提供給攻擊者的信息，后者由客戶端輸入攻擊者想要寫入的信息。本文選擇Read 和Write 功能碼進行深度解析，為蜜罐系統(tǒng)建立了讀取數(shù)據(jù)、控制數(shù)據(jù)的功能，不僅在S7comm 私有服務方面具備功能協(xié)同性，也在現(xiàn)有系統(tǒng)框架下，將真實攻擊者與PLC 的通信邏輯納入了物理域的信息交互之中。

表2 Read和Write功能碼響應數(shù)據(jù)包的字段解析Tab.2 Field analysis of response package of Read and Write function code

3.2 基于Simulink的以太網(wǎng)通信與控制

為了提升信息服務仿真模塊中S7comm 私有服務仿真的真實性、在過程控制仿真模塊里提供實時更新動態(tài)的生產(chǎn)數(shù)據(jù)，并在蜜罐系統(tǒng)內(nèi)構(gòu)建模擬真實生產(chǎn)現(xiàn)場PLC的工作過程，需要使用Matlab/Simulink 來搭建實時仿真系統(tǒng)。Simulink 是Matlab 中的一種可視化仿真工具，自帶種類繁多、功能強大的模塊庫，被廣泛應用在系統(tǒng)建模、數(shù)據(jù)處理和業(yè)務仿真中。

仿真系統(tǒng)使用了多個關(guān)鍵組件，來實現(xiàn)過程業(yè)務仿真模塊與其他模塊的數(shù)據(jù)實時交互傳輸。

To Instrument 組件用于將Simulink 中的數(shù)據(jù)輸出到外界設備中，在仿真系統(tǒng)中用于模擬傳感器，將工業(yè)過程產(chǎn)生的各項實時數(shù)據(jù)發(fā)送到數(shù)據(jù)轉(zhuǎn)存模塊中的實時生產(chǎn)數(shù)據(jù)庫。如表3 第一部分所示，To Instrument 支持對通信協(xié)議、地址、端口、數(shù)據(jù)類型、緩沖區(qū)大小、傳輸間隔、傳輸格式等進行設置以滿足系統(tǒng)需求。

Query Instrument 組件用于在Simulink 中接收外界信號。在仿真系統(tǒng)中用于模擬系統(tǒng)總閥，控制系統(tǒng)緊急停車。如表3 第二部分所示，與To Instrument 組件類似，同樣需要進行相應預先設置。

Real-time sync 組件用于Simulink 中仿真系統(tǒng)的實時化處理，通過引入此組件，Simulink 系統(tǒng)的仿真運行速度會與外界物理時間保持一致（而不是在幾秒內(nèi)運行完畢全部仿真流程），從而模擬工業(yè)現(xiàn)場實時產(chǎn)生數(shù)據(jù)并接收控制的過程，使得整個PLC蜜罐系統(tǒng)的數(shù)據(jù)流轉(zhuǎn)更加真實。

表3 To Instrument和Query Instrument組件設置Tab.3 Settings of To Instrument and Query Instrument components

4 系統(tǒng)實現(xiàn)

本文構(gòu)建的高交互PLC 蜜罐系統(tǒng)以開源蜜罐Conpot 和Simulink 仿真器為基礎，基于S7comm 私有功能開發(fā)和工控業(yè)務仿真，采用信息服務仿真、數(shù)據(jù)轉(zhuǎn)存、過程控制仿真三模塊體系，通過模塊間的信息交換，實現(xiàn)了具備高交互性和高仿真度的PLC蜜罐系統(tǒng)。

4.1 過程控制仿真模塊

過程控制仿真模塊使用Matlab/Simulink 搭建了燃氣管網(wǎng)仿真系統(tǒng)。燃氣管網(wǎng)是一個由多過程組成的燃氣輸送控制系統(tǒng)，包括高壓、中高壓、低壓三部分，通過監(jiān)測并控制不同階段的壓強、流速、溫度保持穩(wěn)定預設值，最終輸出標準狀態(tài)的燃氣到用戶家中。

在Simulink中搭建的燃氣管網(wǎng)仿真系統(tǒng)架構(gòu)如圖5所示。

圖5 燃氣管網(wǎng)仿真系統(tǒng)架構(gòu)Fig.5 Simulation system architecture of gas pipe network

通過不同組件之間的相互協(xié)作，結(jié)合過程模擬、通信交互、實時仿真三種功能，最終實現(xiàn)了接收實時控制信號、輸出實時生產(chǎn)數(shù)據(jù)的功能。燃氣管網(wǎng)過程組件內(nèi)集成了燃氣管網(wǎng)系統(tǒng)生產(chǎn)過程仿真的諸多物理特性，包括高中低壓三部分傳遞函數(shù)構(gòu)建、干擾量模擬、開關(guān)選擇模擬等，當仿真系統(tǒng)運行正常時，該過程能夠產(chǎn)生7 個持續(xù)、實時輸出的數(shù)據(jù)流，分別為運行過程中不同的流量、溫度、壓強值。To Instrument 組件采集以上燃氣管網(wǎng)系統(tǒng)產(chǎn)生的數(shù)據(jù)，并通過TCP/IP 協(xié)議將其輸出到數(shù)據(jù)轉(zhuǎn)存模塊的實時生產(chǎn)數(shù)據(jù)庫中，實現(xiàn)了本模塊系統(tǒng)傳感器的功能。Query Instrument組件接收數(shù)據(jù)轉(zhuǎn)存模塊通過TCP/IP 協(xié)議發(fā)送的實時控制指令流，然后將其輸入到燃氣管網(wǎng)過程中，只要控制指令不變，運行狀態(tài)就不會變；一旦外部輸入的控制指令流發(fā)生變化，燃氣管網(wǎng)過程的運行狀態(tài)和輸出數(shù)據(jù)也會隨之變化，其實現(xiàn)的是本模塊系統(tǒng)總閥的功能。Real-time sync 組件負責整體系統(tǒng)的實時化，這使得該工業(yè)過程的仿真和通信行為都是實時進行的，符合蜜罐系統(tǒng)的設計要求。

4.2 數(shù)據(jù)轉(zhuǎn)存模塊

數(shù)據(jù)轉(zhuǎn)存模塊的腳本使用python3語言編寫，調(diào)用的核心庫是Socket和MySQL，通過搭建、操作數(shù)據(jù)庫并與其他模塊進行通信，實現(xiàn)了接收、存儲生產(chǎn)數(shù)據(jù)和調(diào)用、發(fā)送控制指令流的功能。

實時生產(chǎn)數(shù)據(jù)庫存儲著系統(tǒng)的實時生產(chǎn)數(shù)據(jù)，程序腳本會通過Socket 庫與過程控制仿真模塊的To Instrument 組件相連接，并接收其輸出的生產(chǎn)數(shù)據(jù)；然后經(jīng)過一定的格式化處理，通過SQL 語句將其存入數(shù)據(jù)庫內(nèi)。由于數(shù)據(jù)的產(chǎn)生和傳輸是實時的，因此實時生產(chǎn)數(shù)據(jù)庫中的數(shù)據(jù)是實時變化更新的最新數(shù)據(jù)。

實時控制數(shù)據(jù)庫存儲系統(tǒng)的實時控制指令。與實時更新數(shù)據(jù)的實時生產(chǎn)數(shù)據(jù)庫不同，實時控制數(shù)據(jù)庫的數(shù)據(jù)并非實時輸入，而是實時輸出。實時控制數(shù)據(jù)庫會使用Socket腳本，對過程控制仿真模塊中的Query Instrument 組件實時發(fā)送內(nèi)部存儲的數(shù)據(jù)作為控制指令，從而為工業(yè)過程提供了持續(xù)的閥門信號。

4.3 信息服務仿真模塊

在Ubuntu 系統(tǒng)內(nèi)以S7-300 模板部署二次開發(fā)后的Conpot 蜜罐，以此模擬西門子S7-300 PLC 與外界攻擊者進行通信，從而實現(xiàn)系統(tǒng)所需的信息服務。

在交互過程中，Conpot 的S7comm 服務器在執(zhí)行Read 功能碼對應的S7comm 私有服務時，預設的腳本函數(shù)會使用SQL語句讀取數(shù)據(jù)轉(zhuǎn)存模塊中的實時生產(chǎn)數(shù)據(jù)數(shù)據(jù)庫；同樣，在執(zhí)行Write功能碼對應的服務時，預設的腳本函數(shù)會使用SQL語句來將數(shù)據(jù)轉(zhuǎn)存模塊中實時控制數(shù)據(jù)庫的數(shù)覆蓋為新的數(shù)，從而控制過程控制仿真模塊。

5 實驗測試與分析

5.1 實驗環(huán)境

本文通過控制網(wǎng)仿真攻擊來測試高交互PLC蜜罐系統(tǒng)的連通性和工作邏輯。如表4 所示，實驗設備分為蜜罐設備和測試設備，通過以太網(wǎng)進行通信。高交互蜜罐系統(tǒng)部署在蜜罐設備內(nèi)，其中信息服務仿真模塊和數(shù)據(jù)轉(zhuǎn)存模塊位于虛擬機，過程控制仿真模塊位于宿主機。測試設備為同一IP 段內(nèi)的獨立計算機。

表4 實驗環(huán)境配置Tab.4 Configuration of experimental environment

5.2 控制網(wǎng)攻擊測試

控制網(wǎng)攻擊測試的主要目的是驗證蜜罐系統(tǒng)的信息域交互能力。將測試設備與蜜罐設備的以太網(wǎng)輸入端口相連，利用Nmap 探測腳本分別進行了設備操作系統(tǒng)指紋識別、系統(tǒng)探測。然后測試S7comm 私有服務實現(xiàn)情況，以“0x28 PLC start”為例，向蜜罐設備發(fā)送基于真實設備反饋信息的數(shù)據(jù)包，如圖6 所示，蜜罐系統(tǒng)能夠識別出數(shù)據(jù)包請求的S7comm私有服務為“28”并返回對應響應數(shù)據(jù)包。經(jīng)完整測試，蜜罐系統(tǒng)支持表1中列舉的全部11種S7comm私有服務。

圖6 蜜罐系統(tǒng)日志Fig.6 Log of honeypot system

5.3 業(yè)務邏輯測試

業(yè)務邏輯攻擊測試的主要目的是驗證蜜罐系統(tǒng)的物理域交互能力。在虛擬機內(nèi)以S7-300 模式部署定制版Conpot，運行信息服務仿真模塊主程序和數(shù)據(jù)轉(zhuǎn)存模塊中主程序，在宿主機中運行Simulink實時仿真，開始更新實時數(shù)據(jù)。

如圖7 所示，測試設備對蜜罐系統(tǒng)進行了完整測試來驗證其連接穩(wěn)定性和功能協(xié)同性。考慮到過程控制仿真模塊中信號的復雜多樣，以總閥（圖8）和管道壓強值PT2的全過程狀態(tài)（圖9）為例展示蜜罐系統(tǒng)中的運行狀態(tài)。

在716 s 前，過程控制仿真模塊持續(xù)正常運行。在此間，測試設備通過使用包含Read 功能碼的請求數(shù)據(jù)包Read_1 向蜜罐系統(tǒng)發(fā)起第一次通信，請求讀取PLC 的I 區(qū)實時數(shù)據(jù)，得到系統(tǒng)返回的響應數(shù)據(jù)包。響應數(shù)據(jù)包的實時數(shù)據(jù)來自過程控制仿真模塊，在數(shù)據(jù)轉(zhuǎn)存模塊模擬真實PLC 的I區(qū)7通道數(shù)據(jù)格式進行格式化組合，為28 位7 通道十六進制數(shù)“557931e12af52eec13dd2808244b”，這段正常I 區(qū)數(shù)據(jù)作為S7data攜帶的PLC的I區(qū)數(shù)據(jù)的一部分被組入響應數(shù)據(jù)包。

在716 s 時，測試設備使用包含Write 功能碼的數(shù)據(jù)包向蜜罐系統(tǒng)發(fā)起第二次通信，請求寫入控制指令，得到寫入成功的響應數(shù)據(jù)包，這表示攻擊者已成功劫持了PLC 輸出。此時數(shù)據(jù)轉(zhuǎn)存模塊發(fā)送出去的控制指令也隨攻擊指令發(fā)生了變化，可見圖8 中過程控制仿真模塊的總閥信號由0 階躍為1，閥門由開啟轉(zhuǎn)為關(guān)閉，過程控制仿真模塊的生產(chǎn)狀態(tài)立即發(fā)生變化，圖9 中PT2 輸出值發(fā)生突變，系統(tǒng)的正常運行遭到破壞，開始輸出失常的實時數(shù)據(jù)，直至仿真結(jié)束。

在716 s 后，再次使用包含Read 功能碼的數(shù)據(jù)包發(fā)起第三次通信，請求讀數(shù)據(jù)，得到過程控制仿真模塊生產(chǎn)癱瘓狀態(tài)下系統(tǒng)返回的響應數(shù)據(jù)包，此時接收到的數(shù)據(jù)已變?yōu)槭С區(qū)數(shù)據(jù)“00000000000000000000027c024e8”，可見其中末位2個通道值保持穩(wěn)定（溫度為室溫不變），其余過程量歸零，這表示系統(tǒng)傳感器輸出異常，攻擊者據(jù)此可知生產(chǎn)過程遭到了破壞。

圖7 高交互蜜罐系統(tǒng)測試流程Fig.7 Test process of high-interaction honeypot system

圖8 仿真期間總閥信號狀態(tài)圖Fig.8 Signal state diagram of main valve during simulation

圖9 仿真期間管道壓強PT2信號狀態(tài)圖Fig.9 Signal state diagram of pipe pressure PT2 during simulation

通過以上測試可知，本文設計的高交互PLC 蜜罐系統(tǒng)各模塊能穩(wěn)定工作，內(nèi)部連接和對外交互運轉(zhuǎn)正常，多次通信證實了蜜罐系統(tǒng)實現(xiàn)的不同S7comm 私有服務在迎合攻擊者的行為方面配合默契，邏輯嚴密，具備良好的協(xié)同性。其仿真工業(yè)過程提供的實時生產(chǎn)數(shù)據(jù)和可供破壞的生產(chǎn)環(huán)境形成的物理域交互循環(huán)對只接觸過信息域交互蜜罐的攻擊者來說更具誘騙性。綜上可得出結(jié)論，本文設計的高交互PLC 蜜罐系統(tǒng)達到了引言中提出的高交互的指標。相較于以往的中低交互工控蜜罐，本文所設計的PLC蜜罐系統(tǒng)具有顯著的突破性。

6 結(jié)語

蜜罐技術(shù)是對抗日益猖獗的互聯(lián)網(wǎng)威脅建立的防御手段，由于傳統(tǒng)工控蜜罐交互能力的局限和輸出信息的隨機化，不具備足夠的真實性和欺騙性。本文針對此問題，提出了一種結(jié)合工控業(yè)務仿真的高交互PLC蜜罐系統(tǒng)搭建方法。當攻擊者對基于工控業(yè)務仿真的高交互PLC 蜜罐系統(tǒng)進行攻擊時，其不僅能夠獲取到實時更新的生產(chǎn)數(shù)據(jù)，還能夠控制PLC蜜罐輸出對生產(chǎn)系統(tǒng)寫入數(shù)據(jù)來造成生產(chǎn)停車，完成邏輯閉環(huán)的蜜罐系統(tǒng)也因此具備更高的誘騙性。相較于傳統(tǒng)低交互、中交互蜜罐，本文提出的蜜罐系統(tǒng)發(fā)展了新的交互層次，在信息域交互的基礎上不僅拓展了物理域的業(yè)務邏輯支持，交互形式也更加立體、豐富、真實。

本文的研究目標集中于Simulink 仿真系統(tǒng)與定制Conpot蜜罐的數(shù)據(jù)交換框架、S7comm 私有功能的擴展和S7comm 協(xié)議數(shù)據(jù)包的字段解析上，沒有針對PLC程序的控制、解析進行研究，此外由于使用了預設的攻擊腳本，沒有進行廣泛的攻擊行為描述，這是未來研究的方向。