2. 中国科学院大学 计算机与控制学院, 北京 100049;
3. 中国科学院大学 网络空间安全学院, 北京 100049
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
随着虚拟化技术的不断发展, 云计算应用越来越广泛。解决面向云平台的安全问题、保障使用云服务的客户机系统安全成为当下的研究热点之一。国内外有很多研究者提出基于虚拟化技术或操作系统的安全防护技术方案。基于虚拟化架构的安全功能的研究已有了一些学术成果, 主要包括实现恶意代码的检测和分析、完整性监控、入侵检测 (如基于主机的入侵检测系统模型[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 虚报场景 Figure 1 Scenario of false positive |
针对这个场景, 本文方案采取的策略是从t1时刻开始捕获并记录该进程的后续行为。在t2时刻, 误报被确定, 判断该进程并非恶意进程, 此时就不必因之前的虚报杀死了该进程而重新运行它, 而是通过释放该进程相关行为, 使该进程能够在正确状态下正常运行下去, 以此避免了对客户机可用性造成的影响。见图 2。在t2时刻后不需要执行t1时刻前执行过的行为。
|
图 2 改进后的虚报场景 Figure 2 Scenario of false positive after improvement |
2) 决策为A发生误报 (即认为A发生虚报) 而放过了产生该威胁的进程。假如该进程确实是恶意进程, 则在一般情况下, 该进程就会进一步对系统造成破坏。当t2时刻发现漏报时, 破坏行为往往已经完成, 此时就需要通过系统回滚来恢复系统, 见图 3。
|
图 3 漏报场景 Figure 3 Scenario of false negative |
图 3中的横轴代表进程的状态, 实线表示正在运行, 虚线表示暂停。将系统中的进程分成三类, 分别是正常进程、受感染进程和恶意进程。一些进程由于和恶意进程存在交互而受到感染。由于t1到t2时刻内, 恶意进程已经对系统造成实质性影响, 因此需要暂停一段时间进行系统恢复。在这段时间内, 正常进程和受感染进程均处于暂停状态, 系统可用性受到影响。
针对这个场景, 本文方案采取的策略是控制进程行为不会对系统造成实质性影响 (例如修改系统文件、创建相关恶意进程)。在t2时若发现t1时刻A并非虚报, 仅需杀死该进程即可恢复系统安全运行, 而不需要将系统回滚, 以此避免了对客户机的可用性造成的影响。如图 4所示, 恶意进程以外的进程始终处于运行状态。
|
图 4 改进后的漏报场景 Figure 4 Scenario of false negative after improvement |
总结以上描述, 本研究希望针对以下问题进行解决:在难以判断某时刻是否发生误报、误报为虚报还是漏报时, 采取措施使得不论是何种情况, 均能使进程持续不断地运行, 并且保证进程不对系统造成任何威胁; 在之后的某个时刻, 误报类型被发现时, 能够快速恢复系统的正常运行状态。
2 方案设计 2.1 语义解析为实现虚拟化监控层 (Virtual Machine Monitor, VMM) 对上层客户机进程行为控制, 需要在VMM中对客户机进程行为信息进行捕获。而VMM获取的数据缺乏语义, 因此需要解决如何从VMM正确解析客户机行为信息的问题。
本研究采用系统调用行为序列作为进程行为控制的基础。利用文献[11]提出的在VMM下捕获客户机系统调用行为信息的方法, 对客户机进程的行为信息进行捕获。捕获行为包括文件操作和进程操作, 具体内容见表 1。
|
表 1 捕获行为 Table 1 Operations of being captured |
捕获到的行为信息包括系统调用号、进程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 行为执行对流程的影响 Figure 5 Effect of operations on the control flow |
因此这种方案只能在少部分情况下起到作用, 即：当受控行为完全独立, 对该进程后续行为流程完全没有影响时, 此方案才能保证进程正确的运行状态。
方案2 在t1时刻, 利用进程备份来保存运行状态。当进程被发现虚报时, 通过快速达到所保存的运行状态来恢复进程, 并让这个进程继续完成该时间点之后的行为。此方案对比方案1虽然有一些性能损失, 但是它在通用性方面没有局限性。此方案能够保证任何情况下进程的正确运行状态, 并且不需要额外记录进程行为, 从而减少了空间开销。
本文采用方案2解决进程的行为释放问题。在进程有可能被虚报为恶意进程时, 记录下该时刻的进程状态, 在虚报被发现时, 就从记录的时刻开始恢复进程的行为, 以使进程快速恢复到应有的运行状态, 而无需重新运行。这个过程的实现不需要改动客户机的内核代码。实现方式是在一个处于用户态的陷入时刻, 对该进程注入系统调用。
3 系统实现整体系统结构如图 6。本系统将云平台分为两部分:一部分是云平台之上的客户机；另一部分是虚拟化架构中的VMM。本系统在VMM层中添加捕获模块、行为控制模块、行为释放模块, 不对客户机作任何更改。
|
图 6 系统结构 Figure 6 System architecture |
当一个安全工具产生报警时, 本系统将接收到该信号 (安全工具如何发送信号给本系统不是本研究的重点, 以下实验将以来自dom0的超级调用来模拟来自安全工具的报警信号), 然后执行以下流程:
1) 将产生威胁的进程 (由安全工具提供) 标为可疑进程, 将其进程id传递给捕获模块和行为释放模块。
2) 行为释放模块对该进程进行备份。
3) 捕获模块对该进程行为进行捕获, 并将捕获到的行为传递给行为控制模块。
4) 行为控制模块对进程行为进行控制, 并根据行为类型形成进程间依赖关系。
5) 当误报被发现时, 若为漏报, 则只需杀死该进程和备份进程即可; 若为虚报, 则将消息发送给行为释放模块, 该模块负责恢复进程状态, 使进程能够持续不断运行。
3.2 捕获模块捕获模块负责捕获客户机中进程的系统调用行为, 并以此为根据形成依赖关系。捕获行为的时刻发生在该行为执行之前, 也就是sysenter/int80指令执行完毕, 下一条指令执行之前的时刻。在该时刻通过控制客户机陷入到VMM中, 从VMM获取客户机内存中重要结构, 如当前进程的任务状态段 (Task State Segment, TSS), 得到该进程task_struct结构, 以获得进程相关信息, 并通过读取寄存器及内存中栈的内容, 获取系统调用号以及参数信息。
3.3 行为控制模块行为控制模块负责对受监控的进程进行后续行为的控制, 并维持该进程以及相关进程的正常运行。当捕获模块捕获到一个来自受控进程或与之存在依赖关系的进程行为时, 交给行为控制模块进行处理。该模块首先判断当前行为是否是一个需要被修改的行为。若不是, 则不作处理; 若是, 则按照表 2进行行为控制。修改结束之后返回给客户机, 客户机将不会察觉到VMM对该进程的任何修改, 并继续正常运行该进程。
|
|
表 2 各行为控制方式 Table 2 Control of operations |
该模块同时负责根据进程行为形成进程之间的依赖关系, 行为控制见表 2。如write系统调用, 控制方式为在该系统调用执行之前将写的内容清零; 对于mmap系统调用, 当多个进程mmap同一个文件时, 就会产生进程间依赖, 此时的控制方式是允许其执行, 同时记录产生的依赖关系。类似的还有write/read产生的进程间依赖, 控制方式与mmap相同。fork和clone也会产生进程间依赖, 但控制方式是不允许其执行, 这里通过在该系统调用执行之前, 修改其系统调用号为一个无副作用的系统调用 (如getpid ()) 来实现控制。pipe由于经常和fork捆绑使用, 当fork无法执行时, pipe也无法起到应有的效果, 因此这里允许其执行。
3.4 行为释放模块行为释放模块负责对进程进行备份处理, 并将虚报为恶意的进程释放掉, 以快速恢复其正常运行状态。
当某一进程开始处于控制之下, 或某一进程与受控进程产生依赖关系时, 则交给行为释放模块进行该进程状态的备份。对进程进行备份的方法是, 在该进程处于用户态时主动陷入到VMM中, 此时对该进程注入一个fork系统调用, 以实现进程备份。注入fork系统调用的方法是修改进程代码段中的4个字节, 将原代码内容修改为int3、int80、int3三条指令。其中：int80指令用来注入系统调用；int3指令用来产生客户机到VMM的主动陷入。修改代码时需要保存该位置原来的代码内容, 以便之后的恢复工作。代码被修改后, 还需要设置eax寄存器的值为fork系统调用号, 这样, 当客户机执行到int80指令时, 就能够正确执行fork系统调用完成进程的备份。由于eax寄存器也被修改, 因此这里同样需要将原本的eax寄存器值记录下来。Fork Injecting算法如下。
算法1 Fork Injecting。
1) if (modify= =1) /*the code had been injected */
2) {
3) save the value of rax;
4) modify eax to fork system call number;
5) }
6) else /*the code had not been injected */
7) {
8) fetch_content (eip); /*fetch the content of eip */
9) save the value of eax;
10) modify eax to fork system call number;
11) inject four bytes code;
12) turn on the int3 interrupt;
13) }
14) modify the eip to "int80";
fork产生的子进程作为备份进程, 应该暂停在此状态下, 而不应该被调度运行; 当行为需要被释放时, 才解除其暂停状态。这里采用的方法是, 如果检测到是子进程被调度执行, 则注入sched_yield系统调用使其睡眠, 注入的方法同fork, 修改eax寄存器为sched_yield系统调用号, 并修改eip寄存器到int80指令的位置即可。
另外, 由于所修改的代码段部分往往是被多个进程所共享的, 因此修改的代码有可能被其他无关进程所执行, 而其他进程应执行原来的代码, 而不应该执行修改后的代码, 因此这里加入两个int3指令, 以对客户机陷入VMM时正在运行进程的行为流程进行控制。由于有两个int3指令, 因此从int3陷入的情况分为两种:从第一个int3陷入 (1st int3) 以及从第二个int3陷入 (2nd int3)。不同陷入情况的处理措施见图 7。
|
图 7 int3陷入后的处理 Figure 7 Process after int3 trap |
从第一个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 2nd Int3 Child Process Handler。
1) if (release= =0) /*cannot be released */
2) {
3) modify eip to 1st int3;
4) modify eax to sched_yield system call number;
5) }
6) else /*need to be released */
7) {
8) if (all_released= =0) /*some child processes have not been released */
9) {
10) if (current process has not been released)
11) simulate_4pop_on2ndint3;
12) else
13) simulate_4pop_on1stint3;
14) }
15) else /*all the child processes have been released */
16) {
17) modify eip;
18) recover the original code;
19) }
20) }
4 测试和分析以Xen-4.4.0作为架构原型, Ubuntu 14.04.1作为宿主机, 内核版本为3.16.0-30-generic; centos release 6.6作为客户机, 内核版本为2.6.32-504.el6.i686。CPU为Intel i7-4790 3.60 GHz, 内存4 GB。
4.1 效果测试实验中有两个监控工具A和B共同监控客户机, 当前客户机中正在运行某一目标进程。t1时刻A对该进程 (目标进程) 产生报警, B未产生报警, 则出现以下两种场景。
4.1.1 虚报场景A发生虚报, 即目标进程并非一个恶意进程, 在t2时刻发现虚报 (这里通过dom0使用超级调用发送信号来通知虚报被发现)。该目标进程被报警之后还执行了其他操作, 并与其他进程形成了依赖关系。实验中本系统在报警过后能够正确记录各个进程依赖关系, 并对相关进程的行为进行控制。在t2时刻虚报被发现时, 能够使相关进程继续正常执行, 而不需要重新执行。实验中捕获到的行为及数量如表 3所示。
|
|
表 3 各行为控制效果 Table 3 Control effect of operations |
B发生漏报, 即目标进程是一个恶意进程, 在t2时刻发现漏报。由于目标进程行为受到控制, 并未对系统进行实质性破坏, 因此此时仅需杀死该进程及相关进程即可, 而不需要进行系统暂停、恢复、回滚等操作。实验样本有Tsunami、Kaiten、XOR.DDoS。
Tsunami, 从行为上分析, 该程序开始执行之后需要clone产生子进程, 该子进程与攻击主机建立socket连接, 并发送数据。接收到攻击主机的命令后, 作为僵尸网络中的一台主机, 被入侵主机对目标发起DoS (Denial of Service)、SYN flood等攻击。在本实验中, 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, 分别表示系统运行前后的进程完整执行时间。其计算公式如下:
| $ {t_1} = {\rm{ }}tf - ts{\rm{ }} + {\rm{ }}t{e_1} - ts $ | (1) |
| $ {t_2} = {\rm{ }}tf - ts{\rm{ }} + {\rm{ }}t{e_2} - tr $ | (2) |
实验结果见表 4。从改进前后时间百分比可以看出, 改进之后虚报情况对客户机的时间开销有所降低。
|
|
表 4 虚报场景改进前后时间对比 Table 4 Comparison of time before and after improvement of false positive scenario |
如果是漏报场景, 节省的时间与未采取措施时进行系统回滚的时间有关, 而改进之后就不需要系统回滚, 因此具有性能优势。
以上结果表明, 相对于未采取措施的情况, 本系统能够在安全工具发生误报时, 避免回滚、恢复等操作带来的时间开销, 减少了误报处理时间, 从而降低误报对客户机可用性造成的影响。
4.2.2 时间消耗测试在进程运行过程中, 警报可能在任何时刻产生。表 5是一个进程样本在运行过程中不同时刻S1~S4发生警报时的运行时间比较, 从S1到S4发生警报的时刻依次接近程序运行结束。
|
|
表 5 不同时刻发生警报时的运行时间比较 Table 5 Comparison of time of alarms at different times |
ts1和te1分别是没有警报产生时该进程的运行起始时间和结束时间, ts2和te2分别是有警报产生时该进程的运行起始时间和结束时间。t1和t2分别是没有警报产生和有警报产生时的运行时间, 可用式 (3)、(4) 表示。
| $ {t_1} = t{e_1} - t{s_1} $ | (3) |
| $ {t_2} = t{e_2} - t{s_2} $ | (4) |
对多个进程进行上述实验得到图 8。图 8中:S1~S4为发生警报的4个相对时间, 满足S1 < S2 < S3 < S4, 且S1~S4均在进程运行时间段内。
|
图 8 不同时刻发生警报的性能影响 Figure 8 Performance impact of alarms at different times |
图 8中的折线体现了系统运行前后, 进程执行时间随报警产生时刻的变化。从图 8中结果可以看出, 进程运行中发生警报的时刻越靠后, 本系统对进程性能影响越小。这是由于发生警报时, 进程开始处于控制之下, 之后受控进程的系统调用行为会使虚拟机发生VMM陷入, 环境的切换带来主要的时间开销。因此, 警报时刻越靠后, 需要控制的行为越少, 本系统性能表现越良好。
5 结语本文针对安全工具对云平台之上的客户机可用性带来的影响问题提出一种解决方案。该方案避免安全工具因误报而进行系统恢复、回滚等操作, 确保在误报发生后, 客户机系统仍然能够持续不断地运行, 并维持正确的运行状态。实验结果表明, 该方案在安全工具误报发生时能够正确控制可疑进程, 避免该进程对系统造成实质性影响, 并能保证该进程正确运行状态; 在误报发现时, 系统能够快速恢复到应有的状态。在性能方面本文方案也具有良好的表现。因此, 本文方案能够达到预期效果, 降低安全工具对云平台之上的客户机可用性造成的影响。下一步将增加网络相关操作的监控、完成备份进程对客户机透明等工作。
| [1] | LAUREANO M, MAZIERO C, JAMHOUR E. Protecting host-based intrusion detectors through virtual machines[J]. Computer Networks, 2007, 51 (5) : 1275-1283. doi: 10.1016/j.comnet.2006.09.007 |
| [2] | 项国富, 金海, 邹德清, 等. 基于虚拟化的安全监控[J]. 软件学报, 2012, 23 (8) : 2173-2187. ( XIANG G F, JIN H, ZOU D Q, et al. Virtualization-based security monitoring[J]. Journal of Software, 2012, 23 (8) : 2173-2187. doi: 10.3724/SP.J.1001.2012.04219 ) |
| [3] | JIANG X, WANG X, XU D. Stealthy malware detection through VMM-based out-of-the-box semantic view reconstruction[C]//Proceedings of the 14th ACM Conference on Computer and Communications Security. New York: ACM, 2007: 128-138. http://dl.acm.org/citation.cfm?id=1315262 |
| [4] | DINABURG A, ROYAL P, SHARIF M, et al. Ether: malware analysis via hardware virtualization extensions[C]//Proceedings of the 15th ACM Conference on Computer and Communications Security. New York: ACM, 2008: 51-62. http://dl.acm.org/citation.cfm?id=1455779 |
| [5] | LANZI A, SHARIF M I, LEE W. K-Tracer: a system for extracting kernel malware behavior[EB/OL].[2016-03-10]. https://www.isoc.org/isoc/conferences/ndss/09/pdf/12.pdf. |
| [6] | XUAN C, COPELAND J, BEYAH R. Toward revealing kernel malware behavior in virtual execution environments[C]//RAID 2009: Proceedings of the 12th International Symposium on Recent Advances in Intrusion Detection. Berlin: Springer, 2009: 304-325. http://link.springer.com/chapter/10.1007/978-3-642-04342-0_16 |
| [7] | SESHADRI A, LUK M, QU N, et al. SecVisor: a tiny hypervisor to provide lifetime kernel code integrity for commodity OSes[C]//SOSP 2007: Proceedings of Twenty-first ACM SIGOPS Symposium on Operating Systems Principles. New York: ACM, 2007: 335-350. http://dl.acm.org/citation.cfm?id=1294294 |
| [8] | PAYNE B D, LEINHOS M. LibVMI[EB/OL].[2016-08-29]. http://libvmi.com. |
| [9] | PAYNE B D, CARBONE M, SHARIF M, et al. Lares: an architecture for secure active monitoring using virtualization[C]//SP 2008: Proceedings of the 2008 IEEE Symposium on Security and Privacy. Piscataway, NJ: IEEE, 2008: 233-247. http://ieeexplore.ieee.org/abstract/document/4531156/ |
| [10] | ZHANG X, LI Q, QING S, et al. VNIDA: building an IDS architecture using VMM-based non-intrusive approach[C]//WKDD 2008: Proceedings of the First International Workshop on Knowledge Discovery and Data Mining. Piscataway, NJ: IEEE, 2008: 594-600. |
| [11] | SHARIF M I, LEE W, CUI W, et al. Secure in-VM monitoring using hardware virtualization[C]//Proceedings of the 16th ACM Conference on Computer and Communications Security. New York: ACM, 2009: 477-487. http://dl.acm.org/citation.cfm?id=1653720 |
| [12] | XI X, JIA X, LIU P. SHELF: preserving business continuity and availability in an intrusion recovery system[C]//ACSAC 2009: Proceedings of the 2009 Annual Computer Security Applications Conference. Piscataway, NJ: IEEE, 2009: 484-493. http://ieeexplore.ieee.org/abstract/document/5380701/ |
| [13] | WU R, CHEN P, LIU P, et al. System call redirection: a practical approach to meeting real-world virtual machine introspection needs[C]//Proceedings of the 201444th Annual IEEE/IFIP International Conference on Dependable Systems and Networks. Piscataway, NJ: IEEE, 2014: 574-585. http://ieeexplore.ieee.org/abstract/document/6903612/ |