付 琳,邵培南,應 飛,解 維

(中國電子科技集團公司第三十二研究所,上海 201808)

0 概述

信息系統(tǒng)運行環(huán)境由網(wǎng)絡通信層、基礎層、應用支撐層和應用層組成,系統(tǒng)的運行可能受到來自軟硬件病毒、后門和漏洞的安全威脅攻擊[1]。例如對應用層HTTP協(xié)議的網(wǎng)頁篡改和SQL注入、對應用支撐層Web容器和分布式文件系統(tǒng)的后門和漏洞攻擊、對基礎層云容器、操作系統(tǒng)的后門和漏洞攻擊等[2]。以上攻擊行為可能會導致信息系統(tǒng)運行的功能異?；蚪K止,核心數(shù)據(jù)受到篡改、竊取或破壞[3]。

信息系統(tǒng)的安全防御技術分為被動安全防御和主動安全防御[4]。被動安全防御基于已知安全威脅特征規(guī)則的病毒、后門、漏洞等進行威脅診斷和清洗,如防火墻、病毒檢測、后門檢測等[5]。擬態(tài)防御理論由鄔江興院士提出,是一種以動態(tài)異構冗余(Dynamic Heterogeneous Redundancy,DHR)原理[6]為基礎的主動安全防御技術。

本文將DHR架構與擬態(tài)信息系統(tǒng)相結合,設計一種擬態(tài)通用運行環(huán)境(Mimic Common Operating Environment,MCOE)框架。MCOE以運行擬態(tài)信息系統(tǒng)的異構執(zhí)行體池為對象,提供N個異構執(zhí)行體部署、服務請求的分發(fā)、執(zhí)行、表決[7]、管理和安全威脅診斷[8]等運行支撐功能,用以保障安全威脅攻擊情景下服務請求的正確、可靠運行[9]。

1 信息系統(tǒng)擬態(tài)防御

信息系統(tǒng)的網(wǎng)絡通信層擬態(tài)防御主要基于擬態(tài)網(wǎng)絡通信產(chǎn)品來實施[10]。本文提及的信息系統(tǒng)的擬態(tài)防御,主要是針對基礎層、應用支撐層和應用層的擬態(tài)防御。通常,擬態(tài)信息系統(tǒng)的必要組成要素如下:

1)擬態(tài)化改造中功能等價的K(K≥1)個冗余異構應用程序源代碼。對系統(tǒng)應用程序源代碼的擬態(tài)化改造主要是增加標簽化的表決調(diào)用和表決前后的上下文處理。標簽化的表決調(diào)用指第三方API(如Oracle)參數(shù)、關鍵安全數(shù)據(jù)文件、庫表數(shù)據(jù)結構操作、指定程序點的內(nèi)在程序片段功能或內(nèi)存關鍵數(shù)據(jù)的一致性表決調(diào)用。對此部分數(shù)據(jù)的一致性表決主要通過防止關鍵文件、數(shù)據(jù)庫受到篡改確保關鍵功能正確執(zhí)行,實現(xiàn)細粒度的安全防御。對源代碼的擬態(tài)化改造具體分為如下3個部分:

(1)標簽化表決調(diào)用(包括標簽化API標識、表決主鍵、表決參數(shù)JSON字符串)和表決調(diào)用前后上下文程序段處理。

(2)標簽化第三方API的協(xié)同執(zhí)行調(diào)用,防止因服務請求并發(fā)執(zhí)行引起的N個異構執(zhí)行體API不一致。

(3)添加API鉤子函數(shù)和統(tǒng)一處理組件,用于識別利用后門和漏洞訪問的第三方API,如識別數(shù)據(jù)竊取的通信API或SQL語句。

2)異構軟硬件構造化或擬態(tài)軟件產(chǎn)品構建化的系統(tǒng)三層異構冗余的運行環(huán)境設施。例如:異構執(zhí)行體[11]基礎層操作系統(tǒng)、云容器、虛擬機的異構,應用支撐層Web容器的異構,應用層擬態(tài)存儲[12]等擬態(tài)產(chǎn)品的異構。

