李津津,賈曉啟,杜海超,王利朋

1.網(wǎng)絡(luò)安全防護技術(shù)北京市重點實驗室(中國科學(xué)院 信息工程研究所),北京100195;2.中國科學(xué)院大學(xué) 計算機與控制學(xué)院,北京100049; 3.中國科學(xué)院大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院,北京100049)(*通信作者電子郵箱duhaichao@iie.ac.cn)

基于虛擬化技術(shù)的有效提高系統(tǒng)可用性的方法

李津津1,2,賈曉啟1,3,杜海超1*,王利朋1

1.網(wǎng)絡(luò)安全防護技術(shù)北京市重點實驗室(中國科學(xué)院 信息工程研究所),北京100195;2.中國科學(xué)院大學(xué) 計算機與控制學(xué)院,北京100049; 3.中國科學(xué)院大學(xué) 網(wǎng)絡(luò)空間安全學(xué)院,北京100049)(*通信作者電子郵箱duhaichao@iie.ac.cn)

針對安全攸關(guān)的客戶機在安全工具發(fā)生警報時往往會進行暫停、檢測、恢復(fù)等操作,而安全工具誤報(虛報、漏報)的發(fā)生和發(fā)現(xiàn)存在延遲,從而對客戶機造成可用性影響的問題,提出一種基于虛擬化技術(shù)的有效解決方案。在誤報發(fā)生時,首先正確控制可疑進程行為,避免該進程對系統(tǒng)造成實質(zhì)性影響。其次記錄可疑進程行為,并根據(jù)其與系統(tǒng)其他進程的交互行為形成進程間依賴關(guān)系。當(dāng)誤報被發(fā)現(xiàn)時,以記錄的進程行為及進程間依賴關(guān)系為依據(jù),對可疑進程及與其存在依賴關(guān)系的相關(guān)進程采取恢復(fù)進程行為、殺死相關(guān)進程等措施,使系統(tǒng)快速達(dá)到正確運行狀態(tài)。實驗結(jié)果表明,所提方案能夠在安全工具發(fā)生誤報時,避免回滾、恢復(fù)等操作帶來的時間開銷,相對于未采取措施的情況,所提方案將誤報存在時的處理時間減少20%～50%。所提方案能夠有效降低安全工具誤報對客戶機可用性造成的影響,可應(yīng)用在安全攸關(guān)的客戶機所在的云平臺之上。

虛擬化;可用性;安全技術(shù);云平臺;系統(tǒng)調(diào)用

0 引言

隨著虛擬化技術(shù)的不斷發(fā)展,云計算應(yīng)用越來越廣泛。解決面向云平臺的安全問題、保障使用云服務(wù)的客戶機系統(tǒng)安全成為當(dāng)下的研究熱點之一。國內(nèi)外有很多研究者提出基于虛擬化技術(shù)或操作系統(tǒng)的安全防護技術(shù)方案?；谔摂M化架構(gòu)的安全功能的研究已有了一些學(xué)術(shù)成果,主要包括實現(xiàn)惡意代碼的檢測和分析、完整性監(jiān)控、入侵檢測(如基于主機的入侵檢測系統(tǒng)模型[1])和安全監(jiān)控[2]。

在惡意代碼檢測與分析方面,Jiang等[3]提出了VMwatcher(Virtual Machine watcher)機制,它在客戶機系統(tǒng)之外部署惡意行為檢測系統(tǒng),并在監(jiān)控層進行語義恢復(fù),能夠檢測出系統(tǒng)存在的惡意程序。Dinaburg等[4]提出基于Xen的Ether方法,整個系統(tǒng)分為兩個部分：一部分工作在監(jiān)控層下；一部分工作在Xen的特權(quán)管理域(dom0)中,利用Intel VT(Intel Virtualization Technology)技術(shù)對被監(jiān)控系統(tǒng)中的可疑程序進行跟蹤。Lanzi等[5]基于QEMU(Quick Emulator)提出并開發(fā)了K-Tracer惡意代碼行為分析工具,它能夠動態(tài)收集Windows內(nèi)核的執(zhí)行路徑信息,并采用后向和前向切片技術(shù)來提取惡意代碼行為。文獻(xiàn)[6]提出的Rkprofiler是一個基于沙盒的惡意代碼分析系統(tǒng),它能夠監(jiān)控并報告客戶機操作系統(tǒng)中運行的惡意代碼的行為。

在完整性保護方面,文獻(xiàn)[7]提出的SecVisor通過創(chuàng)建一種輕量級虛擬機對操作系統(tǒng)進行內(nèi)存保護,它基于頁表對內(nèi)核模式和用戶模式下的內(nèi)存進行內(nèi)存保護。Payne等[8]提出的LibVMI是同時支持KVM(Kernel Virtual Machine)、QEMU、Xen平臺的安全監(jiān)控工具,它可以讀寫虛擬機內(nèi)任意一塊內(nèi)存,通過內(nèi)存對進程、文件等進行系統(tǒng)級別的監(jiān)控。

在安全監(jiān)控方面,Payne等[9]提出的Lares系統(tǒng)是內(nèi)部監(jiān)控的典型代表,它將安全系統(tǒng)部署在客戶機系統(tǒng)外的一個安全域中,同時在客戶機系統(tǒng)的內(nèi)核中插入鉤子函數(shù),鉤子函數(shù)用來攔截某些事件。由于鉤子函數(shù)存在于客戶機系統(tǒng)的內(nèi)核中,能夠被客戶機系統(tǒng)感知,存在被惡意程序篡改的可能性,因此需要在虛擬機管理層對鉤子函數(shù)所在內(nèi)存區(qū)域進行保護。

