云计算在一个新的基础设施环境下,推动着企业迈向更加高效和灵活的工作模式.然而,安全问题仍是一个关键问题,阻碍了人们全面转向云的步伐.虚拟机(virtual machine,简称VM)作为云计算基础设施中基本的计算资源,成为了恶意软件极具吸引力的攻击目标.云用户被授予特权,可以通过网络访问其VM并安装任意种类任意版本的操作系统(operate system,简称OS)及应用,而这些OS和应用本身可能带有漏洞,会给系统带来风险.这些带有漏洞的VM极易被攻击者攻陷,并成为攻击者攻击云系统内其他VM的跳板,被攻击者远程控制发动分布式拒绝服务攻击(distributed denied of service,简称DDoS)等极具破坏力的网络攻击,导致多台VM瘫痪.因此,为防止脆弱的VM被利用作为攻击跳板,对云内网中虚拟机间的网络行为应加以关注并及时隔离攻击源以保护其他VM不受攻击.

虽然云管理员可以利用特权修补VM的漏洞、在VM安装个人防火墙或基于主机的入侵检测系统(host- based intrusion detection system,简称HIDS)来保护其免受攻击.然而,这种做法可能会中断用户正在运行的服务,甚至因为应用程序版本依赖的原因而导致服务功能障碍.再者,这类基于代理的方式,由于其代理是可见的,攻击者可以伪造检测结果,禁用代理.最近有些方案提出将监控代理放置于VM外,并使用虚拟机自省(virtual machine introspection,简称VMI)技术获取VM状态信息.此类方案可有效克服上述方法的弊端.但尽管如此,因虚拟机自省技术普遍运用在主机级检测上,通过现有VMI技术获取的主机信息,包括内存信息和磁盘信息等,仍然很难直接运用在网络攻击行为的检测上.

针对于网络攻击的检测和防护,传统防护方法通常会根据网络拓扑情况在边界或旁路部署安全设备,如基于网络的入侵检测系统(network-based intrusion detection system,简称NIDS)和网络防火墙.这类方法的部署与网络结构紧密耦合,存在诸多不适应性.同时,对于同一主机中VM间通信的情况不具备检测功能.作为改变现有网络格局的软件定义网络(software defined networking,简称SDN)技术,由于其灵活性,也被应用在了网络安全防护领域.然而,现有的软件定义安全技术对于攻击行为的检测和控制粒度仅能细到流(flow)这一级别,因而无法通过定位进程级攻击源的方式彻底隔离恶意进程、杜绝攻击的再次发生.

鉴于现有VMI技术和SDN技术难以解决本文所讨论的问题,我们提出了一个虚拟化网络纵深防御系统,整合位于主机层的VMI技术和位于网络层的SDN技术的优势,通过VMI获取信息,辅助SDN定位发起攻击的进程,并对其发出的流量进行检测、控制、隔离,实现更细粒度的进程级攻击防御.本系统可以实时检测到VM发起的与其他VM的新建连接,反向追溯发起连接的VM和具体进程并予以检测,继而根据检测结果控制该连接的数据包流量.通过VMI的进程监控和SDN控制,可以检测恶意进程并重定向可疑流量到一个基于网络的入侵检测引擎中进行深层数据包检测以及消除恶意流量.

本文旨在提出一种类似内网防火墙的虚拟化网络纵深防御系统,目的是防止脆弱的VM成为攻击者攻击其他VM的跳板、隔离攻击源、抑制攻击行为的发生范围,并减轻攻击产生的后果.其优势在于可以及时捕获网络流量并控制流量最终的目的地(原目的地址、入侵检测系统或是直接丢弃),实现进程级的网络攻击防御,而不是改良现有的入侵检测算法.其中,系统的纵深防御是指:

· 除开云主机与外部网络的通信流量,也可监控同一云主机内部的虚拟机间的网络流量;

· 可在完全无代理的状态下主动感知并抑制恶意行为;

· 具备进程级的检测功能和网络控制功能,不仅可以检测具体进程的状态,对网络流量的控制也可细致到进程,因而不影响虚拟机内其他的网络服务,最大限度地保证了服务质量;

· 对虚拟内网中的流量可进行重定向,为网络控制提供了除告警、丢包外的其他选择.