擬態(tài)信息系統(tǒng)的運行支撐環(huán)境為基于系統(tǒng)異構應用程序源代碼和運行環(huán)境設施形成的異構執(zhí)行體池,由基礎層A冗余異構、應用支撐層B冗余異構、應用層的K冗余異構形成具有M=A×B×K種異構執(zhí)行體的異構執(zhí)行體池。在受到安全威脅攻擊的情況下,系統(tǒng)運行支撐環(huán)境的異構性可確保系統(tǒng)正確可靠運行。

2 MCOE框架體系設計

MCOE實現(xiàn)面向服務請求的N個異構執(zhí)行體執(zhí)行過程的自動化,對服務請求進行入口、過程、結果三級安全防護,并且提供了集成化的分發(fā)和表決的接口規(guī)范[13]。

2.1 MCOE總體框架

MCOE是實現(xiàn)面向C/C++、Java語言開發(fā)的 C/S或B/S信息系統(tǒng)的擬態(tài)防御架構[14],為擬態(tài)信息系統(tǒng)提供了自動化的通用運行環(huán)境和擬態(tài)防御手段,其防御方法和目標如下:

1)通過N個異構執(zhí)行體運行節(jié)點軟硬件資源異構最大化的資源調(diào)度,主動防御特定軟硬件后門漏洞引起的安全威脅。

2)通過異構執(zhí)行體運行節(jié)點軟硬件資源和資源對象(如云容器、虛擬機)調(diào)度的隨機性和動態(tài)性最大化,及時阻斷由系統(tǒng)四層軟硬件發(fā)起的安全威脅攻擊。

3)通過服務請求執(zhí)行過程中N個異構執(zhí)行體內(nèi)部和服務請求響應結果的兩級表決,防止關鍵的文件、數(shù)據(jù)庫、內(nèi)存數(shù)據(jù)結構映像受到篡改,確保在受到安全威脅的情況下系統(tǒng)能夠正確運行。

MCOE總體框架如圖1所示,其中包括分發(fā)、內(nèi)部表決、外部表決、管理和協(xié)同5個服務器,以及部署在各個服務器上的節(jié)點代理服務進程。

服務請求主鍵為分發(fā)服務器接收到客戶端服務請求時創(chuàng)建的唯一標識,MOCE體系架構中的各個服務器通過服務請求主鍵進行關聯(lián)?？蛻舳朔照埱篁?qū)動的MCOE,其中各服務器間協(xié)同工作的運行場景如下:

1)分發(fā)服務器接收客戶端服務請求,按需進行已知特征安全威脅[15]識別和清洗,調(diào)用管理服務器的資源調(diào)度服務接口獲取相應服務請求,執(zhí)行所需的N個異構執(zhí)行體、內(nèi)部表決服務器和協(xié)同運行服務器的運行節(jié)點資源。

2)分發(fā)服務器發(fā)送包含服務請求主鍵和各個服務器運行節(jié)點資源(服務器、云容器或虛擬機對象資源)的文件給相應服務器的運行節(jié)點代理服務。

3)N個異構執(zhí)行體、內(nèi)部表決服務器和協(xié)同運行服務器的運行節(jié)點代理接收文件后,在相應系統(tǒng)配置文件中創(chuàng)建基于服務請求主鍵的待處理配置記錄,并向分發(fā)服務器返回應答。

4)分發(fā)服務器轉(zhuǎn)發(fā)服務請求到相應的N個異構執(zhí)行體服務器。

5)N個異構執(zhí)行體服務器執(zhí)行服務請求,當執(zhí)行到關鍵數(shù)據(jù)操作、重要功能模塊和標簽化的第三方API時,讀取待處理配置記錄中的內(nèi)部表決服務器地址,調(diào)用內(nèi)部表決服務器對表決內(nèi)容進行一致性表決,同時對未標簽化的API進行安全威脅診斷和處理。