在入侵檢測方面, Laureano等[1]提出了基于主機的入侵檢測系統(tǒng)的保護方法,它通過分析在外部監(jiān)控虛擬機所獲取的系統(tǒng)調(diào)用序列來判斷進程行為是否存在異常,并采用相應(yīng)的措施。文獻(xiàn)[10]提出的VNIDA是通過建立一個單獨的入侵檢測域為其他虛擬機提供入侵檢測服務(wù)。

然而,這些方案均沒有考慮到云服務(wù)客戶機的可用性問題。不論是基于操作系統(tǒng)或是基于虛擬化技術(shù)的安全工具,在對系統(tǒng)進行檢測、防御、恢復(fù)的過程中,均會對系統(tǒng)可用性帶來影響,而在云平臺之上的客戶機對于自身可用性具有更高的要求,因此應(yīng)該盡量減少安全防護措施對客戶機正常運行的干擾。

在實際應(yīng)用場景中,安全防護工具不可避免會發(fā)生誤報行為,安全攸關(guān)的客戶機在安全工具發(fā)生警報時,往往會進行暫停、檢測、恢復(fù)等操作,而安全工具誤報(虛報、漏報)的發(fā)生和發(fā)現(xiàn)存在延遲,因此誤報會降低客戶機系統(tǒng)的可用性。為解決這個問題,本文提出一種基于虛擬化技術(shù)的有效解決方案,降低由安全防護工具的誤報引發(fā)的對云平臺客戶機系統(tǒng)可用性的影響。當(dāng)安全防護工具發(fā)生誤報時,本文方案能夠確保客戶機持續(xù)不斷地運行,而不用進行回滾、暫停、重啟等操作,并維護客戶機系統(tǒng)應(yīng)有的狀態(tài)。

1 誤報場景模型

現(xiàn)實場景中,一個主機可能被多種安全工具所保護,如安裝殺毒軟件、部署入侵檢測系統(tǒng)進行安全監(jiān)控等。然而,任何一個安全工具都有發(fā)生誤報的可能。假設(shè)有兩個安全工具同時對一臺主機進行安全監(jiān)控,分別為A和B。假如A和B發(fā)生警報的時間有分歧,則說明它們之中有一個發(fā)生了誤報。假設(shè)在t1時刻,A發(fā)生警報,而B未發(fā)生警報,此時有以下兩種情況:

1)如果A的警報正確,說明B發(fā)生漏報;

2)如果A的警報不正確,說明A發(fā)生虛報。

即t1時刻A和B中有一個發(fā)生了誤報,并且難以提供可靠的依據(jù)以判斷是哪一個工具發(fā)生誤報,也就難以依據(jù)結(jié)果作出正確的決策。決策結(jié)果有以下兩種可能:

1)決策為B發(fā)生誤報(即認(rèn)為A的警報正確、B發(fā)生漏報)而停止了產(chǎn)生該威脅的進程。假如此時并未真正發(fā)生安全威脅,就破壞了該進程的正常運行狀態(tài)。當(dāng)t2時刻發(fā)現(xiàn)A虛報時,需要重新運行該進程,這樣就對客戶機的可用性造成了影響,見圖1。圖1中的方塊代表進程行為,其中底紋相同的方塊代表同一行為,底紋不同的方塊代表不同行為,橫軸代表時間。t1到t2時刻內(nèi)該進程停止運行(虛線表示),在t2時刻進程恢復(fù)運行,由于失去了該進程正常的運行狀態(tài),需要重新執(zhí)行t1時刻之前執(zhí)行過的行為,因此會帶來較大的時間開銷,降低系統(tǒng)的可用性。

圖1 虛報場景

針對這個場景,本文方案采取的策略是從t1時刻開始捕獲并記錄該進程的后續(xù)行為。在t2時刻,誤報被確定,判斷該進程并非惡意進程,此時就不必因之前的虛報殺死了該進程而重新運行它,而是通過釋放該進程相關(guān)行為,使該進程能夠在正確狀態(tài)下正常運行下去,以此避免了對客戶機可用性造成的影響。見圖2。在t2時刻后不需要執(zhí)行t1時刻前執(zhí)行過的行為。

圖2 改進后的虛報場景

2)決策為A發(fā)生誤報(即認(rèn)為A發(fā)生虛報)而放過了產(chǎn)生該威脅的進程。假如該進程確實是惡意進程,則在一般情況下,該進程就會進一步對系統(tǒng)造成破壞。當(dāng)t2時刻發(fā)現(xiàn)漏報時,破壞行為往往已經(jīng)完成,此時就需要通過系統(tǒng)回滾來恢復(fù)系統(tǒng),見圖3。

圖3中的橫軸代表進程的狀態(tài),實線表示正在運行,虛線表示暫停。將系統(tǒng)中的進程分成三類,分別是正常進程、受感染進程和惡意進程。一些進程由于和惡意進程存在交互而受到感染。由于t1到t2時刻內(nèi),惡意進程已經(jīng)對系統(tǒng)造成實質(zhì)性影響,因此需要暫停一段時間進行系統(tǒng)恢復(fù)。在這段時間內(nèi),正常進程和受感染進程均處于暫停狀態(tài),系統(tǒng)可用性受到影響。

圖3 漏報場景