现有很多着重于检测被感染VM并保护云中其他VM不受其攻击的技术,如防火墙和入侵检测系统(intrusion detection system,简称IDS).在网络层,传统的网络防火墙和基于网络的入侵检测系统(network-based intrusion detection system,简称NIDS)建立在“被监控网络内-防火墙外”模式下.此种模式不适用于被感染VM和攻击目标处于同一云主机内部的情况,因为网络防火墙和NIDS搜集的必须是进出被监控网络的信息.在主机层,个人防火墙、HIDS^[1,2]、防病毒和防间谍软件系统等,运行在它们所保护的VM内,使得这些工具很容易被窃取到系统特权的攻击者破坏.故这些传统网络安全技术并不能很好地解决本文所需着重解决的问题:及时检测有害VM,并在其试图与其他VM进行连接时予以阻止,防止攻击的发生.

目前,部分研究在虚拟化技术的基础上进行的网络分析检测工作,可以检测网络通信过程中的恶意行为,保障VM的安全.

Yassin等人^[3]提出了一种基于云计算的框架,称作“基于云的入侵检测服务(cloud-based intrusion detection service,简称CBIDS)”.CBIDS能够克服传统入侵检测技术在部署方式上的不足.同时,该框架可以嗅探到网络内任意地方的网络流量,可疑数据包会传递到CBIDS中进行深度检测,并产生相应的警告.然而,CBIDS仅能检测网络流量并提出警告,却无法对攻击行为做出干预,本身不能阻止攻击的发生.除此之外,CBIDS的检测对象仅为数据包,无法追溯该数据包所属的VM和进程,因此不能满足本文应用场景中提出的隔离恶意进程网络行为的要求.Laureano等人^[4]提出的一种网络入侵检测方案,从被监控VM外部监控,检测并阻塞来自VM内部服务的攻击.该方案包括了入侵检测机制和响应机制,保证既能检测出攻击行为,也能阻止其发生.此方案中,检测的是主机内VM与外界(主机以外)进行网络通信过程中的流量,而这些网络通信行为由安装在主机内的防火墙软件进行管理.并且,响应机制中通过该防火墙软件阻塞VM的端口,并断开其与外界的通信.因此,对于同一主机内VM与VM间的网络通信并未得到关注,即,该方案无法应用在同主机中VM间的网络行为检测中.Gupta等人^[5]提出了一种基于配置文件的网络入侵检测和防御系统,该系统为每一个VM创建属于它的配置文件,该配置文件描述了此VM的所有网络行为,这些行为将会被用作判断是否被攻击的依据.该系统可以检测来自VM(内部实体,如恶意的云用户)和外部实体(外部攻击者)的入侵.然而,系统中的网络流量通过虚拟机的IP地址过滤,即,对流量的识别是VM级的,因此,对于进程级检测的细粒度要求,该系统无法满足.SDN^[6-8],即软件定义网络,解耦网络控制功能与转发功能,使得网络控制部分可被直接编程.这种灵活性使得在其上部署网络攻击检测能实现更灵活的安全防护,因此,现有部分网络攻击分析检测研究也转向了SDN.Shin等人^[9]提出了一个基于OpenFlow的安全应用程序开发框架——FRESCO.FRESCO提供了支持OpenFlow的检测控制组件的模块化组成方式.利用RESCO,安全组件可以整合基于DPI的传统网络安全应用发出的告警信息,进而将其作为FRESCO检测部件的输入参数或触发FRESCO响应部件生成新的流规则.然而,在FRESCO中,一个操作(检测或响应)是指对于网络数据包(或称为流)的处理,这些由FRESCO提供的操作源于NOX OpenFlow控制器所能支持的操作.因此,对于进程级的检测,FRESCO同样无法支持.Jafarian等人^[10]使用OpenFlow开发了一个移动目标防御(moving target defense,简称MTD)框架,可以透明地改变机器的IP地址,且此变化具有难预测性和较快的速度.同时,它也保持了结构的完整性和最小的操作开销.此框架原本的设计并不针对于云环境,但经过若干改造,仍能在云中使用.若是应用在云中,改变的将不再是物理机器的IP地址,而是每台VM的独立IP地址.虽然也能通过动态配置保护VM的安全,但是:首先,对于恶意云用户这一情况,它会立即失效;再者,该框架的防护级别也属于VM级,因此做不到进程级的防御.Shin等人^[11]提出了CloudWatcher框架,为大型、动态的云网络提供监控服务.CloudWatcher会自动改变网络数据包走向,以供预装的网络安全设备进行检查.CloudWatcher以一个应用程序的形式运行在网络操作系统上(如NOX,Beacon),可用来控制SDN环境下的网络路由器或交换机.因此,此框架的作用类似于NIDS,并提供一定的控制功能.同样,它也具备普通NIDS的缺陷:无法检测同一主机内VM间的流量;检测粒度为流,无法达到进程级.

