基于虛擬化技術的有效提高系統可用性的方法

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

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

基于虛擬化技術的有效提高系統可用性的方法

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

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

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

虛擬化;可用性;安全技術;云平臺;系統調用

0 引言

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

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

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

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

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

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

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

1 誤報場景模型

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

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

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

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

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

圖1 虛報場景

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

圖2 改進后的虛報場景

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

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

圖3 漏報場景

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

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

2 方案設計

2.1 語義解析

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

本研究采用系統調用行為序列作為進程行為控制的基礎。利用文獻[11]提出的在VMM下捕獲客戶機系統調用行為信息的方法,對客戶機進程的行為信息進行捕獲。捕獲行為包括文件操作和進程操作,具體內容見表1。

表1 捕獲行為

捕獲到的行為信息包括系統調用號、進程id以及與具體行為有關的信息,如文件操作中的文件路徑、進程操作中的進程id。

2.2 進程間依賴

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

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

2.3 進程行為控制

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

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

2.4 進程行為釋放

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

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

圖5 行為執行對流程的影響

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

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

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

3 系統實現

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

圖6 系統結構

3.1 工作流程

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

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

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

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

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

5)當誤報被發現時,若為漏報,則只需殺死該進程和備份進程即可;若為虛報,則將消息發送給行為釋放模塊,該模塊負責恢復進程狀態,使進程能夠持續不斷運行。

3.2 捕獲模塊

捕獲模塊負責捕獲客戶機中進程的系統調用行為,并以此為根據形成依賴關系。捕獲行為的時刻發生在該行為執行之前,也就是sysenter/int80指令執行完畢,下一條指令執行之前的時刻。在該時刻通過控制客戶機陷入到VMM中,從VMM獲取客戶機內存中重要結構,如當前進程的任務狀態段(TaskStateSegment,TSS),得到該進程task_struct結構,以獲得進程相關信息,并通過讀取寄存器及內存中棧的內容,獲取系統調用號以及參數信息。

3.3 行為控制模塊

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

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

表2 各行為控制方式

3.4 行為釋放模塊

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

當某一進程開始處于控制之下,或某一進程與受控進程產生依賴關系時,則交給行為釋放模塊進行該進程狀態的備份。對進程進行備份的方法是,在該進程處于用戶態時主動陷入到VMM中,此時對該進程注入一個fork系統調用,以實現進程備份。注入fork系統調用的方法是修改進程代碼段中的4個字節,將原代碼內容修改為int3、int80、int3三條指令。其中：int80指令用來注入系統調用；int3指令用來產生客戶機到VMM的主動陷入。修改代碼時需要保存該位置原來的代碼內容,以便之后的恢復工作。代碼被修改后,還需要設置eax寄存器的值為fork系統調用號,這樣,當客戶機執行到int80指令時,就能夠正確執行fork系統調用完成進程的備份。由于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產生的子進程作為備份進程,應該暫停在此狀態下,而不應該被調度運行;當行為需要被釋放時,才解除其暫停狀態。這里采用的方法是,如果檢測到是子進程被調度執行,則注入sched_yield系統調用使其睡眠,注入的方法同fork,修改eax寄存器為sched_yield系統調用號,并修改eip寄存器到int80指令的位置即可。

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

圖7 int3陷入后的處理

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

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

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

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

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

2)子進程陷入。子進程剛被fork出來,它一旦被調度,執行的第一條指令就是第二個int3,此時為它注入sched_yield系統調用使其睡眠。當它再次被調度開始運行后執行的仍然是第二個int3,如果還需要繼續睡眠,就重復以上的處理;當行為釋放模塊收到控制信號,要將該進程以及存在依賴關系的進程釋放掉,此時不再進行睡眠處理,將修改的代碼恢復回原來的內容。然而,此時可能有不止一個子進程處于睡眠狀態,如果在第一個子進程陷入時發現需要被釋放,就立即恢復代碼,則其他的子進程就會由于寄存器值不匹配而發生錯亂,導致無法正常運行。因此這時不再為其注入sched_yield系統調用的同時,模擬原代碼效果,讓其繼續運行下去,并且記下這個進程的id,此后這個進程不會再因第二個int3而陷入,只可能從第一個int3陷入。當最后一個需要釋放的子進程在第二個int3處陷入時,才可以恢復代碼。代碼恢復之后,不會再有任何進程因int3陷入。子進程相關處理在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作為架構原型,Ubuntu14.04.1作為宿主機,內核版本為3.16.0-30-generic;centosrelease6.6作為客戶機,內核版本為2.6.32-504.el6.i686。CPU為Inteli7- 4790 3.60GHz,內存4GB。

4.1 效果測試

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

4.1.1 虛報場景

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

表3 各行為控制效果

4.1.2 漏報場景

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

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

假設該進程執行到clone時沒有任何安全工具對其產生警報,運行過程中生成了子進程。該子進程成功與遠程主機進行連接并發生通信時,才有安全工具產生警報。本系統會控制write操作寫的內容,由于發送網絡數據常用write系統調用作為底層實現,因此在本系統控制下,遠程攻擊主機無法接收到來自受感染主機的正常數據。

對另一個惡意程序樣本Kaiten進行分析。該進程會對系統文件,如/etc/rc.d/rc.local、/etc/rc.conf進行寫操作。本系統會對寫內容進行控制,使寫操作無效。可以看出,客戶機操作系統恢復工作量及其復雜性有所降低。

XOR.DDoS開始執行時會進行自我復制,實現方式是在usr/bin、/bin、/tmp下創建文件并寫入二進制內容。處于控制之下的進程將無法寫入數據到目標文件中。

4.2 性能測試

性能測試用來分析本系統在性能方面的表現。時間測試使用gettimeofday()函數。

4.2.1 系統運行前后對比測試

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

評價指標為t1和t2,分別表示系統運行前后的進程完整執行時間。其計算公式如下:

t1=tf-ts+te1-ts

(1)

t2=tf-ts+te2-tr

(2)

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

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

如果是漏報場景,節省的時間與未采取措施時進行系統回滾的時間有關,而改進之后就不需要系統回滾,因此具有性能優勢。

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

4.2.2 時間消耗測試

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

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

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

t1=te1-ts1

(3)

t2=te2-ts2

(4)

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

圖8 不同時刻發生警報的性能影響

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

5 結語

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

)

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

[2] 項國富, 金海, 鄒德清, 等. 基于虛擬化的安全監控[J]. 軟件學報, 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。 基金項目:國家自然科學基金資助項目(61100228);國家863計劃項目(2012AA013101);中國科學院戰略性先導專項(XDA06030601,XDA06010701)。

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

1001- 9081(2017)04- 0986- 07

10.11772/j.issn.1001- 9081.2017.04.0986

TP309.3

A