針對這個場景,本文方案采取的策略是控制進程行為不會對系統(tǒng)造成實質(zhì)性影響(例如修改系統(tǒng)文件、創(chuàng)建相關(guān)惡意進程)。在t2時若發(fā)現(xiàn)t1時刻A并非虛報,僅需殺死該進程即可恢復(fù)系統(tǒng)安全運行,而不需要將系統(tǒng)回滾,以此避免了對客戶機的可用性造成的影響。如圖4所示,惡意進程以外的進程始終處于運行狀態(tài)。

總結(jié)以上描述,本研究希望針對以下問題進行解決:在難以判斷某時刻是否發(fā)生誤報、誤報為虛報還是漏報時,采取措施使得不論是何種情況,均能使進程持續(xù)不斷地運行,并且保證進程不對系統(tǒng)造成任何威脅;在之后的某個時刻,誤報類型被發(fā)現(xiàn)時,能夠快速恢復(fù)系統(tǒng)的正常運行狀態(tài)。

2 方案設(shè)計

2.1 語義解析

為實現(xiàn)虛擬化監(jiān)控層(VirtualMachineMonitor,VMM)對上層客戶機進程行為控制,需要在VMM中對客戶機進程行為信息進行捕獲。而VMM獲取的數(shù)據(jù)缺乏語義,因此需要解決如何從VMM正確解析客戶機行為信息的問題。

本研究采用系統(tǒng)調(diào)用行為序列作為進程行為控制的基礎(chǔ)。利用文獻(xiàn)[11]提出的在VMM下捕獲客戶機系統(tǒng)調(diào)用行為信息的方法,對客戶機進程的行為信息進行捕獲。捕獲行為包括文件操作和進程操作,具體內(nèi)容見表1。

表1 捕獲行為

捕獲到的行為信息包括系統(tǒng)調(diào)用號、進程id以及與具體行為有關(guān)的信息,如文件操作中的文件路徑、進程操作中的進程id。

2.2 進程間依賴

由于進程之間存在進程間通信,因此有些行為并不是孤立的。比如p進程被判定為可疑進程,p進程的行為會處于控制之下。如果q進程和p進程存在行為交互,那么q進程就可能被p進程所感染,因此q進程的行為也應(yīng)該受到控制。進程間交互行為決定了進程間的關(guān)系,如何根據(jù)各進程的行為形成依賴關(guān)系也是需要解決的問題之一。

產(chǎn)生進程間交互的行為可以分為直接交互和間接交互。進程創(chuàng)建(如fork)、進程間通信(如pipe)可看作是進程間的直接交互。通過文件操作的交互可看作是間接交互,比如進程p寫了某文件,進程q讀了同一個文件,可以認(rèn)為進程p、q間產(chǎn)生間接交互。同理還有mmap系統(tǒng)調(diào)用。文獻(xiàn)[12]對進程間交互行為形成的依賴關(guān)系進行了相關(guān)分析。

2.3 進程行為控制

要實現(xiàn)當(dāng)漏報被發(fā)現(xiàn)時只需將威脅進程殺死即可恢復(fù)系統(tǒng)安全,就要保證該進程在漏報被發(fā)現(xiàn)之前,未對系統(tǒng)造成實質(zhì)性影響。如何控制客戶機的進程行為,保證對該進程及與其存在依賴關(guān)系的進程透明的前提下繼續(xù)運行,并且其行為對系統(tǒng)不產(chǎn)生影響,也是需要解決的問題之一。

為保證客戶機中處于控制之下的進程能夠在不影響系統(tǒng)的前提下正常運行下去,需要采取一些控制措施。例如,捕獲到進程的系統(tǒng)調(diào)用行為時修改其參數(shù)。客戶機恢復(fù)執(zhí)行后,就會根據(jù)新的參數(shù)去執(zhí)行該系統(tǒng)調(diào)用,但是這個行為并沒有對系統(tǒng)產(chǎn)生實質(zhì)的改變,并且該進程能夠正常執(zhí)行下去。而這個被修改的行為可能會影響到該進程及其他進程后續(xù)的行為,因此,要對該進程以及相關(guān)進程的后續(xù)行為繼續(xù)采取控制措施。

2.4 進程行為釋放

當(dāng)虛報被發(fā)現(xiàn)時,如何將之前處于控制之下的進程釋放掉,使系統(tǒng)狀態(tài)變?yōu)樵撨M程正常運行到此時的狀態(tài),即,如何將進程受控行為釋放到客戶機中,使其快速恢復(fù)應(yīng)有的運行狀態(tài),也是需要解決的問題之一。例如一個非惡意進程被虛報,該進程如果繼續(xù)運行下去,后續(xù)會產(chǎn)生一個影響系統(tǒng)的行為(例如修改了系統(tǒng)文件),將該行為記為行為1。在行為1后該進程執(zhí)行了一些對系統(tǒng)沒有影響的行為,隨后產(chǎn)生了另一個影響系統(tǒng)的行為,記為行為2。在此場景下,本研究采取相應(yīng)措施,在發(fā)生虛報之后讓該進程繼續(xù)運行,同時控制行為1和行為2并未真正對系統(tǒng)產(chǎn)生影響,而其他無影響行為能夠正常執(zhí)行;當(dāng)發(fā)現(xiàn)虛報存在時,將受控行為釋放掉,保證進程持續(xù)不斷地正常運行。實現(xiàn)上述目標(biāo)有以下兩種方案。