综上所述,现有的网络分析检测方式由于其各自的缺陷,均无法直接应用在本文所需解决的问题上,而所有方式对比本文所采用方法的共同弱点在于,无法提供进程级的细粒度检测.上述方式与本文工作的详细对比见表 1.

表 1(Table 1)

Table 1 Comparison with other researches 表 1 与其他工作的对比 项目名 监测粒度 能否监控同一云主机内的流量 能否对攻击行为进行干预 CBIDS flow级 √ × Marcos Laureano方案 flow级 × √ Sanchika Gupta方案 VM级 √ √ FRESCO flow级 √ √ MTD VM级 × √ CloudWatcher flow级 × √

Table 1 Comparison with other researches 表 1 与其他工作的对比

对于本系统所采用的VMI^[12]技术,即虚拟机自省技术,是从VM外部分析VM内部状态的一种方法.基于VMI的VM保护方案将安全保护工具和被监控VM予以隔离,因此无需在被监控VM中安装任何代理.这一特点使得该方案抵抗攻击的能力大为增强,不受VM的影响.虽然现有的很多研究^{[13, 14, 15, 16, 17]}采用了此种方法,但普遍运用在了主机级检测方面,没有涉及网络攻击研究,故这里不再详述.

在本框架的应用场景中,云用户能够通过Internet访问其虚拟机,并具有在VM内安装任意操作系统或应用的权限.云管理者在确定某VM存在安全威胁之前,不对其运行作任何干预.攻击者可能来自云外部,将一台已被控制的VM作为跳板,攻击云内其他VM;或是本身即为控制着若干VM的云用户,可直接攻击其他VM.

攻击者通过给目标VM发送恶意网址或文件,达到攻击的目的.若VM用户用带有漏洞的应用程序打开这个网址或文件,文件或网站里的shellcode会触发执行,并下载病毒程序到本地.该病毒程序会自动执行,并窃得该VM的控制权.无论病毒程序以何种方式执行,它都会试图与攻击者连接以接受进一步的命令.攻击者下达的命令会控制病毒程序获取当前局域网的拓扑,扫描其他VM或主机的漏洞,攻击然后控制其他机器,窃取这些被攻击机器里的敏感信息,供攻击者发起DDoS攻击.

如图 1所示,攻击者在通过路过式下载(drive-by download)或恶意的邮件附件等方式成功攻击一台VM后,获得其控制权,接下来便可以该VM为起点,去发动更多的攻击.本研究的目标即为准确、及时地发现已被控制的可疑VM,并阻止它们发动更多针对云里其他VM的攻击.

图 1

Fig. 1

Fig. 1 Attack scenario图 1 攻击场景

当某VM发起一个面向其他VM的连接时,在OVS和OFS的帮助下,可以及时获取该连接的数据包流量.为判断此连接的发起者是否可信,本文提出一个“终止-检测-转发”模型来阻止攻击行为的发生.

在该模型中,终止、检测、转发分别代表VM处于3种安全状态下本系统对其采取的操作.其中,终止代表判定VM或其进程为恶意后采取的隔离操作,此操作将阻塞从该VM或进程发出的所有流量;检测代表发现VM或进程可疑后采取的深度检测操作,此操作将该VM或进程发出的流量重定向到NIDS处进行深度数据包检测;转发则代表VM一切正常,所有流量正常转发到原目的地.

图 2简要描述了“终止-检测-转发”模型在系统处于不同状态时的行为,值得一提的是,本系统暂时只提供网络层面的控制,不关注恶意进程的清除.

图 2

Fig. 2

Fig. 2 “Suspend-Check-Forward” model图 2 “终止-检测-转发”模型

该模型集成了VMI技术和SDN的可编程特性,包括两个层次——VM级和进程级.