6)內(nèi)部表決服務器對于表決異常的結果進行表決,對結果做魯棒性處理,上報異常到管理服務器,同時反饋內(nèi)部表決結果(一致Y/異常E)給相應異構執(zhí)行體。

7)內(nèi)部表決結果為Y的異構執(zhí)行體繼續(xù)執(zhí)行程序,對標簽化的第三方API調(diào)用協(xié)同執(zhí)行服務器進行后續(xù)處理。協(xié)同執(zhí)行服務器具體驅(qū)動第三方API的執(zhí)行,返回包含執(zhí)行結果參數(shù)的標簽化API給調(diào)用方的相應執(zhí)行體。

8)分發(fā)服務器接收和預處理N個異構執(zhí)行體服務請求的響應結果,調(diào)用管理服務器的資源調(diào)度服務接口獲取外部表決服務器地址,同時驅(qū)動該外部表決服務器執(zhí)行相應的表決。

9)外部表決服務器對于表決,對異常的結果進行表決,對結果做魯棒性處理,上報異常到管理服務器,同時反饋外部表決結果(一致Y/異常E) 給分發(fā)服務器。

10)分發(fā)服務器收到外部表決結果,若表決結果為一致,則返回正常的服務請求響應結果給客戶端;否則返回異常,由客戶端重新發(fā)起該請求。

在內(nèi)部表決和外部表決執(zhí)行過程中,表決結果為異常的異構執(zhí)行體節(jié)點資源和運行上下文均發(fā)給管理服務器。對于經(jīng)表決魯棒性處理后確定的異常,由表決服務器實時向管理服務器發(fā)出告警,管理服務器交互式地進行安全威脅診斷、清洗和恢復。

圖1 MCOE體系架構

2.2 MCOE各服務器程序處理框架設計

MCOE各個服務器及部署在服務器上的運行節(jié)點代理服務對服務請求的處理,遵循如圖2所示的主程序統(tǒng)一處理框架。

圖2 各服務器主程序處理框架

Fig.2Processing framework of main programs in eachserver

主程序統(tǒng)一處理框架分為初始化、主程序任務循環(huán)處理、服務請求通信和預處理線程、任務處理子線程4個部分。

1)初始化。進行服務請求處理任務隊列初始化,創(chuàng)建服務請求任務消息包的接收和預處理線程。

2)主程序任務循環(huán)處理。任務循環(huán)處理偽代碼如下:

Read隊列元素;

While(true){//循環(huán)處理

//P為預處理狀態(tài),在表決時隊列元素包括2N/3個表決//參數(shù)為滿足執(zhí)行條件

If(任務隊列元素狀態(tài)標志==“P” and 滿足執(zhí)行條件){

設置:任務隊列元素執(zhí)行標志=“E”;//E為執(zhí)行狀態(tài)

創(chuàng)建相應任務隊列元素的任務處理子線程;

Read Next任務隊列元素;

}ElseIf(任務隊列元素狀態(tài)標志==“C”){

//C為任務完成狀態(tài)

刪除該隊列元素;

Read 當前隊列元素;

}Else{//任務隊列元素狀態(tài)為未完成狀態(tài)

Read Next任務隊列元素;}}

3)服務請求通信和預處理線程。服務請求通信和預處理線程部分偽代碼如下:

該線程基于HTTP協(xié)議通信并發(fā)接收服務請求任務消息包;

解析服務請求任務消息包;

If 依賴于N(N≥3)個消息包處理的任務{(diào)

遍歷該任務隊列;

If(隊列元素的任務主鍵相同){

//構建N個任務參數(shù)JSON字符串數(shù)組

6）6—9月份，田間卵果率達到1%時，及時噴25%滅幼脲1 000倍液或2.5%溴氰菊酯乳油3 000倍液。

在該元素中添加該參數(shù)字符串JSON;

}Else{

創(chuàng)建新元素;}

}Else{//消息包獨立處理的任務

在任務隊列尾插入該任務元素;}