方案1 在該進程不知情的情況下控制該進程,使其不執(zhí)行真正影響系統(tǒng)的行為,即行為1和行為2,而其他行為都正常執(zhí)行。在虛報被發(fā)現(xiàn)時,只重新執(zhí)行受控行為,即行為1和行為2,其他行為不用重新執(zhí)行。此方案在性能上具有優(yōu)勢,但是在通用性方面存在局限性。影響系統(tǒng)的行為往往存在一些后續(xù)效果,即,這些行為不是獨立存在的。例如,行為1本應(yīng)在t1時刻執(zhí)行,但此時控制它在t1時刻不執(zhí)行,而在之后的t2時刻執(zhí)行,這樣可能會出現(xiàn)狀態(tài)出錯的問題,因為t1時刻是否成功完成該行為可能會影響到后續(xù)的運行狀態(tài)。如圖5的情況:t1時刻是否成功將“aaa”寫入文件x,決定了t2時刻執(zhí)行行為α或是行為β。這說明后續(xù)運行狀態(tài)受到該行為影響。

圖5 行為執(zhí)行對流程的影響

因此這種方案只能在少部分情況下起到作用,即：當(dāng)受控行為完全獨立,對該進程后續(xù)行為流程完全沒有影響時,此方案才能保證進程正確的運行狀態(tài)。

方案2 在t1時刻,利用進程備份來保存運行狀態(tài)。當(dāng)進程被發(fā)現(xiàn)虛報時,通過快速達(dá)到所保存的運行狀態(tài)來恢復(fù)進程,并讓這個進程繼續(xù)完成該時間點之后的行為。此方案對比方案1雖然有一些性能損失,但是它在通用性方面沒有局限性。此方案能夠保證任何情況下進程的正確運行狀態(tài),并且不需要額外記錄進程行為,從而減少了空間開銷。

本文采用方案2解決進程的行為釋放問題。在進程有可能被虛報為惡意進程時,記錄下該時刻的進程狀態(tài),在虛報被發(fā)現(xiàn)時,就從記錄的時刻開始恢復(fù)進程的行為,以使進程快速恢復(fù)到應(yīng)有的運行狀態(tài),而無需重新運行。這個過程的實現(xiàn)不需要改動客戶機的內(nèi)核代碼。實現(xiàn)方式是在一個處于用戶態(tài)的陷入時刻,對該進程注入系統(tǒng)調(diào)用。

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

整體系統(tǒng)結(jié)構(gòu)如圖6。本系統(tǒng)將云平臺分為兩部分:一部分是云平臺之上的客戶機；另一部分是虛擬化架構(gòu)中的VMM。本系統(tǒng)在VMM層中添加捕獲模塊、行為控制模塊、行為釋放模塊,不對客戶機作任何更改。

圖6 系統(tǒng)結(jié)構(gòu)

3.1 工作流程

當(dāng)一個安全工具產(chǎn)生報警時,本系統(tǒng)將接收到該信號(安全工具如何發(fā)送信號給本系統(tǒng)不是本研究的重點,以下實驗將以來自dom0的超級調(diào)用來模擬來自安全工具的報警信號),然后執(zhí)行以下流程:

1)將產(chǎn)生威脅的進程(由安全工具提供)標(biāo)為可疑進程,將其進程id傳遞給捕獲模塊和行為釋放模塊。

2)行為釋放模塊對該進程進行備份。

3)捕獲模塊對該進程行為進行捕獲,并將捕獲到的行為傳遞給行為控制模塊。

4)行為控制模塊對進程行為進行控制,并根據(jù)行為類型形成進程間依賴關(guān)系。

5)當(dāng)誤報被發(fā)現(xiàn)時,若為漏報,則只需殺死該進程和備份進程即可;若為虛報,則將消息發(fā)送給行為釋放模塊,該模塊負(fù)責(zé)恢復(fù)進程狀態(tài),使進程能夠持續(xù)不斷運行。

3.2 捕獲模塊

捕獲模塊負(fù)責(zé)捕獲客戶機中進程的系統(tǒng)調(diào)用行為,并以此為根據(jù)形成依賴關(guān)系。捕獲行為的時刻發(fā)生在該行為執(zhí)行之前,也就是sysenter/int80指令執(zhí)行完畢,下一條指令執(zhí)行之前的時刻。在該時刻通過控制客戶機陷入到VMM中,從VMM獲取客戶機內(nèi)存中重要結(jié)構(gòu),如當(dāng)前進程的任務(wù)狀態(tài)段(TaskStateSegment,TSS),得到該進程task_struct結(jié)構(gòu),以獲得進程相關(guān)信息,并通過讀取寄存器及內(nèi)存中棧的內(nèi)容,獲取系統(tǒng)調(diào)用號以及參數(shù)信息。

3.3 行為控制模塊

行為控制模塊負(fù)責(zé)對受監(jiān)控的進程進行后續(xù)行為的控制,并維持該進程以及相關(guān)進程的正常運行。當(dāng)捕獲模塊捕獲到一個來自受控進程或與之存在依賴關(guān)系的進程行為時,交給行為控制模塊進行處理。該模塊首先判斷當(dāng)前行為是否是一個需要被修改的行為。若不是,則不作處理;若是,則按照表2進行行為控制。修改結(jié)束之后返回給客戶機,客戶機將不會察覺到VMM對該進程的任何修改,并繼續(xù)正常運行該進程。

該模塊同時負(fù)責(zé)根據(jù)進程行為形成進程之間的依賴關(guān)系,行為控制見表2。如write系統(tǒng)調(diào)用,控制方式為在該系統(tǒng)調(diào)用執(zhí)行之前將寫的內(nèi)容清零;對于mmap系統(tǒng)調(diào)用,當(dāng)多個進程mmap同一個文件時,就會產(chǎn)生進程間依賴,此時的控制方式是允許其執(zhí)行,同時記錄產(chǎn)生的依賴關(guān)系。類似的還有write/read產(chǎn)生的進程間依賴,控制方式與mmap相同。fork和clone也會產(chǎn)生進程間依賴,但控制方式是不允許其執(zhí)行,這里通過在該系統(tǒng)調(diào)用執(zhí)行之前,修改其系統(tǒng)調(diào)用號為一個無副作用的系統(tǒng)調(diào)用(如getpid())來實現(xiàn)控制。pipe由于經(jīng)常和fork捆綁使用,當(dāng)fork無法執(zhí)行時,pipe也無法起到應(yīng)有的效果,因此這里允許其執(zhí)行。