· VM级:本系统通过定位发出连接请求的VM并检测其安全性,若判定为恶意,则终止该流量并阻塞从此VM发出的所有流量,将其彻底隔离;若VM为可疑,却无法确认为恶意,则重定向此VM发出的流量到NIDS处进行深度检测;若能确定为正常,则让流量继续转发到原目的地;

· 进程级:与VM类似,确定发起连接的具体VM中的具体进程,并进行检测.若判定为恶意进程,则终止其与其他VM进程的通信行为;若可疑,则重定向它发出的流量到NIDS处检查;若正常,则按正常程序进行转发.

本系统旨在基于软件定义网络技术,建立一个云服务器集群中的内网防火墙.服务器的虚拟化环境由特权域(privileged domains,简称PD),如XEN的dom0,以及非特权域(unprivileged domains,简称UPD),如VM等构成.云主机之间和主机内虚拟机之间分别由可编程的网络交换机OpenFlow Switches(OFS)和Open vSwitches (OVS)连接,OVS转发主机内VM间的网络数据包,而OFS负责主机间的网络通信.本系统中,控制中心包括攻击分析器(attack analyzer,简称AA)和网络控制器(network controller,简称NC),其中,攻击分析器是系统中制定策略的核心部分,由它决定流量最后的处理为“终止-检测-转发”模型中的哪一部分;网络控制器则负责控制网络交换机的路由.本地部件包括特权域里的进程检测器(process inspector,简称PI)、VMI,负责对VM及其中进程的检测工作,以及非特权域里的NIDS,负责确认重定向到此处的流量是否安全.本系统的总体框架如图 3所示.

图 3

Fig. 3

Fig. 3 Architecture of the system 图 3 系统总体框架图

本文中,仅以XEN虚拟化平台为例进行说明.在云主机内,所有网络流量都由OVS进行处理和转发,并且每个OVS中都存在流表,指示应该如何转发流量.而在云主机之间,由OFS根据内部的流表进行处理和转发.由于OFS和OVS的数据转发功能和路由控制功能相互分离,故在本系统中,OFS和OVS仅完成数据转发这一功能,而路由控制则由NC来完成.一旦一个网络连接请求被创建,该请求的流量就会到达OVS并等候处理.由于这是一个新的连接,故OVS内不存在相应的流表项.此时,OVS会将流量发送给控制器NC,向NC询问处理方式.由于NC在主机外部,与该主机以OFS相连接,故这一过程需要经过OFS.成功发送到NC后,NC记录下流量的信息,并继续转发给AA,由AA调用PI和VMI模块获取发起请求的VM及内部进程的信息,并做出决策,如转发到目的地、重定向到NIDS处进行深层检查或是直接丢包.AA将命令传递给NC,由NC控制OVS/OFS具体执行流量处理操作.同时,将该操作写进流表.这种处理方式可以在恶意VM试图与其他VM建立连接时及时阻断连接,保证其他VM不会受到威胁.

本节详细介绍本系统中各重要部件的工作原理及其实现方式.

AA是系统中的信息处理和决策制定中心.其工作流程如图 4所示.

图 4

Fig. 4

Fig. 4 Workflow of AA图 4 AA工作流程图

当NC接收到由OVS发送过来的流量时,会记录下该OVS的datapath ID以及发送数据包的VM对应在OVS上的虚拟网卡号ofport和具体发包的进程所使用的端口号(source port),然后将其转发给AA.AA通过这些信息,并调用VMI模块,能够确定该请求来源于哪台VM里的哪个进程.定位发起连接请求的VM和进程的过程如下:

1) OFS根据datapath ID,确定OVS所属的云主机;

2) OVS根据数据包来源的ofport,确定该数据包来源于何VM;

3) 若只检测VM的安全状态,则直接返回该VM的ID给AA;

4) 若还需了解具体发送数据包的进程,则调用PI和VMI部件,列出该VM内的所有进程(包括隐藏进程)以及进程所使用的网络端口;

5) 将之前记录的source port与步骤4)中的所有进程的网络端口号一一比对,找到符合的进程号pid,再将VM的ID和进程的pid返回给AA.

