楊立博

(山東財(cái)經(jīng)大學(xué)經(jīng)濟(jì)學(xué)科實(shí)驗(yàn)教學(xué)中心 山東 250014）

1 虛擬化技術(shù)

作為當(dāng)今云計(jì)算的核心技術(shù)之一，虛擬化技術(shù)因其穩(wěn)定性、安全性和平臺(tái)資源利用率高等特性,得到了越來(lái)越廣泛的應(yīng)用。

虛擬化技術(shù)產(chǎn)生于1960年代,IBM在其大型主機(jī)系統(tǒng)VM/370正式啟用該技術(shù)。當(dāng)時(shí)硬件資源十分昂貴和稀缺,虛擬化技術(shù)能夠很好地解決有限的計(jì)算資源被充分利用的問(wèn)題。但之后因?yàn)橛布夹g(shù)的快速發(fā)展以及分時(shí)操作系統(tǒng)的出現(xiàn)，虛擬化技術(shù)進(jìn)入慢速發(fā)展階段。隨著多核處理器的出現(xiàn),計(jì)算機(jī)處理能力得到了很大的提升,這導(dǎo)致服務(wù)器的利用率快速下降。虛擬化技術(shù)能夠在保證提供正常服務(wù)的情況下提高服務(wù)器的利用率,特別是隨著云計(jì)算概念的提出,使得虛擬化技術(shù)再次成為熱門的研究課題。

虛擬化技術(shù)、超線程技術(shù)以及多任務(wù)它們?nèi)叩母拍钣泻艽髤^(qū)別。虛擬化指的是多個(gè)虛擬機(jī)在同一個(gè)物理機(jī)器上同時(shí)運(yùn)行,并且每個(gè)虛擬機(jī)上運(yùn)行一個(gè)同時(shí)運(yùn)行多個(gè)應(yīng)用程序的操作系統(tǒng);超線程技術(shù)是指利用單CPU來(lái)模擬多CPU的運(yùn)行效果;多任務(wù)是指在操作系統(tǒng)中同時(shí)并行運(yùn)行多個(gè)程序。

虛擬器管理器能夠有效地對(duì)多個(gè)虛擬機(jī)實(shí)施隔離,已經(jīng)被廣泛地應(yīng)用于多個(gè)方面。根據(jù)抽象層次的不同,虛擬化技術(shù)可以分為5類:指令級(jí)虛擬化、硬件級(jí)虛擬化、操作系統(tǒng)級(jí)虛擬化、運(yùn)行庫(kù)級(jí)虛擬化和編程語(yǔ)言級(jí)虛擬化。不同類別的虛擬化技術(shù)的實(shí)現(xiàn)原理都是一樣的,即利用某種特殊的手段對(duì)底層資源進(jìn)行管理和分配,向上層提供抽象出來(lái)底層資源。

虛擬化大體分為完全虛擬化、部分虛擬化和操作系統(tǒng)層虛擬化，完全虛擬化即指在不區(qū)分物理環(huán)境和虛擬環(huán)境的前提下，虛擬機(jī)管理器完全復(fù)制底層物理硬件。

2 基于完全虛擬化的安全監(jiān)控技術(shù)

由于惡意軟件層出不窮,使得向用戶提供服務(wù)的應(yīng)用系統(tǒng)面臨日益增長(zhǎng)的安全威脅。基于系統(tǒng)內(nèi)部的安全監(jiān)測(cè)技術(shù)和基于網(wǎng)絡(luò)監(jiān)控的安全監(jiān)測(cè)技術(shù)已經(jīng)不能夠適應(yīng)這種需求,因此選擇采用虛擬化技術(shù)解決云計(jì)算環(huán)境下應(yīng)用系統(tǒng)中存在的安全隱患。

與傳統(tǒng)架構(gòu)相比較，虛擬化架構(gòu)在安全方面具有明顯優(yōu)勢(shì)：虛擬化架構(gòu)中的虛擬機(jī)管理器介于真實(shí)硬件平臺(tái)和操作系統(tǒng)間，特權(quán)級(jí)高于操作系統(tǒng)，并且虛擬化架構(gòu)隔離性和可信計(jì)算基都更為理想；傳統(tǒng)架構(gòu)中的操作系統(tǒng)只擁有整個(gè)硬件平臺(tái)的管理權(quán)限而已。

安全監(jiān)控是指通過(guò)從網(wǎng)絡(luò)和計(jì)算機(jī)中獲得的事件信息來(lái)分析系統(tǒng)和用戶的行為，從而增強(qiáng)網(wǎng)絡(luò)和計(jì)算機(jī)系統(tǒng)的安全性，目前常見(jiàn)的有防火墻、入侵檢測(cè)等等。

根據(jù)安全監(jiān)控實(shí)現(xiàn)技術(shù)可將基于完全虛擬化的安全監(jiān)控及其相關(guān)研究工作分為以下兩類：

2.1 外部監(jiān)控，即使用虛擬機(jī)管理器攔截機(jī)中發(fā)生的異常事件，在虛擬機(jī)外部進(jìn)行事件安全性檢測(cè)。

2.2 內(nèi)部監(jiān)控，即通過(guò)虛擬機(jī)管理器加載和保護(hù)的內(nèi)核模塊進(jìn)行異常事件攔截，確保計(jì)算機(jī)系統(tǒng)和網(wǎng)絡(luò)的安全。