表2 各行為控制方式

3.4 行為釋放模塊

行為釋放模塊負(fù)責(zé)對進程進行備份處理,并將虛報為惡意的進程釋放掉,以快速恢復(fù)其正常運行狀態(tài)。

當(dāng)某一進程開始處于控制之下,或某一進程與受控進程產(chǎn)生依賴關(guān)系時,則交給行為釋放模塊進行該進程狀態(tài)的備份。對進程進行備份的方法是,在該進程處于用戶態(tài)時主動陷入到VMM中,此時對該進程注入一個fork系統(tǒng)調(diào)用,以實現(xiàn)進程備份。注入fork系統(tǒng)調(diào)用的方法是修改進程代碼段中的4個字節(jié),將原代碼內(nèi)容修改為int3、int80、int3三條指令。其中：int80指令用來注入系統(tǒng)調(diào)用；int3指令用來產(chǎn)生客戶機到VMM的主動陷入。修改代碼時需要保存該位置原來的代碼內(nèi)容,以便之后的恢復(fù)工作。代碼被修改后,還需要設(shè)置eax寄存器的值為fork系統(tǒng)調(diào)用號,這樣,當(dāng)客戶機執(zhí)行到int80指令時,就能夠正確執(zhí)行fork系統(tǒng)調(diào)用完成進程的備份。由于eax寄存器也被修改,因此這里同樣需要將原本的eax寄存器值記錄下來。ForkInjecting算法如下。

算法1ForkInjecting。

1)

if(modify==1)

/*thecodehadbeeninjected*/

2)

{

3)

savethevalueofrax;

4)

modifyeaxtoforksystemcallnumber;

5)

}

6)

else

/*thecodehadnotbeeninjected*/

7)

{

8)

fetch_content(eip);

/*fetchthecontentofeip*/

9)

savethevalueofeax;

10)

modifyeaxtoforksystemcallnumber;

11)

injectfourbytescode;

12)

turnontheint3interrupt;

13)

}

14)

modifytheeipto"int80";

fork產(chǎn)生的子進程作為備份進程,應(yīng)該暫停在此狀態(tài)下,而不應(yīng)該被調(diào)度運行;當(dāng)行為需要被釋放時,才解除其暫停狀態(tài)。這里采用的方法是,如果檢測到是子進程被調(diào)度執(zhí)行,則注入sched_yield系統(tǒng)調(diào)用使其睡眠,注入的方法同fork,修改eax寄存器為sched_yield系統(tǒng)調(diào)用號,并修改eip寄存器到int80指令的位置即可。

另外,由于所修改的代碼段部分往往是被多個進程所共享的,因此修改的代碼有可能被其他無關(guān)進程所執(zhí)行,而其他進程應(yīng)執(zhí)行原來的代碼,而不應(yīng)該執(zhí)行修改后的代碼,因此這里加入兩個int3指令,以對客戶機陷入VMM時正在運行進程的行為流程進行控制。由于有兩個int3指令,因此從int3陷入的情況分為兩種:從第一個int3陷入(1stint3)以及從第二個int3陷入(2ndint3)。不同陷入情況的處理措施見圖7。

圖7 int3陷入后的處理

從第一個int3陷入可分為以下兩種情況:

1)一個無關(guān)進程運行到這里,會從第一個int3陷入,為了不影響該進程的正常執(zhí)行流程,就需要模擬被修改的位置原來的代碼執(zhí)行效果。例如該位置原本為4個pop指令,則模擬將棧內(nèi)容依次彈出后的效果,即為相應(yīng)的4個寄存器賦值,修改esp寄存器使其指向出棧后的位置,并修改eip寄存器使其指向4個字節(jié)之后(4個pop指令分別為1字節(jié))。這樣,當(dāng)客戶機恢復(fù)運行時,該進程就能夠正常執(zhí)行下去。

2)受控進程的fork執(zhí)行完畢之后,其后續(xù)又執(zhí)行到這段代碼,它也會從第一個int3陷入。此時該進程也不應(yīng)該執(zhí)行修改后的代碼,因此處理方式與1)相同。

從第二個int3陷入也可分為以下兩種情況:

1)剛執(zhí)行完int80指令,即fork結(jié)束的受控進程,其下一條指令就是第二個int3。此時需要記錄eax寄存器的值,這是該進程的子進程的進程id。