然后,AA可通过PI模块获取该VM以及该进程的安全信息并进行分析,进而在先验知识(可疑进程列表、恶意进程列表)的帮助下做出决策.如PI模块获知发出网络连接的进程为隐藏进程,或在可疑进程列表中出现,则有理由相信该进程发出的数据包需要得到更深层的检查;若出现在恶意进程列表中,则可直接丢弃它发出的包;若以上情况均未发生,则相信此进程是正常的,其数据包可以转发.可疑进程列表和恶意进程列表是可以动态更新的,因为AA每次得到PI的反馈后,若确认某进程可疑或恶意,便会更新这两个列表.值得一提的是,AA作为一个信息处理和决策模块,它本身可以接收不同安全组件的信息,包括NIDS的警告信息,或是其他查毒软件发送来的报告,进而根据所获得的信息做出相应决策.下面仅以隐藏进程检测的结果以及可疑进程列表、恶意进程列表作为其中一个说明范例:

· 可疑进程列表(suspect process list,简称SPL):该列表列举了拥有漏洞数据库中漏洞的进程,此列表中的进程都是可疑的,因为它的漏洞很容易被攻击者利用,故需要得到更多的关注;

· 恶意进程列表(malicious process list,简称MPL):该列表列举出的进程是已被确定为恶意的进程,故此列表中的进程应被立即禁止与其他VM的通信.

与“终止-检测-转发”模型相对应,AA做出的决策包括两个层次,分别是VM级以及进程级.

· 在VM级,具体措施发生在网络第2层——数据链路层.由于OVS通过虚拟网桥将两台VM的网卡连接起来,并且不同网桥上的VM在数据链路层是相互隔离的,故只需禁用某VM的虚拟网卡所对应的OVS上的端口,即可将该VM隔离;也可修改流表项将从该VM对应的OVS端口出来的所有流量重定向到NIDS处进行检查.该决策尽可能地杜绝了攻击行为的发生,但同时也影响了VM内正常服务的运行,可能会给用户带来不便;

· 在进程级,通过PI模块获得进程的网络信息后,通知NC控制OVS,每当接收到来自某VM内某可疑进程发出的流量,则将其丢弃或是重定向到NIDS.进程级的决策具备更细的控制粒度,能够在有效遏制恶意行为的同时保证VM的其他网络服务不受影响.

总而言之,AA的策略包括:

1) VMIsp:即VM级的检测.此策略将一个可疑的VM发出的所有流量导入到一个in-line模式下的NIDS处进行检查;

2) VMIso:即VM级的隔离.此策略将一个被怀疑的VM的所有网络流量阻塞掉,使得该VM与其他VM相互隔离;

3) PrIsp:即进程级的检测.此策略仅将特定VM内的特定进程发出的流量重定向到NIDS处进行检查;

4) PrIso:即进程级的隔离.此策略阻止某可疑VM内的可疑进程与其他VM的进程进行网络通信.该方法仅停止某一进程的网络服务,并不影响同VM内的其他进程.

NC是本系统能够利用OpenFlow协议构建可编程网络的关键部件.OVS作为直接处理VM之间流量的交换机,由NC控制.本系统中,NC从OVS处获得流量的信息并转发给AA,再接收从AA处传递回来的处理命令.然后,NC根据此命令创建一个流表项插入到OVS的流表中,从而操控流量的去向.

图 5

Fig. 5

Fig. 5 Workflow of NC图 5 NC工作流程图

为将流量重定向到NIDS中进行深层数据包检测,NIDS的两个虚拟网卡会被添加到被监控网络所属的OVS上,并设置成混杂模式用来嗅探网络流量.同时,配置NIDS,其中一个虚拟网卡仅作为接收流量的入口(inport),另一个网卡仅作为正常流量的出口(outport).在这种状态下,广播流量易引起自循环,因为广播流量会发送到每个VM中,当此流量进入到NIDS入口时,NIDS会判断是否正常:若为正常,便让其通过出口又再回到OVS上重新进行广播.因此,需要特别处理这种情况,避免引起自循环,耗费网络资源.防止自循环的伪算法如下:

算法1. 自循环避免算法.

输入:数据包包头信息,NIDS的inport,NIDS的outport;

1. if (数据包从OVS其中一个ofport发出)

//如果数据包不是从OVS的ofport发出,则为非法数据包,应丢弃

2. if (数据包中目的MAC地址对应OVS的ofport==null)

3. //代表这是一个广播包

4. if (数据包源端口==NIDS的outport && 数据包目的端口==NIDS的inport)