If(消息包為獨立處理的任務){

Read 隊列元素和預處理;

動態(tài)安裝和執(zhí)行相應的任務組件;

任務隊列元素執(zhí)行標志=“C”;

發(fā)送執(zhí)行結果到相應節(jié)點代理;

Break;

}ElseIf(消息包屬于統(tǒng)一處理的N個任務){

//N個消息包統(tǒng)一進行處理

Read 未處理的數(shù)據(jù)元素集;

If(未處理的數(shù)據(jù)元素集==Null){

//消息包未到達,等待時間閾值T

Sleep(XX us);

}Else{//讀到數(shù)據(jù)集

If(同步執(zhí)行 and 第1次執(zhí)行){

發(fā)送任務處理結果到消息源服務器;

保存任務處理結果;//例如協(xié)同執(zhí)行

}ElseIf(同步執(zhí)行 and 第2次～第N次執(zhí)行){

返回第1次保存的任務處理結果給源服務器;}

If(處理結果滿足任務節(jié)點提交條件 and 異步執(zhí)行){

發(fā)送處理結果到相應的消息源節(jié)點;}}}

//例如表決服務器,基于源節(jié)點運行代理服務實現(xiàn)交互

If(處理任務消息數(shù)==N){

//已完成本次任務處理

隊列任務處理狀態(tài)=“C”;

Break;

}ElseIf(處理任務消息數(shù)≠N and處理時間>閾值T){

調(diào)用管理服務進行異常處理;

Break;}

2.3 MCOE框架內(nèi)外部接口設計

MCOE框架內(nèi)外部接口設計基于以下3個方面:由分發(fā)服務器和管理服務器協(xié)同完成的服務請求預處理、資源調(diào)度和請求轉(zhuǎn)發(fā)過程;N異構執(zhí)行體驅(qū)動的表決和第三方API協(xié)同執(zhí)行過程;由分發(fā)器和外部表決器協(xié)同完成的響應結果表決過程和客戶端轉(zhuǎn)發(fā)過程。

MCOE服務器間接口遵循HTTP通信協(xié)議,接口定義為json格式文件,各服務器依據(jù)json庫函數(shù)進行解析預處理,如圖3所示。

圖3 MCOE服務器接口定義

分發(fā)服務相關的接口描述見表1,其中接口主要提供服務請求轉(zhuǎn)發(fā)、服務請求響應結果接收和外部表決所需參數(shù)。其中,通過管理服務提供的擬態(tài)資源調(diào)度接口調(diào)度出隨機性、動態(tài)性和異構性三性最大化的N異構執(zhí)行體服務器,為擬態(tài)防御提供異構化的基礎環(huán)境。異構執(zhí)行體相關的接口描述見表2,其中接口主要提供N異構執(zhí)行體運行過程中內(nèi)部表決和第三方API協(xié)同運行所需的參數(shù)。管理服務器相關接口描述見表3,其中接口基于“管理者+代理”方式實現(xiàn)。部署在各個服務器上的運行節(jié)點代理服務采集各個服務器的節(jié)點運行資源狀態(tài)和日志數(shù)據(jù),并將采集數(shù)據(jù)上報給運行管理服務,接收、處理運行管理服務下發(fā)的資源狀態(tài)監(jiān)管命令和節(jié)點清洗命令。

表1 分發(fā)服務相關接口描述Table 1 Description of interfaces related to MCOE distribution services

表2 N異構執(zhí)行體相關接口描述Table 2 Description of interfaces related to N heterogeneous executor

表3 管理服務器相關接口描述Table 3 Description of interfaces related to the management server

3 MCOE各模塊概要設計

MCOE各個功能模塊間的交互遵循HTTP通信協(xié)議,各模塊的功能實現(xiàn)均遵循2.2節(jié)中的程序統(tǒng)一處理框架。

3.1 分發(fā)服務概要設計