2)子進程陷入。子進程剛被fork出來,它一旦被調(diào)度,執(zhí)行的第一條指令就是第二個int3,此時為它注入sched_yield系統(tǒng)調(diào)用使其睡眠。當(dāng)它再次被調(diào)度開始運行后執(zhí)行的仍然是第二個int3,如果還需要繼續(xù)睡眠,就重復(fù)以上的處理;當(dāng)行為釋放模塊收到控制信號,要將該進程以及存在依賴關(guān)系的進程釋放掉,此時不再進行睡眠處理,將修改的代碼恢復(fù)回原來的內(nèi)容。然而,此時可能有不止一個子進程處于睡眠狀態(tài),如果在第一個子進程陷入時發(fā)現(xiàn)需要被釋放,就立即恢復(fù)代碼,則其他的子進程就會由于寄存器值不匹配而發(fā)生錯亂,導(dǎo)致無法正常運行。因此這時不再為其注入sched_yield系統(tǒng)調(diào)用的同時,模擬原代碼效果,讓其繼續(xù)運行下去,并且記下這個進程的id,此后這個進程不會再因第二個int3而陷入,只可能從第一個int3陷入。當(dāng)最后一個需要釋放的子進程在第二個int3處陷入時,才可以恢復(fù)代碼。代碼恢復(fù)之后,不會再有任何進程因int3陷入。子進程相關(guān)處理在vmx_vmexit_handler的TRAP_int3條件中。

算法2 2ndInt3ChildProcessHandler。

1)

if(release==0)

/*cannotbereleased*/

2)

{

3)

modifyeipto1stint3;

4)

modifyeaxtosched_yieldsystemcallnumber;

5)

}

6)

else

/*needtobereleased*/

7)

{

8)

if(all_released==0)

/*somechildprocesseshavenotbeenreleased*/

9)

{

10)

if(currentprocesshasnotbeenreleased)

11)

simulate_4pop_on2ndint3;

12)

else

13)

simulate_4pop_on1stint3;

14)

}

15)

else

/*allthechildprocesseshavebeenreleased*/

16)

{

17)

modifyeip;

18)

recovertheoriginalcode;

19)

}

20)

}

4 測試和分析

以Xen- 4.4.0作為架構(gòu)原型,Ubuntu14.04.1作為宿主機,內(nèi)核版本為3.16.0-30-generic;centosrelease6.6作為客戶機,內(nèi)核版本為2.6.32-504.el6.i686。CPU為Inteli7- 4790 3.60GHz,內(nèi)存4GB。

4.1 效果測試

實驗中有兩個監(jiān)控工具A和B共同監(jiān)控客戶機,當(dāng)前客戶機中正在運行某一目標(biāo)進程。t1時刻A對該進程(目標(biāo)進程)產(chǎn)生報警,B未產(chǎn)生報警,則出現(xiàn)以下兩種場景。

4.1.1 虛報場景

A發(fā)生虛報,即目標(biāo)進程并非一個惡意進程,在t2時刻發(fā)現(xiàn)虛報(這里通過dom0使用超級調(diào)用發(fā)送信號來通知虛報被發(fā)現(xiàn))。該目標(biāo)進程被報警之后還執(zhí)行了其他操作,并與其他進程形成了依賴關(guān)系。實驗中本系統(tǒng)在報警過后能夠正確記錄各個進程依賴關(guān)系,并對相關(guān)進程的行為進行控制。在t2時刻虛報被發(fā)現(xiàn)時,能夠使相關(guān)進程繼續(xù)正常執(zhí)行,而不需要重新執(zhí)行。實驗中捕獲到的行為及數(shù)量如表3所示。

表3 各行為控制效果

4.1.2 漏報場景

B發(fā)生漏報,即目標(biāo)進程是一個惡意進程,在t2時刻發(fā)現(xiàn)漏報。由于目標(biāo)進程行為受到控制,并未對系統(tǒng)進行實質(zhì)性破壞,因此此時僅需殺死該進程及相關(guān)進程即可,而不需要進行系統(tǒng)暫停、恢復(fù)、回滾等操作。實驗樣本有Tsunami、Kaiten、XOR.DDoS。

Tsunami,從行為上分析,該程序開始執(zhí)行之后需要clone產(chǎn)生子進程,該子進程與攻擊主機建立socket連接,并發(fā)送數(shù)據(jù)。接收到攻擊主機的命令后,作為僵尸網(wǎng)絡(luò)中的一臺主機,被入侵主機對目標(biāo)發(fā)起DoS(DenialofService)、SYNflood等攻擊。在本實驗中,clone系統(tǒng)調(diào)用被捕獲并受到控制,使clone不會成功執(zhí)行,因此不會發(fā)生子進程與遠(yuǎn)程攻擊主機進行socket連接。

假設(shè)該進程執(zhí)行到clone時沒有任何安全工具對其產(chǎn)生警報,運行過程中生成了子進程。該子進程成功與遠(yuǎn)程主機進行連接并發(fā)生通信時,才有安全工具產(chǎn)生警報。本系統(tǒng)會控制write操作寫的內(nèi)容,由于發(fā)送網(wǎng)絡(luò)數(shù)據(jù)常用write系統(tǒng)調(diào)用作為底層實現(xiàn),因此在本系統(tǒng)控制下,遠(yuǎn)程攻擊主機無法接收到來自受感染主機的正常數(shù)據(jù)。

對另一個惡意程序樣本Kaiten進行分析。該進程會對系統(tǒng)文件,如/etc/rc.d/rc.local、/etc/rc.conf進行寫操作。本系統(tǒng)會對寫內(nèi)容進行控制,使寫操作無效?？梢钥闯?客戶機操作系統(tǒng)恢復(fù)工作量及其復(fù)雜性有所降低。

XOR.DDoS開始執(zhí)行時會進行自我復(fù)制,實現(xiàn)方式是在usr/bin、/bin、/tmp下創(chuàng)建文件并寫入二進制內(nèi)容。處于控制之下的進程將無法寫入數(shù)據(jù)到目標(biāo)文件中。

4.2 性能測試

性能測試用來分析本系統(tǒng)在性能方面的表現(xiàn)。時間測試使用gettimeofday()函數(shù)。

4.2.1 系統(tǒng)運行前后對比測試