//如果数据包由NIDS发出,目的地也是NIDS,则应丢弃该包,防止自循环发生

5. 丢包

6. else

7. 将数据包转发到OVS的每一个端口

8. end if

9. else

10. 丢包

11. end if

NC的工作就是根据AA的决策处理流量的转发路由.对于协议低于第4层的数据包,NC会根据AA传回来的命令:终止、重定向或正常转发,在OVS中创建流表项并填充转发路由.若是终止命令,则目的地填null;若为重定向命令,则为NIDS在OVS上的outport号;若为正常转发,则为原目的地址对应的OVS上的端口(ofport)号.若数据包协议高于第4层或是一个广播包,则NC仅检查该包的目的地址是否为空(null):若为null,则将其广播到所有VM中;若不为null,则按照其目的地址进行转发.

PI模块主要用于在VMI模块的协助下检测云主机内每台VM内部的进程状况,获知当前VM以及其中进程的安全状态.为保证检测工具自身的安全和检测结果的完整性,本系统将PI模块置于被监控VM外的Domain0中,与VMI模块协同合作.

PI模块内包含了两个子模块:守护程序(daemon)和语义翻译模块(semantic translation module).如图 6所示:守护程序主要用来接收来自AA的命令(如检测隐藏进程、判断发包的是何进程或进程的网络连接状态等)并予以执行,然后将结果返回给AA;而语义翻译模块的存在是为了解决语义鸿沟(semantic gap)的问题.在虚拟化平台中,虚拟机监视器(virtual machine monitor,简称VMM),也称为管理程序(hypervisor),仅能读到VM内部的虚拟硬件信息.这些硬件信息是大量的不可读的原数据(raw data),不具备客户操作系统内部的数据结构,使得这些原数据缺少有意义的语义信息,因而也很难通过这些原数据直接获知当前系统的运行状态.这种状况通常称为语义鸿沟问题.

图 6

Fig. 6

Fig. 6 Structure of PI module and VMI module图 6 PI模块和VMI模块结构图

由于PI模块放置在被监控VM外部,故需要VMI模块帮助从外部获取VM内的信息.VMI模块负责通过两层地址转换,将VM应用程序的虚拟地址空间转换到主机的物理地址空间,进而可以直接在主机中读到VM内的信息.其中,第1层地址转换是将客户机(即VM)虚拟地址(guest virtual address,简称GVA)映射到客户机物理地址(guest physical address,简称GPA),第2层地址转换是将GPA翻译成主机物理地址(host physical address,简称HPA).通过在VM外部读HPA地址中的内容,即可获知相应的VM内GVA的内存信息.完成地址翻译后,VMI模块会将读到的内容返回给PI进行检测.

本系统中,隐藏进程检测以及进程的网络状态是非常重要的部分,对于判断VM及特定进程的安全性有着重要意义.下面以操作系统为Windows的VM为例,分析隐藏进程检测和网络状态检测.

在隐藏进程检测过程中,PI首先利用VMI模块寻找VM内的活动进程链.在此之前,需要找到Windows加载的内核模块链表表头PsLoadedModuleList,然后遍历内核模块链表,找出ntoskrnl.exe.找到操作系统内核文件ntoskrnl.exe以及其加载到内存中的基地址(BaseAddress)后,通过分析ntoskrnl.exe的PE(portable executable)文件,在其中的.edata节的导出地址表中得到PsInitialSystemProcess的相对虚拟地址(relative virtual address,简称RVA).PsInitialSystemProcess是指向系统system进程的EPROCESS结构的指针,其在内存中的虚拟地址VA可由VA=RVA+BaseAddress计算得出.在Windows中,活动进程的EPROCESS结构会相互连接成一个双向循环链表,故得到PsInitialSystemProcess地址并寻找到system的EPROCESS后,即可确定活动进程链.

由于隐藏进程会通过各种方式隐藏自身,如采用直接操作内核对象(direct kernel object manipulation,简称DKOM)的方式,则该进程的EPROCESS将不会出现在上述的活动进程链中.由于Windows的调度单元是线程,故该进程即使不在活动进程链中,也不会影响OS的调度和进程的运行.但若将进程从线程链表上摘除,则无法获得CPU时间,进而无法运行,故遍历线程调度链即可发现从活动进程链上脱链的所有进程.经过比对在用户态获取的进程(如采用ZwQuerySystemInformation函数枚举进程)和内核态的活动进程链以及线程调度链,可检测出隐藏进程.