分發(fā)服務結合傳統(tǒng)安全防御對已知安全威脅的清洗提供了Web信息系統(tǒng)的入口級安全防御。分發(fā)服務提供客戶端服務請求的接收、對已知威脅的清洗[16]、N個冗余異構執(zhí)行體服務請求分發(fā)、請求響應結果的處理以及將請求響應結果轉(zhuǎn)發(fā)給客戶端等功能。如圖4所示,分發(fā)服務主要包括3個功能模塊:

1)請求預處理引擎。接收服務請求,定義服務請求主鍵服務請求安全威脅清洗;構建N個異構執(zhí)行體服務請求。

2)分發(fā)處理模塊。通過“擬態(tài)資源調(diào)度接口”獲取相應節(jié)點執(zhí)行資源;構建包含服務請求主鍵、內(nèi)部表決、協(xié)同執(zhí)行和N個異構執(zhí)行體服務器執(zhí)行資源的服務器地址文件,通過“服務請求主鍵和處理過程所需的服務器地址接口”下發(fā)到相應的服務器;通過“服務請求轉(zhuǎn)發(fā)接口”轉(zhuǎn)發(fā)服務請求到相應的N個構執(zhí)行體。

3)請求響應處理模塊。接收請求響應執(zhí)行結果;通過“擬態(tài)資源調(diào)度接口”獲取外部表決器執(zhí)行資源;構建包含服務請求主鍵、外部表決服務器執(zhí)行資源的服務器地址文件;基于此文件驅(qū)動外部表決的執(zhí)行;接收表決服務器的反饋結果,表決一致時將服務請求最終響應結果返回給客戶端,表決不一致時返回異常信息給管理服務。

圖4 分發(fā)服務功能組成示意圖

Fig.4Schematic diagram of function composition ofdistribution service

3.2 表決服務概要設計

表決服務包括內(nèi)部表決服務和外部表決服務,是MCOE最為關鍵的組成部分[17]。內(nèi)部表決服務提供了異構執(zhí)行體執(zhí)行過程中的安全防御,外部表決服務提供了異構執(zhí)行體執(zhí)行結果的安全防御。

如圖5所示,內(nèi)部表決服務主要包括4個功能模塊:

1)表決信息接收處理。通過“內(nèi)部表決調(diào)用接口”接收來自N個異構執(zhí)行體的內(nèi)部表決內(nèi)容,確定相應的表決組件。

2)表決執(zhí)行。對N個異構執(zhí)行體關鍵數(shù)據(jù)操作、重要功能模塊和第三方API參數(shù)進行一致性表決。

3)魯棒性處理。表決異常時,根據(jù)表決對象的魯棒性策略按需執(zhí)行魯棒性處理過程。

4)表決結果反饋。表決大多數(shù)一致時,將表決結果返回給正常的N個異構執(zhí)行體,若存在不一致的異構執(zhí)行體調(diào)用管理服務進行異常處理。表決不一致調(diào)用管理服務進行異常處理。

圖5 內(nèi)部表決服務功能組成示意圖

Fig.5Schematic diagram of function composition ofinternal voting service

外部表決服務中大部分功能模塊與內(nèi)部表決服務相同,不同之處在于外部表決是對N個服務請求響應的一致性表決,通過分發(fā)服務和外部表決服務之間的交互完成。

3.3 協(xié)同執(zhí)行服務概要設計

協(xié)同執(zhí)行服務具體驅(qū)動第三方API的執(zhí)行,確保N個異構執(zhí)行體API執(zhí)行結果的一致性,并提供執(zhí)行協(xié)同統(tǒng)一框架以支持協(xié)同執(zhí)行種類的擴展和配置。當對N個異構執(zhí)行體內(nèi)的第三方API內(nèi)部表決結果為一致時,N個異構執(zhí)行體通過異步方式調(diào)用協(xié)同執(zhí)行服務器進行第三方API的統(tǒng)一執(zhí)行。當接收到第1個協(xié)同執(zhí)行調(diào)用時,完成對第三方API的協(xié)同執(zhí)行、將執(zhí)行結果返回給相應的執(zhí)行體,并保存執(zhí)行結果;當收到第2個～第N個執(zhí)行體的協(xié)同執(zhí)行調(diào)用時,將保存的協(xié)同執(zhí)行結果返回給相應的執(zhí)行體。