一般虛擬監(jiān)控系統(tǒng)的設(shè)計(jì)原則都在保證虛擬機(jī)監(jiān)控器的透明性、實(shí)時(shí)性、安全性和有效性，以防虛擬機(jī)監(jiān)控器存在安全漏洞、隔離性受到破壞以及出現(xiàn)虛擬機(jī)逃逸等問(wèn)題。目前主流的虛擬機(jī)監(jiān)控器有XEN和VMware等。

3 存在問(wèn)題及解決方法探析

威脅基于完全虛擬化的安全監(jiān)控技術(shù)的因素主要來(lái)自于三個(gè)方面：內(nèi)核、內(nèi)核可加載模塊和應(yīng)用進(jìn)程。首先,入侵程序通常以為內(nèi)核可加載模塊存在,會(huì)修改內(nèi)核代碼或數(shù)據(jù),從而篡改內(nèi)核的控制流。其次,惡意的內(nèi)核可加載模塊通常具有隱藏特性,使得系統(tǒng)用戶無(wú)法察覺(jué)。最后,入侵程序感染系統(tǒng)中的應(yīng)用進(jìn)程,使得其正常行為發(fā)生改變。常規(guī)的安全監(jiān)控工具與被監(jiān)控的程序位于同一層次,如果被監(jiān)控的惡意程序的權(quán)限高于監(jiān)控工具,那么惡意程序就完全有可能繞過(guò)或者破壞監(jiān)控工具,從而導(dǎo)致監(jiān)控失效。

3.1 內(nèi)核

內(nèi)核作為操作系統(tǒng)的核心程序，由代碼和數(shù)據(jù)構(gòu)成。操作系統(tǒng)安全最重要的一點(diǎn)就是內(nèi)核數(shù)據(jù)的完整性，為此保證內(nèi)核的完整性成為安全監(jiān)控的關(guān)鍵。

內(nèi)核容易受到內(nèi)核對(duì)象鉤子和動(dòng)態(tài)內(nèi)核對(duì)象操作的威脅、修改數(shù)據(jù)，為此我們必須建立起完整的內(nèi)核保護(hù)模塊。圖1為內(nèi)核保護(hù)模塊結(jié)構(gòu)圖。

圖1 內(nèi)核保護(hù)模塊結(jié)構(gòu)圖

3.2 內(nèi)核可加載模塊

惡意的內(nèi)核可加載模塊通常會(huì)隱藏自身,使得入侵行為不被系統(tǒng)用戶察覺(jué)。其最常見(jiàn)的隱藏方式就是該模塊加載到內(nèi)存后將它自己從內(nèi)核可加載模塊的列表中摘除,但并沒(méi)有將它從內(nèi)核內(nèi)存中卸載。然而與內(nèi)核可加載模塊同層次的監(jiān)控工具并不能很好的檢測(cè)到具有隱藏特性的惡意內(nèi)核可加載模塊,其監(jiān)控仍存在漏洞。

隱藏內(nèi)核可加載模塊檢測(cè)的關(guān)鍵在于交叉視圖對(duì)比技術(shù)，在虛擬機(jī)監(jiān)控器層次訪問(wèn)虛擬機(jī)系統(tǒng)中的/proc/modules文件來(lái)獲得不可信的內(nèi)核可加載模塊列表。虛擬機(jī)監(jiān)控器層次視圖,也就是可信的內(nèi)核可加載模塊列表。我們知道內(nèi)核模塊在創(chuàng)建和卸載時(shí)會(huì)進(jìn)行系統(tǒng)調(diào)用,進(jìn)而由內(nèi)核分配它所需資源,因此虛擬機(jī)層次視圖的構(gòu)建可以通過(guò)虛擬機(jī)監(jiān)控器截獲客戶操作系統(tǒng)的系統(tǒng)調(diào)用來(lái)實(shí)現(xiàn)。最后將不可信視圖與可信視圖進(jìn)行交叉對(duì)比,檢測(cè)出隱藏的內(nèi)核可加載模塊。

4 結(jié)束語(yǔ)

傳統(tǒng)環(huán)境下,安全監(jiān)控是基于相對(duì)穩(wěn)定的網(wǎng)絡(luò)和系統(tǒng)環(huán)境。在虛擬計(jì)算環(huán)境下,虛擬機(jī)管理器可以對(duì)操作系統(tǒng)運(yùn)行的多個(gè)虛擬機(jī)進(jìn)行隔離。因此利用虛擬機(jī)管理器將安全監(jiān)控系統(tǒng)部署在管理器上,不僅可以增強(qiáng)監(jiān)控系統(tǒng)的安全性,同時(shí)相對(duì)于目標(biāo)虛擬機(jī)而言具有透明性。然而,由于虛擬機(jī)本身所具有的動(dòng)態(tài)性和多樣性,這也給安全監(jiān)控帶來(lái)了巨大的挑戰(zhàn)，仍需要后續(xù)技術(shù)發(fā)展進(jìn)行改進(jìn)。

[1]Smith J E,Nair R, The Architecture of Virtual Machines[J].IEEE Computer, 2005, 38(5):32-38.