软件看门狗系统及方法概要Word格式.docx
《软件看门狗系统及方法概要Word格式.docx》由会员分享,可在线阅读,更多相关《软件看门狗系统及方法概要Word格式.docx(15页珍藏版)》请在冰豆网上搜索。
2、根据权利要求1所述的系统,其特征在于,所述恢复指令,包括:
启动某个进程,终止某个进程,启动虚拟机,重启虚拟机,从镜像文件恢复虚拟机。
3、根据权利要求1所述的系统,其特征在于,所述策略模块,还用于根据用户输入的进程配置信息确定关键用户进程。
4、一种基于权利要求1至3中任一软件看门狗系统的检测方法,其特征在于,该方法包括:
KVM上的虚拟机监控器获取物理主机的内存信息;
语义重构模块根据虚拟机监控器获取的物理主机的内存信息重构出客户虚拟机上的语义信息;
故障检测模块根据语义重构模块重构出的客户虚拟机上的语义信息检测客户虚拟机的隐藏进程、关键用户进程和系统调用的完整性,输出检测结果;
策略模块根据故障检测模块的检测结果和用户配置的恢复策略,生成恢复指令;
恢复模块根据策略模块产生的恢复指令进行恢复操作;
5、根据权利要求4所述的方法,其特征在于,所述恢复指令,包括:
6、根据权利要求4所述的方法,其特征在于,所述方法还包括,策略模块根据用户输入的进程配置信息确定关键用户进程。
说明书
一种软件看门狗系统及方法
技术领域
本发明涉及安全技术领域,尤其涉及一种软件看门狗系统及方法。
背景技术
传统的基于硬件的看门狗系统,在系统进入不可恢复错误时,能产生一个不可屏蔽中断来通知系统自动重启,只有相应的复位信号才能清除它。
以此来达到保证系统的高可用性,主要应用领域是嵌入式系统。
传统的基于硬件的看门狗系统,不但造价较高,而且功能单一,不够通用,必须提供编程接口来进行“喂狗”操作,增加了系统的复杂性和耦合度。
发明内容
本发明提供了一种软件看门狗系统及方法,能够同时监控多个客户虚拟机,操作简单,处理高效。
第一方面,本发明提供了一种软件看门狗系统,该系统包括:
进一步地,所述恢复指令,包括:
进一步地,所述策略模块,还用于根据用户输入的进程配置信息确定关键用户进程。
第二方面,本发明提供了一种基于第一方面中任一软件看门狗系统的检测方法,该方法包括:
进一步地,所述方法还包括,策略模块根据用户输入的进程配置信息确定关键用户进程。
通过本发明实施例提供的一种软件看门狗系统及方法,能够通过一个宿主虚拟机来同时监控多个客户虚拟机,并且操作简单,处理高效。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是本发明实施例提供的一种软件看门狗系统的结构示意图;
图2是本发明实施例提供的一种基于实施例1中的软件看门狗系统的检测方法的流程图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例,基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本发明保护的范围。
实施例1:
在一台物理主机上可以同时安装多个虚拟机,其中一个为宿主虚拟机,其余的为客户虚拟机,通过宿主虚拟机能够对客户虚拟机进行监控。
本发明提供了一种软件看门狗系统,该系统建立在以宿主虚拟机为单位的虚拟化系统架构上,该系统架构将看门狗中的故障检测恢复系统放置在被检测的客户虚拟机之外,该系统可以检测多台客户虚拟机。
参见图1,该系统包括:
KVM(Kernel-basedVirtualMachine,基于内核的虚拟机),以及安装于KVM上的语义重构模块101、故障检测模块102、策略模块103、恢复模块104;
KVM上的虚拟机监控器105,用于获取物理主机的内存信息;
语义重构模块101,用于根据虚拟机监控器105获取的物理主机的内存信息重构出客户虚拟机上的语义信息;
故障检测模块102,用于根据语义重构模块101重构出的客户虚拟机上的语义信息检测客户虚拟机的隐藏进程、关键用户进程和系统调用的完整性,输出检测结果;
策略模块103,用于根据故障检测模块102的检测结果和用户配置的恢复策略,生成恢复指令;
恢复模块104,用于根据策略模块103产生的恢复指令进行恢复操作;
通过本发明实施例提供的一种软件看门狗系统,能够通过一个宿主虚拟机来同时监控多个客户虚拟机,并且操作简单,处理高效。
所述恢复指令,包括:
所述策略模块103,还用于根据用户输入的进程配置信息确定关键用户进程。
其中,虚拟机监控器负责创建抽象层来虚拟化一个物理主机的硬件并把它划分成逻辑上隔离的虚拟主机。
虚拟机监控器能够保证即使被监控的虚拟主机被入侵,也能够防止进一步入侵到拥有特权级的宿主虚拟机上的应用程序,因此,不可能入侵到虚拟机故障检测和恢复程序。
虚拟机监控器为了控制其上的客户虚拟机,对客户虚拟机拥有完全的控制权限,包括内存,CPU寄存器和I/O操作。
虚拟机监控器拥有的高优先级允许对客户虚拟机的完全监控,也让恶意代码很难逃过监测。
虚拟机监控器可以监督虚拟主机的操作,能够干预请求,例如,特权级CPU指令,因为它介于客户虚拟机和宿主虚拟机之间。
在被监控虚拟机内部,检测系统可以轻易获取正在执行的进程、磁盘上文件等操作系统级别的高级语义信息,而在被监控虚拟机外部,检测系统仅能获取寄存器值、内存数据、磁盘块数据或当前指令执行流等低等级信息,这种语义的断层影响了检测功能的有效实施。
为了解决语义断层的问题,需要重构虚拟机内部的高级语义信息。
本系统更加关注进程信息的刻画,如以进程控制块为模板,重构进程控制块信息,进而获取进程名、进程号以及内存地址空间等。
本系统在虚拟机外部构建进程控制块链表,并通过交叉视图的方式比较外部重构进程列表和内部汇报进程列表的差异,以此确定是否存在隐藏进程。
然而直接操作内核对象类攻击可以将待隐藏进程控制块从进程队列中摘链,因而该方法可能会出现漏检现象。
本系统提供了相应的隐藏进程的处理机制,可以在最大程度上保证系统的自动恢复能力,从而提高安全性和自动化。
利用虚拟机自省机制,将检测工具与被监控系统隔离在不同的虚拟机中,通过语义重构,在虚拟机外部的检测软件发现虚拟机中的恶意软件,然后根据不同的恢复策略进行虚拟机的恢复,来确保在虚拟机发生故障的情况下,软件看门狗可以自动进行恢复,保证系统的正常运行,同时该系统只要在宿主虚拟机上进行配置就可以,在客户虚拟机上不需要安装任何组件,提高整个系统的安全性和可靠性。
本发明利用虚拟机监控器的隔离特性和高特权级特性,获得客户虚拟机的内存信息,获得客户虚拟机的内存信息后,然后通过客户虚拟机系统的操作系统的内存布局和操作系统的常量参数,来获得客户虚拟机的操作系统级别的内核数据结构信息。
通过这些数据结构,可以获得客户虚拟机的一些信息,如进程列表,内核模块列表等。
当故障检测模块运行时,可以利用客户虚拟机的进程信息,来判断是否有隐藏进程,同时可以检测关键进程是否在运行。
如果关键进程缺失,同时发现隐藏进程,那么说明当前这个系统已经被恶意软件入侵。
如果故障检测模发现系统调用被修改,也说明当前系统中有恶意软件。
策略模块根据故障检测模发现的系统异常情况和用户配置的恢复策略来进行决策,输出恢复指令。
恢复策略可以为:
如果用户进程缺失,可以简单地启动用户进程,如果操作系统调用被破坏,可以重启虚拟机;
如果重启之后还是有原来的问题,那么就采用从镜像文件恢复虚拟机的方式来解决问题。
恢复模块执行策略模块产生的恢复指令,它可以启动,停止某个进程,可以关闭,启动虚拟机,也可以从镜像来恢复虚拟机。
其中,恢复策略可以包括两个过程:
虚拟机级别的恢复:
利用虚拟机可以动态地创建、撤销以及在各个物理平台之间进行迁移的特性,进行虚拟机级别的恢复,例如:
启动虚拟机,重启虚拟机,从镜像文件恢复虚拟机。
进程级别的恢复:
如果用户进程遭到破坏可以进行进程级别的恢复,尝试重启用户进程,例如:
启动某个进程,终止某个进程。
通过以上两个级别的恢复过程来确保在虚拟机发生故障的情况下,可以自动进行恢复,重新正常运行,保证系统的高可靠性和高安全性。
对于语义重构模块,由于本系统的故障检测模块与被监控系统隔离在不同的虚拟机中,因此需要解决语义鸿沟问题。
通过语义重构,将原始的物理主机的内存信息重构出客户虚拟机操作系统级别的语义。
对于故障检测模块,如果有恶意软件杀掉了用户程序,可以用关键进程运行状态来检测出来。
如果恶意软件在系统调用中挂了钩子,系统调用完整性检查可以检查出来。
如果恶意软件将自己隐藏出来了,隐藏进程检测部分可以检测出这个进程。
其中,运行在客户虚拟机上的操作系统可以是Linux系统、Windows系统。
实施例2:
本发明实施例提供了一种基于实施例1中的软件看门狗系统的检测方法,参见图2,该方法包括:
步骤201:
步骤202:
步骤203:
步骤204:
步骤205:
所述方法还包括,策略模块根据用户输入的进程配置信息确定关键用户进程。
需要说明的是:
每个虚拟机的内核里,有一个进程描述符,存储了操作系统进程的所有信息。
所有进程的进程描述符都在一个循环的双向链表task_list里存储。
每个单独进程的信息,进程描述符,作为一个单独的结构task_struct存储在这个链表里。
一个进程启动的子线程也在task_list的结构里有一个项来存储,并有与之相对应的唯一的线程ID和task_struct来对应run_list域,指向了另外一个结构runqueue,CPU需要使用这个信息。
runqueue结构是一个包含所有要被CPU执行的进程的结构。
task_struct结构中的mm域指向了进程的附加属性:
一旦一个进程被创建后,就被赋予了一个虚拟内存地址。
地址空间和其他所有跟此进程相关的内存管理的信息都存储在了一个叫做mm_struct的结构里。
跟此进程相关的所有虚拟内存区域的描述符都链接在另外的一个链表里,可以通过mm_struct描述符里的mmap域来访问到这个信息。
这些对于此进程可用的虚拟内存区域被保存到另外一个叫做vm_area_struct的描述符里。
这就形成了一个包含进程的虚拟内存信息的链表,每个vm_area_struct描述符指向了它所代表的连续内存区域。
这些地址被存储在每个vm_area_struct里的vm_next域来串联起来。
vm_next域指向下一个vm_area_struct结构,因此指向了进程所拥有的下一片虚拟内存区域。
以上都是跟给定进程的虚拟内存相关的信息。
然而,一个进程只能访问到存储在物理内存里的进程数据。
关联虚拟内存和相应的物理地址的信息存储在页表里。
页表信息可以通过mm_struct的pgd信息来访问到。
页表存储了以页帧为单位的内核内存信息。
这些关联信息在Linux系统里是以三级的形式来存储的。
从上往下依次是:
全局页目录,页中间目录,页表项。
最终就访问到了具体的页。
在虚拟化环境里,虚拟机监控器负责转换虚拟机的虚拟内存地址为宿主虚拟机的物理内存地址。
基于虚拟自省的应用,需要读取内存信息并理解他们语义,因此必须通过找到操作系统对应的第一个任务的符号信息来进行。
一个符号指向了程序块,可以是变量或者是函数的名称。
必须找到task_list的头部,然后就可以获得系统所有进程的信息了。
这个链表的头部存储在一个叫做init_task_union的结构里,在Linux系统下,是跟第一个进程的task_struct相关联的。
符号和对应的虚拟地址存储在Linux系统的System.map文件里。
System.map文件在内核编译之后就创建了,通常存储在/boot目录下,而且在内核的生命周期里,一直保持不变的。
在找到init_task_union所在的地址之后,就可以遍历操作系统里所有的进程链表了。
这样就可以完整地重构出客户虚拟机的内存的信息并进一步分析得出虚拟机的状态。
本系统就可以把虚拟机的虚拟内存地址转换到他们对应到的物理内存的地址了。
虚拟机监控器负责为每个虚拟机创建一个虚拟的MMU(MemoryManagementUnit,内存管理单元)并调节虚拟机的内存访问。
虚拟机监控器也控制了物理的MMU并以不会和其他虚拟机物理内存互相重叠的方式映射每个虚拟机的物理内存。
这样,每个虚拟机自己的地址空间就被隔离开来,不能访问别的虚拟机的地址空间。
最终,低级的事件消息,例如中断等就自动被虚拟机监控器捕获。
因此,在这种环境下,虚拟机监控器可以一直监控,控制每个虚拟机监控器所要求的特权级的指令。
本系统通过虚拟机监控器获得客户虚拟机操作系统的内核数据结构信息,进一步得到进程列表等内存信息。
获得虚拟机的内存信息后,就可以利用故障检测模块,检测包括隐藏进程检测,用户配置的关键进程检测,系统调用完整性检查来发现恶意软件。
故障检测模块检测隐藏进程的过程如下:
Linux维护了一个进程描述符的双向链表task_list。
系统启动时的第一个进程的init_task结构是链表的头结点。
同时Linux还维护了一个runqueue的链表,任何由CPU执行的进程都唯一的属于这个链表。
语义重构模块获得双向链表task_list和runqueue链表,在虚拟机内部通过ps命令得到的进程信息列表ps_list;
故障检测模块判断待检测进程是否存在于双向链表task_list、runqueue链表、进程信息列表ps_list中;
如果存在于上述的向链表task_list、runqueue链表、进程信息列表ps_list中,则结束,否则发现隐藏进程。
故障检测模块检测用户配置的关键用户进程的过程如下:
用户配置了检测的关键用户进程名为userprocess,查看userprocess是否出现在task_list中,如果没有出现,说明用户指定的关键用户进程缺失。
故障检测模块检测系统调用完整性的过程如下:
Linux系统调用的各个函数的入口地址在系统安装后,就是固定的。
所以创建一份正常的系统调用表,作为基准。
之后每次检查时,访问系统调用的各个入口地址,检查其是否与基准一致,如果一致,说明系统调用没有问题。
如果不一致,说明系统调用被破坏,系统调用已经被加了钩子函数。
经过故障检测模块之后,本系统就获得了虚拟机上进程的运行状态,在本实施例中,发现客户虚拟机vm01中的用户关键进程csdtest程序缺失。
策略模块根据故障检测模块的检测结果和用户配置的恢复策略,生成恢复指令。
用户在配置恢复策略时,可以指定当检测到用户的关键进程不存在时,如何进行恢复。
恢复时的操作可以是启动某个指定进程,此进程可以是一个守护进程,由它来负责运行用户所需要的所有应用程序;
恢复操作也可以是重新启动系统,在Windows操作系统中,重启操作系统能够解决一些问题;
恢复操作也可以是从最原始的镜像文件来恢复虚拟机。
这种恢复是终极的解决方案,此镜像不仅保存了虚拟机上所有文件的状态,而且也保存了操作系统和用户应用程序的运行状态。
但前提条件是建立此镜像时,整个系统是干净,完整,没有被恶意软件破坏的。
当故障检测模块检测到隐藏进程后,可以采取以下恢复策略:
重启操作系统,如果重启两次后仍不能解决故障则重启虚拟机,如果重启虚拟机仍不能解决故障则从镜像文件恢复虚拟机。
当故障检测模块检测到关键用户进程缺失后,可以采取以下恢复策略:
启动该关键用户进程,如果没有解决故障,则重启虚拟机,如果重启虚拟机后没有解决故障,则从镜像文件恢复虚拟机。
当故障检测模块检测到系统调用被修改后,可以采取以下恢复策略:
从镜像文件恢复虚拟机。
综上所述,整个恢复机制分为两级,一种是进程级别的恢复,另外一种是虚拟机级别的恢复。
当重启程序3次之后,发现问题依然存在,就会采用重启操作系统的方法来解决故障。
如果此时故障依旧,就可以采用恢复镜像的方法来恢复整个虚拟机,不过恢复镜像之后,整个客户虚拟机的状态就回到了之前做镜像时的状态,最近对文件所做的操作和用户程序运行时产生的数据就会丢失,因此在实际应用中,需要配合数据库等操作来将数据保存到其他地方。
当策略模块作出恢复操作的决策之后,就由恢复模块去负责执行恢复命令。
通过上述描述可见,本发明实施例具有如下的有益效果:
通过本发明实施例提供的一种软件看门狗系统及方法,根据虚拟机监控器获取的物理主机的内存信息进行客户虚拟机的隐藏进程的检测,关键用户进程的检测,系统调用完整性的检测,通过策略模块输出的恢复指令来对客户虚拟机进行恢复,保证了客户虚拟机的高可靠性,能够对客户虚拟机进行故障检测和恢复,具有配置简单、可扩展性强以及高可靠性。
需要说明的是,在本文中,诸如第一和第二之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。
在没有更多限制的情况下,由语句“包括一个·
·
”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同因素。
本领域普通技术人员可以理解:
实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储在计算机可读取的存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;
而前述的存储介质包括:
ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质中。
最后需要说明的是:
以上所述仅为本发明的较佳实施例,仅用于说明本发明的技术方案,并非用于限定本发明的保护范围。
凡在本发明的精神和原则之内所做的任何修改、等同替换、改进等,均包含在本发明的保护范围内。
说明书附图
图1
图2