3.4 管理服務概要設計

管理服務包括管理服務器和運行節(jié)點服務管理者和管理者服務代理,其中主要的功能模塊如圖6所示。

圖6 管理服務功能組成示意圖

Fig.6Schematic diagram of function composition ofmanagement service

管理服務器主要包括3個功能模塊:

1)擬態(tài)應用管理模塊。創(chuàng)建和部署擬態(tài)應用、匯總和處理節(jié)點上報應用資源狀態(tài)日志信息、監(jiān)管擬態(tài)應用執(zhí)行過程。

2)擬態(tài)資源管理模塊。包括擬態(tài)資源監(jiān)控、異構執(zhí)行體調(diào)度和表決服務器資源調(diào)度。

3)擬態(tài)安全威脅診斷模塊。包括擬態(tài)運行過程管理、告警和環(huán)境日志信息處理、安全威脅的清洗策略執(zhí)行。

運行節(jié)點代理服務完成服務器節(jié)點資源狀態(tài)信息的采集,并將其上報給管理服務器,并且執(zhí)行管理服務器下發(fā)的管理命令。

4 模型實現(xiàn)

基于對示例應用程序ybsapp.war的MCOE模型實現(xiàn)包括3個部分:1)異構執(zhí)行體管理和資源調(diào)度;2)分發(fā)服務對各個異構執(zhí)行體進行服務請求分發(fā);3)對各個異構體上的請求響應結果進行外部表決并將結果反饋管理服務。

4.1 管理過程

首先在異構執(zhí)行體的基礎層(CPU類型和操作系統(tǒng)類型)和應用支撐層(Web容器)上實現(xiàn)異構。管理服務使用MySQL實現(xiàn)對異構執(zhí)行體節(jié)點和資源的管理。異構執(zhí)行體節(jié)點狀態(tài)示例如圖7所示,模型實現(xiàn)階段實際部署4個異構執(zhí)行體應用服務器,本文實驗中執(zhí)行體1～執(zhí)行體4所用Web容器分別為Jboss、Tomcat8.0、Tomcat8.5、Tomcat9.0。

圖7 異構執(zhí)行體節(jié)點狀態(tài)示例

異構執(zhí)行體上的運行節(jié)點代理服務將異構執(zhí)行體狀態(tài)信息實時上報到管理服務器,管理服務器實時判定執(zhí)行體運行狀態(tài)是否正常。

4.2 分發(fā)過程

分發(fā)服務通過改造Nginx反向代理服務[18],以及對Nginx主請求-子請求機制與Proxy反向代理機制的改進,實現(xiàn)服務請求的異構化、服務請求的轉(zhuǎn)發(fā)、外部表決服務的調(diào)用,并將外部表決結果返回給客戶端。

客戶端(192.168.2.7:8080)發(fā)起示例應用ybsapp服務請求,分發(fā)服務向管理服務發(fā)出資源調(diào)度請求,管理服務通過異構最大化調(diào)度[19]和負載均衡算法[20]調(diào)度出此次執(zhí)行服務請求的3個異構執(zhí)行體和外部表決地址,分發(fā)服務通過“擬態(tài)資源調(diào)度接口”獲取相應節(jié)點執(zhí)行資源,再由分發(fā)服務構建包含服務請求主鍵、異構執(zhí)行體和表決服務器節(jié)點資源的地址文件,如圖8所示。

圖8 服務請求執(zhí)行資源分配profile示例

Fig.8 Example profile of a service request for resourceallocation