選取5個非惡意程序作為虛報場景的實驗樣本a～e。在運行過程中,假設(shè)t1時刻發(fā)生虛報,t2時刻發(fā)現(xiàn)虛報。通常情況下,t2時刻發(fā)現(xiàn)虛報后,由于之前運行狀態(tài)的丟失需要重新運行程序;在本文方案之下,t2時刻發(fā)現(xiàn)虛報后,不需要重新開始運行,只需從t1時刻保存的進程狀態(tài)處繼續(xù)運行。實驗中測量的指標(biāo)如下(單位均為μs):ts為起始時刻；te1為正常結(jié)束時刻；tf為虛報發(fā)生時刻；tr為恢復(fù)時刻；te2為恢復(fù)后結(jié)束時刻。

評價指標(biāo)為t1和t2,分別表示系統(tǒng)運行前后的進程完整執(zhí)行時間。其計算公式如下:

t1=tf-ts+te1-ts

(1)

t2=tf-ts+te2-tr

(2)

實驗結(jié)果見表4。從改進前后時間百分比可以看出,改進之后虛報情況對客戶機的時間開銷有所降低。

表4 虛報場景改進前后時間對比

如果是漏報場景,節(jié)省的時間與未采取措施時進行系統(tǒng)回滾的時間有關(guān),而改進之后就不需要系統(tǒng)回滾,因此具有性能優(yōu)勢。

以上結(jié)果表明,相對于未采取措施的情況,本系統(tǒng)能夠在安全工具發(fā)生誤報時,避免回滾、恢復(fù)等操作帶來的時間開銷,減少了誤報處理時間,從而降低誤報對客戶機可用性造成的影響。

4.2.2 時間消耗測試

在進程運行過程中,警報可能在任何時刻產(chǎn)生。表5是一個進程樣本在運行過程中不同時刻S1～S4發(fā)生警報時的運行時間比較,從S1到S4發(fā)生警報的時刻依次接近程序運行結(jié)束。

表5 不同時刻發(fā)生警報時的運行時間比較

ts1和te1分別是沒有警報產(chǎn)生時該進程的運行起始時間和結(jié)束時間,ts2和te2分別是有警報產(chǎn)生時該進程的運行起始時間和結(jié)束時間。t1和t2分別是沒有警報產(chǎn)生和有警報產(chǎn)生時的運行時間,可用式(3)、(4)表示。

t1=te1-ts1

(3)

t2=te2-ts2

(4)

對多個進程進行上述實驗得到圖8。圖8中:S1～S4為發(fā)生警報的4個相對時間,滿足S1

圖8 不同時刻發(fā)生警報的性能影響

圖8中的折線體現(xiàn)了系統(tǒng)運行前后,進程執(zhí)行時間隨報警產(chǎn)生時刻的變化。從圖8中結(jié)果可以看出,進程運行中發(fā)生警報的時刻越靠后,本系統(tǒng)對進程性能影響越小。這是由于發(fā)生警報時,進程開始處于控制之下,之后受控進程的系統(tǒng)調(diào)用行為會使虛擬機發(fā)生VMM陷入,環(huán)境的切換帶來主要的時間開銷。因此,警報時刻越靠后,需要控制的行為越少,本系統(tǒng)性能表現(xiàn)越良好。

5 結(jié)語

本文針對安全工具對云平臺之上的客戶機可用性帶來的影響問題提出一種解決方案。該方案避免安全工具因誤報而進行系統(tǒng)恢復(fù)、回滾等操作,確保在誤報發(fā)生后,客戶機系統(tǒng)仍然能夠持續(xù)不斷地運行,并維持正確的運行狀態(tài)。實驗結(jié)果表明,該方案在安全工具誤報發(fā)生時能夠正確控制可疑進程,避免該進程對系統(tǒng)造成實質(zhì)性影響,并能保證該進程正確運行狀態(tài);在誤報發(fā)現(xiàn)時,系統(tǒng)能夠快速恢復(fù)到應(yīng)有的狀態(tài)。在性能方面本文方案也具有良好的表現(xiàn)。因此,本文方案能夠達(dá)到預(yù)期效果,降低安全工具對云平臺之上的客戶機可用性造成的影響。下一步將增加網(wǎng)絡(luò)相關(guān)操作的監(jiān)控、完成備份進程對客戶機透明等工作。

)

[1]LAUREANOM,MAZIEROC,JAMHOURE.Protectinghost-basedintrusiondetectorsthroughvirtualmachines[J].ComputerNetworks, 2007, 51(5): 1275-1283.

[2] 項國富, 金海, 鄒德清, 等. 基于虛擬化的安全監(jiān)控[J]. 軟件學(xué)報, 2012, 23(8): 2173-2187.(XIANGGF,JINH,ZOUDQ,etal.Virtualization-basedsecuritymonitoring[J].JournalofSoftware, 2012, 23(8): 2173-2187.)

[3]JIANGX,WANGX,XUD.StealthymalwaredetectionthroughVMM-basedout-of-the-boxsemanticviewreconstruction[C]//Proceedingsofthe14thACMConferenceonComputerandCommunicationsSecurity.NewYork:ACM, 2007: 128-138.

[4]DINABURGA,ROYALP,SHARIFM,etal.Ether:malwareanalysisviahardwarevirtualizationextensions[C]//Proceedingsofthe15thACMConferenceonComputerandCommunicationsSecurity.NewYork:ACM, 2008: 51-62.

[5]LANZIA,SHARIFMI,LEEW.K-Tracer:asystemforextractingkernelmalwarebehavior[EB/OL]. [2016- 03- 10].https://www.isoc.org/isoc/conferences/ndss/09/pdf/12.pdf.

