付 琳,邵培南,應(yīng) 飛,解 維
(中國電子科技集團公司第三十二研究所,上海 201808)
信息系統(tǒng)運行環(huán)境由網(wǎng)絡(luò)通信層、基礎(chǔ)層、應(yīng)用支撐層和應(yīng)用層組成,系統(tǒng)的運行可能受到來自軟硬件病毒、后門和漏洞的安全威脅攻擊[1]。例如對應(yīng)用層HTTP協(xié)議的網(wǎng)頁篡改和SQL注入、對應(yīng)用支撐層Web容器和分布式文件系統(tǒng)的后門和漏洞攻擊、對基礎(chǔ)層云容器、操作系統(tǒng)的后門和漏洞攻擊等[2]。以上攻擊行為可能會導(dǎo)致信息系統(tǒng)運行的功能異?;蚪K止,核心數(shù)據(jù)受到篡改、竊取或破壞[3]。
信息系統(tǒng)的安全防御技術(shù)分為被動安全防御和主動安全防御[4]。被動安全防御基于已知安全威脅特征規(guī)則的病毒、后門、漏洞等進行威脅診斷和清洗,如防火墻、病毒檢測、后門檢測等[5]。擬態(tài)防御理論由鄔江興院士提出,是一種以動態(tài)異構(gòu)冗余(Dynamic Heterogeneous Redundancy,DHR)原理[6]為基礎(chǔ)的主動安全防御技術(shù)。
本文將DHR架構(gòu)與擬態(tài)信息系統(tǒng)相結(jié)合,設(shè)計一種擬態(tài)通用運行環(huán)境(Mimic Common Operating Environment,MCOE)框架。MCOE以運行擬態(tài)信息系統(tǒng)的異構(gòu)執(zhí)行體池為對象,提供N個異構(gòu)執(zhí)行體部署、服務(wù)請求的分發(fā)、執(zhí)行、表決[7]、管理和安全威脅診斷[8]等運行支撐功能,用以保障安全威脅攻擊情景下服務(wù)請求的正確、可靠運行[9]。
信息系統(tǒng)的網(wǎng)絡(luò)通信層擬態(tài)防御主要基于擬態(tài)網(wǎng)絡(luò)通信產(chǎn)品來實施[10]。本文提及的信息系統(tǒng)的擬態(tài)防御,主要是針對基礎(chǔ)層、應(yīng)用支撐層和應(yīng)用層的擬態(tài)防御。通常,擬態(tài)信息系統(tǒng)的必要組成要素如下:
1)擬態(tài)化改造中功能等價的K(K≥1)個冗余異構(gòu)應(yīng)用程序源代碼。對系統(tǒng)應(yīng)用程序源代碼的擬態(tài)化改造主要是增加標(biāo)簽化的表決調(diào)用和表決前后的上下文處理。標(biāo)簽化的表決調(diào)用指第三方API(如Oracle)參數(shù)、關(guān)鍵安全數(shù)據(jù)文件、庫表數(shù)據(jù)結(jié)構(gòu)操作、指定程序點的內(nèi)在程序片段功能或內(nèi)存關(guān)鍵數(shù)據(jù)的一致性表決調(diào)用。對此部分?jǐn)?shù)據(jù)的一致性表決主要通過防止關(guān)鍵文件、數(shù)據(jù)庫受到篡改確保關(guān)鍵功能正確執(zhí)行,實現(xiàn)細(xì)粒度的安全防御。對源代碼的擬態(tài)化改造具體分為如下3個部分:
(1)標(biāo)簽化表決調(diào)用(包括標(biāo)簽化API標(biāo)識、表決主鍵、表決參數(shù)JSON字符串)和表決調(diào)用前后上下文程序段處理。
(2)標(biāo)簽化第三方API的協(xié)同執(zhí)行調(diào)用,防止因服務(wù)請求并發(fā)執(zhí)行引起的N個異構(gòu)執(zhí)行體API不一致。
(3)添加API鉤子函數(shù)和統(tǒng)一處理組件,用于識別利用后門和漏洞訪問的第三方API,如識別數(shù)據(jù)竊取的通信API或SQL語句。
2)異構(gòu)軟硬件構(gòu)造化或擬態(tài)軟件產(chǎn)品構(gòu)建化的系統(tǒng)三層異構(gòu)冗余的運行環(huán)境設(shè)施。例如:異構(gòu)執(zhí)行體[11]基礎(chǔ)層操作系統(tǒng)、云容器、虛擬機的異構(gòu),應(yīng)用支撐層Web容器的異構(gòu),應(yīng)用層擬態(tài)存儲[12]等擬態(tài)產(chǎn)品的異構(gòu)。
擬態(tài)信息系統(tǒng)的運行支撐環(huán)境為基于系統(tǒng)異構(gòu)應(yīng)用程序源代碼和運行環(huán)境設(shè)施形成的異構(gòu)執(zhí)行體池,由基礎(chǔ)層A冗余異構(gòu)、應(yīng)用支撐層B冗余異構(gòu)、應(yīng)用層的K冗余異構(gòu)形成具有M=A×B×K種異構(gòu)執(zhí)行體的異構(gòu)執(zhí)行體池。在受到安全威脅攻擊的情況下,系統(tǒng)運行支撐環(huán)境的異構(gòu)性可確保系統(tǒng)正確可靠運行。
MCOE實現(xiàn)面向服務(wù)請求的N個異構(gòu)執(zhí)行體執(zhí)行過程的自動化,對服務(wù)請求進行入口、過程、結(jié)果三級安全防護,并且提供了集成化的分發(fā)和表決的接口規(guī)范[13]。
MCOE是實現(xiàn)面向C/C++、Java語言開發(fā)的 C/S或B/S信息系統(tǒng)的擬態(tài)防御架構(gòu)[14],為擬態(tài)信息系統(tǒng)提供了自動化的通用運行環(huán)境和擬態(tài)防御手段,其防御方法和目標(biāo)如下:
1)通過N個異構(gòu)執(zhí)行體運行節(jié)點軟硬件資源異構(gòu)最大化的資源調(diào)度,主動防御特定軟硬件后門漏洞引起的安全威脅。
2)通過異構(gòu)執(zhí)行體運行節(jié)點軟硬件資源和資源對象(如云容器、虛擬機)調(diào)度的隨機性和動態(tài)性最大化,及時阻斷由系統(tǒng)四層軟硬件發(fā)起的安全威脅攻擊。
3)通過服務(wù)請求執(zhí)行過程中N個異構(gòu)執(zhí)行體內(nèi)部和服務(wù)請求響應(yīng)結(jié)果的兩級表決,防止關(guān)鍵的文件、數(shù)據(jù)庫、內(nèi)存數(shù)據(jù)結(jié)構(gòu)映像受到篡改,確保在受到安全威脅的情況下系統(tǒng)能夠正確運行。
MCOE總體框架如圖1所示,其中包括分發(fā)、內(nèi)部表決、外部表決、管理和協(xié)同5個服務(wù)器,以及部署在各個服務(wù)器上的節(jié)點代理服務(wù)進程。
服務(wù)請求主鍵為分發(fā)服務(wù)器接收到客戶端服務(wù)請求時創(chuàng)建的唯一標(biāo)識,MOCE體系架構(gòu)中的各個服務(wù)器通過服務(wù)請求主鍵進行關(guān)聯(lián)??蛻舳朔?wù)請求驅(qū)動的MCOE,其中各服務(wù)器間協(xié)同工作的運行場景如下:
1)分發(fā)服務(wù)器接收客戶端服務(wù)請求,按需進行已知特征安全威脅[15]識別和清洗,調(diào)用管理服務(wù)器的資源調(diào)度服務(wù)接口獲取相應(yīng)服務(wù)請求,執(zhí)行所需的N個異構(gòu)執(zhí)行體、內(nèi)部表決服務(wù)器和協(xié)同運行服務(wù)器的運行節(jié)點資源。
2)分發(fā)服務(wù)器發(fā)送包含服務(wù)請求主鍵和各個服務(wù)器運行節(jié)點資源(服務(wù)器、云容器或虛擬機對象資源)的文件給相應(yīng)服務(wù)器的運行節(jié)點代理服務(wù)。
3)N個異構(gòu)執(zhí)行體、內(nèi)部表決服務(wù)器和協(xié)同運行服務(wù)器的運行節(jié)點代理接收文件后,在相應(yīng)系統(tǒng)配置文件中創(chuàng)建基于服務(wù)請求主鍵的待處理配置記錄,并向分發(fā)服務(wù)器返回應(yīng)答。
4)分發(fā)服務(wù)器轉(zhuǎn)發(fā)服務(wù)請求到相應(yīng)的N個異構(gòu)執(zhí)行體服務(wù)器。
5)N個異構(gòu)執(zhí)行體服務(wù)器執(zhí)行服務(wù)請求,當(dāng)執(zhí)行到關(guān)鍵數(shù)據(jù)操作、重要功能模塊和標(biāo)簽化的第三方API時,讀取待處理配置記錄中的內(nèi)部表決服務(wù)器地址,調(diào)用內(nèi)部表決服務(wù)器對表決內(nèi)容進行一致性表決,同時對未標(biāo)簽化的API進行安全威脅診斷和處理。
6)內(nèi)部表決服務(wù)器對于表決異常的結(jié)果進行表決,對結(jié)果做魯棒性處理,上報異常到管理服務(wù)器,同時反饋內(nèi)部表決結(jié)果(一致Y/異常E)給相應(yīng)異構(gòu)執(zhí)行體。
7)內(nèi)部表決結(jié)果為Y的異構(gòu)執(zhí)行體繼續(xù)執(zhí)行程序,對標(biāo)簽化的第三方API調(diào)用協(xié)同執(zhí)行服務(wù)器進行后續(xù)處理。協(xié)同執(zhí)行服務(wù)器具體驅(qū)動第三方API的執(zhí)行,返回包含執(zhí)行結(jié)果參數(shù)的標(biāo)簽化API給調(diào)用方的相應(yīng)執(zhí)行體。
8)分發(fā)服務(wù)器接收和預(yù)處理N個異構(gòu)執(zhí)行體服務(wù)請求的響應(yīng)結(jié)果,調(diào)用管理服務(wù)器的資源調(diào)度服務(wù)接口獲取外部表決服務(wù)器地址,同時驅(qū)動該外部表決服務(wù)器執(zhí)行相應(yīng)的表決。
9)外部表決服務(wù)器對于表決,對異常的結(jié)果進行表決,對結(jié)果做魯棒性處理,上報異常到管理服務(wù)器,同時反饋外部表決結(jié)果(一致Y/異常E) 給分發(fā)服務(wù)器。
10)分發(fā)服務(wù)器收到外部表決結(jié)果,若表決結(jié)果為一致,則返回正常的服務(wù)請求響應(yīng)結(jié)果給客戶端;否則返回異常,由客戶端重新發(fā)起該請求。
在內(nèi)部表決和外部表決執(zhí)行過程中,表決結(jié)果為異常的異構(gòu)執(zhí)行體節(jié)點資源和運行上下文均發(fā)給管理服務(wù)器。對于經(jīng)表決魯棒性處理后確定的異常,由表決服務(wù)器實時向管理服務(wù)器發(fā)出告警,管理服務(wù)器交互式地進行安全威脅診斷、清洗和恢復(fù)。
圖1 MCOE體系架構(gòu)
MCOE各個服務(wù)器及部署在服務(wù)器上的運行節(jié)點代理服務(wù)對服務(wù)請求的處理,遵循如圖2所示的主程序統(tǒng)一處理框架。
圖2 各服務(wù)器主程序處理框架
Fig.2Processing framework of main programs in eachserver
主程序統(tǒng)一處理框架分為初始化、主程序任務(wù)循環(huán)處理、服務(wù)請求通信和預(yù)處理線程、任務(wù)處理子線程4個部分。
1)初始化。進行服務(wù)請求處理任務(wù)隊列初始化,創(chuàng)建服務(wù)請求任務(wù)消息包的接收和預(yù)處理線程。
2)主程序任務(wù)循環(huán)處理。任務(wù)循環(huán)處理偽代碼如下:
Read隊列元素;
While(true){//循環(huán)處理
//P為預(yù)處理狀態(tài),在表決時隊列元素包括2N/3個表決//參數(shù)為滿足執(zhí)行條件
If(任務(wù)隊列元素狀態(tài)標(biāo)志==“P” and 滿足執(zhí)行條件){
設(shè)置:任務(wù)隊列元素執(zhí)行標(biāo)志=“E”;//E為執(zhí)行狀態(tài)
創(chuàng)建相應(yīng)任務(wù)隊列元素的任務(wù)處理子線程;
Read Next任務(wù)隊列元素;
}ElseIf(任務(wù)隊列元素狀態(tài)標(biāo)志==“C”){
//C為任務(wù)完成狀態(tài)
刪除該隊列元素;
Read 當(dāng)前隊列元素;
}Else{//任務(wù)隊列元素狀態(tài)為未完成狀態(tài)
Read Next任務(wù)隊列元素;}}
3)服務(wù)請求通信和預(yù)處理線程。服務(wù)請求通信和預(yù)處理線程部分偽代碼如下:
該線程基于HTTP協(xié)議通信并發(fā)接收服務(wù)請求任務(wù)消息包;
解析服務(wù)請求任務(wù)消息包;
If 依賴于N(N≥3)個消息包處理的任務(wù){(diào)
遍歷該任務(wù)隊列;
If(隊列元素的任務(wù)主鍵相同){
//構(gòu)建N個任務(wù)參數(shù)JSON字符串?dāng)?shù)組
6)6—9月份,田間卵果率達(dá)到1%時,及時噴25%滅幼脲1 000倍液或2.5%溴氰菊酯乳油3 000倍液。
在該元素中添加該參數(shù)字符串JSON;
}Else{
創(chuàng)建新元素;}
}Else{//消息包獨立處理的任務(wù)
在任務(wù)隊列尾插入該任務(wù)元素;}
If(消息包為獨立處理的任務(wù)){
Read 隊列元素和預(yù)處理;
動態(tài)安裝和執(zhí)行相應(yīng)的任務(wù)組件;
任務(wù)隊列元素執(zhí)行標(biāo)志=“C”;
發(fā)送執(zhí)行結(jié)果到相應(yīng)節(jié)點代理;
Break;
}ElseIf(消息包屬于統(tǒng)一處理的N個任務(wù)){
//N個消息包統(tǒng)一進行處理
Read 未處理的數(shù)據(jù)元素集;
If(未處理的數(shù)據(jù)元素集==Null){
//消息包未到達(dá),等待時間閾值T
Sleep(XX us);
}Else{//讀到數(shù)據(jù)集
If(同步執(zhí)行 and 第1次執(zhí)行){
發(fā)送任務(wù)處理結(jié)果到消息源服務(wù)器;
保存任務(wù)處理結(jié)果;//例如協(xié)同執(zhí)行
}ElseIf(同步執(zhí)行 and 第2次~第N次執(zhí)行){
返回第1次保存的任務(wù)處理結(jié)果給源服務(wù)器;}
If(處理結(jié)果滿足任務(wù)節(jié)點提交條件 and 異步執(zhí)行){
發(fā)送處理結(jié)果到相應(yīng)的消息源節(jié)點;}}}
//例如表決服務(wù)器,基于源節(jié)點運行代理服務(wù)實現(xiàn)交互
If(處理任務(wù)消息數(shù)==N){
//已完成本次任務(wù)處理
隊列任務(wù)處理狀態(tài)=“C”;
Break;
}ElseIf(處理任務(wù)消息數(shù)≠N and處理時間>閾值T){
調(diào)用管理服務(wù)進行異常處理;
Break;}
MCOE框架內(nèi)外部接口設(shè)計基于以下3個方面:由分發(fā)服務(wù)器和管理服務(wù)器協(xié)同完成的服務(wù)請求預(yù)處理、資源調(diào)度和請求轉(zhuǎn)發(fā)過程;N異構(gòu)執(zhí)行體驅(qū)動的表決和第三方API協(xié)同執(zhí)行過程;由分發(fā)器和外部表決器協(xié)同完成的響應(yīng)結(jié)果表決過程和客戶端轉(zhuǎn)發(fā)過程。
MCOE服務(wù)器間接口遵循HTTP通信協(xié)議,接口定義為json格式文件,各服務(wù)器依據(jù)json庫函數(shù)進行解析預(yù)處理,如圖3所示。
圖3 MCOE服務(wù)器接口定義
分發(fā)服務(wù)相關(guān)的接口描述見表1,其中接口主要提供服務(wù)請求轉(zhuǎn)發(fā)、服務(wù)請求響應(yīng)結(jié)果接收和外部表決所需參數(shù)。其中,通過管理服務(wù)提供的擬態(tài)資源調(diào)度接口調(diào)度出隨機性、動態(tài)性和異構(gòu)性三性最大化的N異構(gòu)執(zhí)行體服務(wù)器,為擬態(tài)防御提供異構(gòu)化的基礎(chǔ)環(huán)境。異構(gòu)執(zhí)行體相關(guān)的接口描述見表2,其中接口主要提供N異構(gòu)執(zhí)行體運行過程中內(nèi)部表決和第三方API協(xié)同運行所需的參數(shù)。管理服務(wù)器相關(guān)接口描述見表3,其中接口基于“管理者+代理”方式實現(xiàn)。部署在各個服務(wù)器上的運行節(jié)點代理服務(wù)采集各個服務(wù)器的節(jié)點運行資源狀態(tài)和日志數(shù)據(jù),并將采集數(shù)據(jù)上報給運行管理服務(wù),接收、處理運行管理服務(wù)下發(fā)的資源狀態(tài)監(jiān)管命令和節(jié)點清洗命令。
表1 分發(fā)服務(wù)相關(guān)接口描述Table 1 Description of interfaces related to MCOE distribution services
表2 N異構(gòu)執(zhí)行體相關(guān)接口描述Table 2 Description of interfaces related to N heterogeneous executor
表3 管理服務(wù)器相關(guān)接口描述Table 3 Description of interfaces related to the management server
MCOE各個功能模塊間的交互遵循HTTP通信協(xié)議,各模塊的功能實現(xiàn)均遵循2.2節(jié)中的程序統(tǒng)一處理框架。
分發(fā)服務(wù)結(jié)合傳統(tǒng)安全防御對已知安全威脅的清洗提供了Web信息系統(tǒng)的入口級安全防御。分發(fā)服務(wù)提供客戶端服務(wù)請求的接收、對已知威脅的清洗[16]、N個冗余異構(gòu)執(zhí)行體服務(wù)請求分發(fā)、請求響應(yīng)結(jié)果的處理以及將請求響應(yīng)結(jié)果轉(zhuǎn)發(fā)給客戶端等功能。如圖4所示,分發(fā)服務(wù)主要包括3個功能模塊:
1)請求預(yù)處理引擎。接收服務(wù)請求,定義服務(wù)請求主鍵服務(wù)請求安全威脅清洗;構(gòu)建N個異構(gòu)執(zhí)行體服務(wù)請求。
2)分發(fā)處理模塊。通過“擬態(tài)資源調(diào)度接口”獲取相應(yīng)節(jié)點執(zhí)行資源;構(gòu)建包含服務(wù)請求主鍵、內(nèi)部表決、協(xié)同執(zhí)行和N個異構(gòu)執(zhí)行體服務(wù)器執(zhí)行資源的服務(wù)器地址文件,通過“服務(wù)請求主鍵和處理過程所需的服務(wù)器地址接口”下發(fā)到相應(yīng)的服務(wù)器;通過“服務(wù)請求轉(zhuǎn)發(fā)接口”轉(zhuǎn)發(fā)服務(wù)請求到相應(yīng)的N個構(gòu)執(zhí)行體。
3)請求響應(yīng)處理模塊。接收請求響應(yīng)執(zhí)行結(jié)果;通過“擬態(tài)資源調(diào)度接口”獲取外部表決器執(zhí)行資源;構(gòu)建包含服務(wù)請求主鍵、外部表決服務(wù)器執(zhí)行資源的服務(wù)器地址文件;基于此文件驅(qū)動外部表決的執(zhí)行;接收表決服務(wù)器的反饋結(jié)果,表決一致時將服務(wù)請求最終響應(yīng)結(jié)果返回給客戶端,表決不一致時返回異常信息給管理服務(wù)。
圖4 分發(fā)服務(wù)功能組成示意圖
Fig.4Schematic diagram of function composition ofdistribution service
表決服務(wù)包括內(nèi)部表決服務(wù)和外部表決服務(wù),是MCOE最為關(guān)鍵的組成部分[17]。內(nèi)部表決服務(wù)提供了異構(gòu)執(zhí)行體執(zhí)行過程中的安全防御,外部表決服務(wù)提供了異構(gòu)執(zhí)行體執(zhí)行結(jié)果的安全防御。
如圖5所示,內(nèi)部表決服務(wù)主要包括4個功能模塊:
1)表決信息接收處理。通過“內(nèi)部表決調(diào)用接口”接收來自N個異構(gòu)執(zhí)行體的內(nèi)部表決內(nèi)容,確定相應(yīng)的表決組件。
2)表決執(zhí)行。對N個異構(gòu)執(zhí)行體關(guān)鍵數(shù)據(jù)操作、重要功能模塊和第三方API參數(shù)進行一致性表決。
3)魯棒性處理。表決異常時,根據(jù)表決對象的魯棒性策略按需執(zhí)行魯棒性處理過程。
4)表決結(jié)果反饋。表決大多數(shù)一致時,將表決結(jié)果返回給正常的N個異構(gòu)執(zhí)行體,若存在不一致的異構(gòu)執(zhí)行體調(diào)用管理服務(wù)進行異常處理。表決不一致調(diào)用管理服務(wù)進行異常處理。
圖5 內(nèi)部表決服務(wù)功能組成示意圖
Fig.5Schematic diagram of function composition ofinternal voting service
外部表決服務(wù)中大部分功能模塊與內(nèi)部表決服務(wù)相同,不同之處在于外部表決是對N個服務(wù)請求響應(yīng)的一致性表決,通過分發(fā)服務(wù)和外部表決服務(wù)之間的交互完成。
協(xié)同執(zhí)行服務(wù)具體驅(qū)動第三方API的執(zhí)行,確保N個異構(gòu)執(zhí)行體API執(zhí)行結(jié)果的一致性,并提供執(zhí)行協(xié)同統(tǒng)一框架以支持協(xié)同執(zhí)行種類的擴展和配置。當(dāng)對N個異構(gòu)執(zhí)行體內(nèi)的第三方API內(nèi)部表決結(jié)果為一致時,N個異構(gòu)執(zhí)行體通過異步方式調(diào)用協(xié)同執(zhí)行服務(wù)器進行第三方API的統(tǒng)一執(zhí)行。當(dāng)接收到第1個協(xié)同執(zhí)行調(diào)用時,完成對第三方API的協(xié)同執(zhí)行、將執(zhí)行結(jié)果返回給相應(yīng)的執(zhí)行體,并保存執(zhí)行結(jié)果;當(dāng)收到第2個~第N個執(zhí)行體的協(xié)同執(zhí)行調(diào)用時,將保存的協(xié)同執(zhí)行結(jié)果返回給相應(yīng)的執(zhí)行體。
管理服務(wù)包括管理服務(wù)器和運行節(jié)點服務(wù)管理者和管理者服務(wù)代理,其中主要的功能模塊如圖6所示。
圖6 管理服務(wù)功能組成示意圖
Fig.6Schematic diagram of function composition ofmanagement service
管理服務(wù)器主要包括3個功能模塊:
1)擬態(tài)應(yīng)用管理模塊。創(chuàng)建和部署擬態(tài)應(yīng)用、匯總和處理節(jié)點上報應(yīng)用資源狀態(tài)日志信息、監(jiān)管擬態(tài)應(yīng)用執(zhí)行過程。
2)擬態(tài)資源管理模塊。包括擬態(tài)資源監(jiān)控、異構(gòu)執(zhí)行體調(diào)度和表決服務(wù)器資源調(diào)度。
3)擬態(tài)安全威脅診斷模塊。包括擬態(tài)運行過程管理、告警和環(huán)境日志信息處理、安全威脅的清洗策略執(zhí)行。
運行節(jié)點代理服務(wù)完成服務(wù)器節(jié)點資源狀態(tài)信息的采集,并將其上報給管理服務(wù)器,并且執(zhí)行管理服務(wù)器下發(fā)的管理命令。
基于對示例應(yīng)用程序ybsapp.war的MCOE模型實現(xiàn)包括3個部分:1)異構(gòu)執(zhí)行體管理和資源調(diào)度;2)分發(fā)服務(wù)對各個異構(gòu)執(zhí)行體進行服務(wù)請求分發(fā);3)對各個異構(gòu)體上的請求響應(yīng)結(jié)果進行外部表決并將結(jié)果反饋管理服務(wù)。
首先在異構(gòu)執(zhí)行體的基礎(chǔ)層(CPU類型和操作系統(tǒng)類型)和應(yīng)用支撐層(Web容器)上實現(xiàn)異構(gòu)。管理服務(wù)使用MySQL實現(xiàn)對異構(gòu)執(zhí)行體節(jié)點和資源的管理。異構(gòu)執(zhí)行體節(jié)點狀態(tài)示例如圖7所示,模型實現(xiàn)階段實際部署4個異構(gòu)執(zhí)行體應(yīng)用服務(wù)器,本文實驗中執(zhí)行體1~執(zhí)行體4所用Web容器分別為Jboss、Tomcat8.0、Tomcat8.5、Tomcat9.0。
圖7 異構(gòu)執(zhí)行體節(jié)點狀態(tài)示例
異構(gòu)執(zhí)行體上的運行節(jié)點代理服務(wù)將異構(gòu)執(zhí)行體狀態(tài)信息實時上報到管理服務(wù)器,管理服務(wù)器實時判定執(zhí)行體運行狀態(tài)是否正常。
分發(fā)服務(wù)通過改造Nginx反向代理服務(wù)[18],以及對Nginx主請求-子請求機制與Proxy反向代理機制的改進,實現(xiàn)服務(wù)請求的異構(gòu)化、服務(wù)請求的轉(zhuǎn)發(fā)、外部表決服務(wù)的調(diào)用,并將外部表決結(jié)果返回給客戶端。
客戶端(192.168.2.7:8080)發(fā)起示例應(yīng)用ybsapp服務(wù)請求,分發(fā)服務(wù)向管理服務(wù)發(fā)出資源調(diào)度請求,管理服務(wù)通過異構(gòu)最大化調(diào)度[19]和負(fù)載均衡算法[20]調(diào)度出此次執(zhí)行服務(wù)請求的3個異構(gòu)執(zhí)行體和外部表決地址,分發(fā)服務(wù)通過“擬態(tài)資源調(diào)度接口”獲取相應(yīng)節(jié)點執(zhí)行資源,再由分發(fā)服務(wù)構(gòu)建包含服務(wù)請求主鍵、異構(gòu)執(zhí)行體和表決服務(wù)器節(jié)點資源的地址文件,如圖8所示。
圖8 服務(wù)請求執(zhí)行資源分配profile示例
Fig.8 Example profile of a service request for resourceallocation
各個服務(wù)器間通過服務(wù)請求主鍵進行關(guān)聯(lián),分發(fā)服務(wù)通過Nginx轉(zhuǎn)發(fā)地址文件到相應(yīng)的N個異構(gòu)執(zhí)行體和外部表決服務(wù)器,同時轉(zhuǎn)發(fā)服務(wù)請求到相應(yīng)的異構(gòu)執(zhí)行體上的服務(wù)請求轉(zhuǎn)發(fā)接口,如圖9所示。
圖9 分發(fā)服務(wù)Nginx轉(zhuǎn)發(fā)過程示例
Fig.9Example of forwarding process of distribution serviceNginx
圖9所示分發(fā)的是一個示例Web應(yīng)用ybs,經(jīng)過分發(fā)服務(wù)Nginx將異構(gòu)化的服務(wù)請求分發(fā)到3個異構(gòu)執(zhí)行體(執(zhí)行體1:192.168.2.28、執(zhí)行體2:192.168.2.75、執(zhí)行體3:192.168.2.32)上,同時調(diào)用外部表決服務(wù)器:192.168.2.36進行服務(wù)請求響應(yīng)表決。
外部表決服務(wù)基于擬態(tài)表決策略,采用一致性校驗算法對服務(wù)請求響應(yīng)進行一致性表決[21]。本文實驗的擬態(tài)表決策略采用三取二表決,即2/3表決對象一致時表決結(jié)果為正常,其他情況表決結(jié)果為異常。
外部表決成功后的反饋結(jié)果如圖10所示,異構(gòu)執(zhí)行體1~執(zhí)行體4初始的表決成功次數(shù)均為0,對異構(gòu)執(zhí)行體1~執(zhí)行體3執(zhí)行服務(wù)請求表決,表決結(jié)果為成功(執(zhí)行體1~執(zhí)行體3表決對象一致),執(zhí)行體1~執(zhí)行體3的表決成功加1,而執(zhí)行體4作為備用執(zhí)行體不參與表決,其表決成功次數(shù)仍為0。表決成功后將返回表決結(jié)果給分發(fā)服務(wù),再由分發(fā)服務(wù)將服務(wù)請求響應(yīng)返回給客戶端。
圖10 表決成功后部署情況示例
外部表決成功后將最終的服務(wù)請求響應(yīng)結(jié)果返回給客戶端,客戶端得到的響應(yīng)頁面如圖11所示。
圖11 客戶端響應(yīng)頁面1
對異構(gòu)執(zhí)行體進行網(wǎng)頁篡改攻擊后,同樣進行服務(wù)請求分發(fā),表決結(jié)果如圖12所示,執(zhí)行體2被表決為異常,但由于異構(gòu)執(zhí)行體互相之間的異構(gòu)性,使得網(wǎng)頁篡改對執(zhí)行體1和執(zhí)行體3并未生效,此次表決結(jié)果仍為成功。
圖12 篡改攻擊、表決后部署情況示例
Fig.12 Example of deployment results after voting for tamper attacks
外部表決服務(wù)返回表決結(jié)果和異常執(zhí)行體地址信息給分發(fā)服務(wù),分發(fā)服務(wù)將服務(wù)請求響應(yīng)返回給客戶端,客戶端得到的響應(yīng)頁面如圖13所示,仍為正常的服務(wù)請求響應(yīng)頁面。分發(fā)服務(wù)將異常執(zhí)行體地址信息上報至管理服務(wù),由管理服務(wù)調(diào)用管理者服務(wù)代理進行異常異構(gòu)執(zhí)行體替換和清洗恢復(fù)。
圖13 客戶端響應(yīng)頁面2
經(jīng)過實驗驗證,由于異構(gòu)執(zhí)行體本身的異構(gòu)性,當(dāng)出現(xiàn)系統(tǒng)安全攻擊時至多導(dǎo)致一個異構(gòu)執(zhí)行體出現(xiàn)異常,而基于3取2表決并不會影響最終返回給客戶端的服務(wù)請求響應(yīng)結(jié)果。MCOE對于異構(gòu)執(zhí)行體的部署和服務(wù)請求的分發(fā)、表決、管理可以達(dá)到防止網(wǎng)頁篡改的目的,保證返回給客戶端正確的服務(wù)請求響應(yīng)。
本文結(jié)合擬態(tài)防御理論,為擬態(tài)信息系統(tǒng)的N異構(gòu)執(zhí)行體設(shè)計系統(tǒng)化的運行環(huán)境框架MCOE。通過改進Nginx反向代理服務(wù)實現(xiàn)對服務(wù)請求分發(fā)和響應(yīng)結(jié)果的處理,同時使用一致性校驗算法進行服務(wù)請求響應(yīng)結(jié)果表決,有效防御應(yīng)用程序后門和漏洞引發(fā)的網(wǎng)頁篡改行為。下一步將對分發(fā)服務(wù)和表決服務(wù)進行改進,提升MCOE框架使用場景的普適性。