各個服務器間通過服務請求主鍵進行關聯(lián),分發(fā)服務通過Nginx轉(zhuǎn)發(fā)地址文件到相應的N個異構執(zhí)行體和外部表決服務器,同時轉(zhuǎn)發(fā)服務請求到相應的異構執(zhí)行體上的服務請求轉(zhuǎn)發(fā)接口,如圖9所示。

圖9 分發(fā)服務Nginx轉(zhuǎn)發(fā)過程示例

Fig.9Example of forwarding process of distribution serviceNginx

圖9所示分發(fā)的是一個示例Web應用ybs,經(jīng)過分發(fā)服務Nginx將異構化的服務請求分發(fā)到3個異構執(zhí)行體(執(zhí)行體1:192.168.2.28、執(zhí)行體2:192.168.2.75、執(zhí)行體3:192.168.2.32)上,同時調(diào)用外部表決服務器:192.168.2.36進行服務請求響應表決。

4.3 表決過程

外部表決服務基于擬態(tài)表決策略,采用一致性校驗算法對服務請求響應進行一致性表決[21]。本文實驗的擬態(tài)表決策略采用三取二表決,即2/3表決對象一致時表決結果為正常,其他情況表決結果為異常。

外部表決成功后的反饋結果如圖10所示,異構執(zhí)行體1～執(zhí)行體4初始的表決成功次數(shù)均為0,對異構執(zhí)行體1～執(zhí)行體3執(zhí)行服務請求表決,表決結果為成功(執(zhí)行體1～執(zhí)行體3表決對象一致),執(zhí)行體1～執(zhí)行體3的表決成功加1,而執(zhí)行體4作為備用執(zhí)行體不參與表決,其表決成功次數(shù)仍為0。表決成功后將返回表決結果給分發(fā)服務,再由分發(fā)服務將服務請求響應返回給客戶端。

圖10 表決成功后部署情況示例

外部表決成功后將最終的服務請求響應結果返回給客戶端,客戶端得到的響應頁面如圖11所示。

圖11 客戶端響應頁面1

對異構執(zhí)行體進行網(wǎng)頁篡改攻擊后,同樣進行服務請求分發(fā),表決結果如圖12所示,執(zhí)行體2被表決為異常,但由于異構執(zhí)行體互相之間的異構性,使得網(wǎng)頁篡改對執(zhí)行體1和執(zhí)行體3并未生效,此次表決結果仍為成功。

圖12 篡改攻擊、表決后部署情況示例

Fig.12 Example of deployment results after voting for tamper attacks

外部表決服務返回表決結果和異常執(zhí)行體地址信息給分發(fā)服務,分發(fā)服務將服務請求響應返回給客戶端,客戶端得到的響應頁面如圖13所示,仍為正常的服務請求響應頁面。分發(fā)服務將異常執(zhí)行體地址信息上報至管理服務,由管理服務調(diào)用管理者服務代理進行異常異構執(zhí)行體替換和清洗恢復。

圖13 客戶端響應頁面2

經(jīng)過實驗驗證,由于異構執(zhí)行體本身的異構性,當出現(xiàn)系統(tǒng)安全攻擊時至多導致一個異構執(zhí)行體出現(xiàn)異常,而基于3取2表決并不會影響最終返回給客戶端的服務請求響應結果。MCOE對于異構執(zhí)行體的部署和服務請求的分發(fā)、表決、管理可以達到防止網(wǎng)頁篡改的目的,保證返回給客戶端正確的服務請求響應。

5 結束語

本文結合擬態(tài)防御理論,為擬態(tài)信息系統(tǒng)的N異構執(zhí)行體設計系統(tǒng)化的運行環(huán)境框架MCOE。通過改進Nginx反向代理服務實現(xiàn)對服務請求分發(fā)和響應結果的處理,同時使用一致性校驗算法進行服務請求響應結果表決,有效防御應用程序后門和漏洞引發(fā)的網(wǎng)頁篡改行為。下一步將對分發(fā)服務和表決服務進行改進,提升MCOE框架使用場景的普適性。