[6]XUANC,COPELANDJ,BEYAHR.Towardrevealingkernelmalwarebehaviorinvirtualexecutionenvironments[C]//RAID2009:Proceedingsofthe12thInternationalSymposiumonRecentAdvancesinIntrusionDetection.Berlin:Springer, 2009: 304-325.

[7]SESHADRIA,LUKM,QUN,etal.SecVisor:atinyhypervisortoprovidelifetimekernelcodeintegrityforcommodityOSes[C]//SOSP2007:ProceedingsofTwenty-firstACMSIGOPSSymposiumonOperatingSystemsPrinciples.NewYork:ACM, 2007: 335-350.

[8]PAYNEBD,LEINHOSM.LibVMI[EB/OL]. [2016- 08- 29].http://libvmi.com.

[9]PAYNEBD,CARBONEM,SHARIFM,etal.Lares:anarchitectureforsecureactivemonitoringusingvirtualization[C]//SP2008:Proceedingsofthe2008IEEESymposiumonSecurityandPrivacy.Piscataway,NJ:IEEE, 2008: 233-247.

[10]ZHANGX,LIQ,QINGS,etal.VNIDA:buildinganIDSarchitectureusingVMM-basednon-intrusiveapproach[C]//WKDD2008:ProceedingsoftheFirstInternationalWorkshoponKnowledgeDiscoveryandDataMining.Piscataway,NJ:IEEE, 2008: 594-600.

[11]SHARIFMI,LEEW,CUIW,etal.Securein-VMmonitoringusinghardwarevirtualization[C]//Proceedingsofthe16thACMConferenceonComputerandCommunicationsSecurity.NewYork:ACM, 2009: 477-487.

[12]XIX,JIAX,LIUP.SHELF:preservingbusinesscontinuityandavailabilityinanintrusionrecoverysystem[C]//ACSAC2009:Proceedingsofthe2009AnnualComputerSecurityApplicationsConference.Piscataway,NJ:IEEE, 2009: 484-493.

[13]WUR,CHENP,LIUP,etal.Systemcallredirection:apracticalapproachtomeetingreal-worldvirtualmachineintrospectionneeds[C]//Proceedingsofthe2014 44thAnnualIEEE/IFIPInternationalConferenceonDependableSystemsandNetworks.Piscataway,NJ:IEEE, 2014: 574-585.

ThisworkispartiallysupportedbytheNationalNaturalScienceFoundationofChina(61100228),theNationalHighTechnologyResearchandDevelopmentProgram(863Program)ofChina(2012AA013101),theStrategicPriorityResearchProgramofChineseAcademyofSciences(XDA06030601,XDA06010701).

LI Jinjin, born in 1992, M. S. candidate. Her research interests include virtualization, information security.

JIA Xiaoqi, born in 1982, Ph. D., research fellow. His research interests include virtualization, network security, operating system security.

DU Haichao, born in 1989, M. S. Her research interests include system security, malicious code detection.

WANG Lipeng, born in 1987, M. S. His research interests include system security, virtualization.

Efficient virtualization-based approach to improve system availability

LI Jinjin1,2, JIA Xiaoqi1,3, DU Haichao1*, WANG Lipeng1

(1. Beijing Key Laboratory of Network Security and Protection Technology (Institute of Information Engineering, Chinese Academy of Sciences), Beijing 100195, China;2. School of Computer and Control Engineering, University of Chinese Academy of Sciences, Beijing 100049, China;3. School of Cyber Space Security, University of Chinese Academy of Sciences, Beijing 100049, China)

In terms of the problem that a safety-critical system will be paused, detected and resumed when security tools alert, and the delay between the occurrence and discovery of the false alarms (false positive or false negative) results in an effect on the availability of the guest Operating System (OS), a scheme based on virtualization was proposed. When a false alarm occurred, the operations of the suspicious application were quarantined correctly to avoid substantial system-wide damages. Then the operations of the suspicious application were logged and application inter-dependency information was generated according to its interactions with other applications. When the false alarm was determined, measures such as resuming the application’s operations and killing the relevant applications according to the operation logs and inter-dependency information were taken so that the guest OS could reach the correct operating status quickly. The experimental results show that the scheme can reduce the overhead caused by rollback and recovery when a false alarm occurs. Compared to the situation without the proposed scheme, the overhead of handling the false alarm is reduced by 20%-50%. The proposed scheme can effectively reduce the effect of false alarm on the availability of clients, and can be applied in the cloud platform which provides services to safety-critical clients.

virtualization; availability; security technology; cloud platform; system call

2016- 09- 14;

2016- 12- 24。 基金項目:國家自然科學(xué)基金資助項目(61100228);國家863計劃項目(2012AA013101);中國科學(xué)院戰(zhàn)略性先導(dǎo)專項(XDA06030601,XDA06010701)。

李津津(1992—),女,陜西西安人,碩士研究生,主要研究方向:虛擬化、信息安全; 賈曉啟(1982—),男,北京人,研究員,博士,CCF會員,主要研究方向:虛擬化、網(wǎng)絡(luò)安全、操作系統(tǒng)安全; 杜海超(1989—),女,北京人,碩士,CCF會員,主要研究方向:系統(tǒng)安全、惡意代碼檢測; 王利朋(1987—),男,河南新鄉(xiāng)人,碩士,主要研究方向:系統(tǒng)安全、虛擬化。

1001- 9081(2017)04- 0986- 07

10.11772/j.issn.1001- 9081.2017.04.0986

TP309.3

A