关于获取进程的socket信息和网络连接状态,PI需要定位分别包含socket信息和网络连接信息的_ADDRESS_OBJECT和_TCPT_OBJECT两条链表.在此之前,需先找到内核模块tcpip.sys,因为tcpip.sys的PE (portable and executable)结构体中的AddrObjTable和TCBTable分别指向了两条链表的基地址.除了使用中的socket信息和活跃的网络连接信息外,PI也能获取该socket和连接所属的进程.

NIDS用于对无法确认是否为恶意的可疑流量进行更彻底的深层数据包检测.本系统的工作在于对网络流量的捕获以及路由控制,而不在于改良现有的流量检测算法,因此直接利用了开源工具snort^[18,19],将其运行在in-line模式下,实行数据包检测.在本系统中,NIDS被放置在非特权域UPD中,这样做的好处是:

1) 部署动态化和自适应化:NIDS作为一个虚拟应用部署,重配置并动态迁移到任意网段中会变得相对容易,且无需复杂的网络配置过程.NIDS在in-line模式下工作,检测并过滤恶意流量,但无需将其配置成一个in-line的网关;

2) 减轻特权域PD的负载:由于特权域PD需要管理和配置内存和硬件资源的访问,若PD的负载过大,则会严重影响VM访问内存和硬件资源,故应尽可能地减轻PD的负载.NIDS的主要作用是对重定向到此处的流量进行深度数据包检测(deep packet inspection,简称DPI).这一过程十分耗费资源,故不适合放在PD内.

NIDS自身的安全也需要考虑在内.尽管NIDS处于UPD内,但是基于以下假设,仍然可以认为它是安全的:

1) 假设每台云主机的管理器Hypervisor是受保护的,每个VM都能完全地相互隔离.恶意的VM不能通过Hypervisor攻击NIDS;

2) 尽管NIDS处于UPD中,能够从PD中被访问,但只有云管理员才能在其中维护软件的安装行为并运行管理任务.假设云管理员是可信的,那么NIDS仅能由云管理员从PD安全地访问,未授权者无法访问;

3) NIDS对于网络内的其他VM是不可见的,仅有NC可以通过OVS和OFS的控制通道去控制和主导NIDS的行为.而控制通道是与OVS、OFS传输网络流量的数据通道相互分离的,故控制通道的安全性值得信任.

进行实验测试工作的云主机硬件配置为:8个Intel(R) Xeon(R) 2.33GHz的CPU,32768MB的内存.主机中有8台VM在运行,其中1台VM中运行着snort,其余7台均为普通云用户所使用的VM.实验部分将按照功能测试和性能测试两方面完成.

本节利用Xcap工具模拟拒绝服务攻击(denial of service,简称DoS)中的SYN洪泛^[20]攻击(SYN flood).利用TCP/IP协议栈的漏洞,给攻击目标发送大量伪造的TCP连接请求,从而耗尽对方的资源(CPU满负荷或内存不足).在同一主机内,设置一台VM为攻击方,OS为Microsoft Windows XP SP3,另一台VM作为目标服务器,OS为Microsoft Windows Server 2003 Standard SP1,且未安装补丁.将NIDS即snort的两个网卡设置为混杂模式,并留一个网卡作为管理接口.各部分网络配置如图 7所示.

图 7

Fig. 7

Fig. 7 Configuration of test network图 7 实验网络配置

在本系统中,攻击方发送的TCP连接请求将不会直接到达被攻击方,而是首先到达网络交换机(OVS,OFS)中.OVS和OFS将该请求的流量转送到NC处加以检查.AA会调用PI模块和VMI模块,追溯该流量的来源以进行检测判断.由于本攻击实为模拟的,发送请求的Xcap工具是一个正常程序,为使其代表恶意程序,本实验用FU rootkit将其隐藏.PI模块检测时,会发现此进程为隐藏进程,同时将结果交由AA处理.隐藏进程的检测结果如图 8所示.

图 8

Fig. 8

Fig. 8 Result of hidden process detection图 8 隐藏进程检测结果

此时,AA判定该进程为可疑,指挥NC将其发出的连接请求流量重定向到NIDS处进行深层检测.此时,在NIDS所在系统中能够嗅探到此流量,如图 9所示.由于攻击方的Xcap工具会连续发包,所有包经上述处理均会到达snort处,直至snort判定这类数据包已构成了syn flood攻击.

图 9

Fig. 9

Fig. 9 Flow captured in NIDS图 9 NIDS处捕获到的流量

在NIDS中事先做过处理,添加一条关于虚假TCP连接请求的规则.规则如下:

drop tcp any any>192.168.1.74 any ( \

msg: “TCP sync flood”;

flow: established,to_server; \

detection_filter: track by_src,count 10,seconds 60;

sid:1000001;

rev:1;)

rate_filter \

gen_id 135,sig_id 1,\

track by_dst,\

count 10,seconds 60,\

new_action drop,timeout 6000,\

apply_to 192.168.1.74

故当流量定向到NIDS处时,NIDS会根据规则将其直接丢弃并发出警告.然后,AA根据NIDS的警告确定攻击方的Xcap程序是恶意程序,将其加入恶意程序列表MPL,并告知NC向OVS中写入流表项,阻塞该进程发出的所有数据包.此时,被攻击方不会收到任何来自攻击方发来的连接请求,保证了它的安全.OVS对应的流表项如图 10所示(图中第1条规则).图中,in_port=4代表攻击者发送的数据包,而actions=out_put:14代表将数据包转发到端口号为14的VM,即为NIDS.

图 10

Fig. 10

Fig. 10 OVS’s flow table图 10 OVS流表

本节将测试云用户以不同的发送速率向外(仍在云内网中)发送TCP包时,运行本系统所带来的丢包率以及不运行本系统情况下的丢包率.同时,还将对比运行本系统的CPU负载和不运行本系统的CPU负载.

首先测试以不同速度发送包长为1 514Bytes的TCP包时,运行本系统和不运行本系统时的丢包率,结果如图 11所示.

图 11

Fig. 11

Fig. 11 Comparison of drop rate between situations of running our system and without our system图 11 运行本系统与不运行情况下丢包率的对比

图 11显示:随着发包速率的增大,两种情况下的丢包率均在逐步增长.由于本系统中OVS转发包之前还需对其发送方进行检查等操作,因此在运行本系统时,丢包率会比另一种情况下的丢包率略高.然而实验结果也表明:两种情况下的丢包率比较接近,最坏情况下,本系统所带来的额外的网络负载为3.17%.

然后对比运行本系统和不运行本系统两种情况下的CPU负载状况,对比分为7组,分别为1~7台VM同时向外(仍在云内网中)发送TCP包,从开始发包到持续1分钟时系统的CPU平均占用率.测试发包1分钟内的平均CPU占用率的原因是:VM刚开始发包时,OVS需要与控制器连接,判断当前数据包的走向.此时的系统负载是最大的,而本系统中PI需要追溯发送源并进行检测,因此与不运行本系统相比负载更大;1分钟之后,OVS的流表项已经由控制器填好,可以直接转发数据包,因此运行本系统的负载情况与不运行本系统的负载情况此时应该一致,故不予考虑.实验结果如图 12所示.

图 12

Fig. 12

Fig. 12 Comparison of CPU load between situations of running our system and without our system图 12 运行本系统与不运行情况下的CPU负载对比

图 12表明:随着发送数据包的并发数的增加,两种情况下的CPU负载会增长,而运行本系统的情况下负载会相对更大.然而随着并发数的增长,运行本系统的CPU负载会逐渐靠近不运行情况下的CPU负载.出现此种现象的原因是:对于本系统,PI对数据包来源的检测是串行的,与发送并发数无关,故它所消耗的CPU负载相对比较稳定.因此,当并发数变大时,PI所占用的CPU比例会逐渐变小,显示出来的结果便是两种情况的CPU负载越来越接近.

本文提出了一种具有内网防火墙特点的虚拟化网络纵深防御系统,融合了软件定义网络以及虚拟机自省技术等,能够及时捕获可疑或恶意流量,反向定位发起流量的VM和进程,利用隐藏进程检测和进程网络信息获取等安全技术确定流量的安全性,运用网络的可编程性对特定进程发起的流量进行控制,在保证网络服务质量的同时,有效阻止了恶意行为的扩散,保护了系统安全.