OpenStack虚拟机迁移机制安全性分析

目前的云平台主要有两种迁移类型:动态迁移和块迁移。动态迁移需要实例保存在NFS共享存储中,这种迁移主要是实例的内存状态的迁移,速度很快。块迁移除了实例内存状态要迁移外,还得迁移磁盘文件,速度会慢些,但是它不要求实例存储在共享文件系统中。(NFS允许一个系统在网络上与他人共享目录和文件。通过使用NFS,用户和程序可以像访问本地文件一样访问远端系统上的文件。)

在云计算基础架构中,虚拟机动态迁移已成为公有云和私有云的必备功能。虚拟机动态迁移是指将一台虚拟机从一个物理机器迁移至另一个物理机器,而迁移过程中虚拟机继续执行原有指令而不会中断的一种技术。云服务提供商利用虚拟机动态迁移技术进行负载均衡、集中管理、容错等技术。虚拟机动态迁移在提供可伸缩性和灵活性的同时,也带来了很多安全问题。当前业界通常把动态迁移的安全问题归为三类:控制平面安全、数据平面安全和迁移模块安全。

一. 虚拟机迁移安全问题分类

1. 控制平面安全

虚拟机监控器(VMM)之间的用来发起和管理虚拟机动态迁移的通信机制应该加入身份鉴别和防篡改机制。攻击者有可能通过攻陷VMM来影响虚拟机动态迁移从而实现对虚拟机的完全控制。

2. 数据平面安全

虚拟机迁移的数据通信信道必须进行安全加固,来防止可能的监听攻击和篡改攻击。被动的监听攻击可能导致被迁移虚拟机敏感数据的泄露,而主动的篡改攻击则可能导致整个虚拟机被攻破。

3. 迁移模块安全

执行迁移功能的VMM模块必须具有抵御外部攻击的能力。如果记者能够利用迁移模块中的漏洞攻陷VMM的话,攻击者就可以完全获取VMM以及VMM之上所有虚拟机的权限。

虚拟机动态迁移会利用虚拟机调度机制来进行目标主机的选择,虚拟机调度机制的基本原理如下图所示。

图1 虚拟机调度机制基本原理

二. 现有的针对虚拟机迁移的攻击方法

目前安全研究人员已经针对数据平面安全提出了很多攻击方法,针对的实验平台包括目前流行的Xen平台和VMware平台。而迁移模块安全主要是对虚拟机监控器的安全漏洞的挖掘,与一般的软件漏洞挖掘无异,因此其安全分析方法可归于普通软件漏洞挖掘一类。目前还没有针对控制平面安全挖掘的相关技术出现。

1. 动态迁移中控制平面的攻击方法

VMM之间的用来发起和管理虚拟机动态迁移的通信机制应该加入身份鉴别和防篡改机制,另外,控制平面中所使用的协议应该能够防止监听攻击和重放攻击。缺乏访问控制机制可能导致攻击者能够执行任意的虚拟机迁移。

1)迁入控制:

通过发起未授权的迁入,攻击者能够把目标虚拟机迁移到攻击者自己的物理机上,从而实现对虚拟机的完全控制。

2)迁出控制:

通过发起未授权的迁出,攻击者能够将大量的虚拟机迁到一个合法的物理机上,造成其过载,从而实现DoS拒绝服务攻击。

3)虚假资源通告:

在一个动态迁移自动在云主机之间执行的环境中,攻击者可以通过控制平面通告虚假的可用资源,假装拥有很多空闲CPU,从而影响控制平面将虚拟机迁入到攻击者所拥有的物理机上。

目前大多数云平台都需要人工来发起虚拟机迁移,其控制平面的访问控制机制是非常简单的。例如,Xen平台利用主机地址白名单来确定可以执行迁移命令的主体。然而由于基于负载均衡的虚拟机之间的自动化迁移可能横跨了多个管理域,多个管理域内部的主机地址是无法预知的,因此这个白名单机制实用性并不高,需要提出新型的控制平面的策略机制。

2. 动态迁移中数据平面的攻击方法

为了防止监听和篡改攻击,虚拟机迁移的数据平面必须进行安全加固。攻击者有可能利用ARP欺骗、DNS污染、路由劫持等技术将自己置于迁移路径之间,此刻攻击者可以发起中间人攻击。

1)被动监听:

针对数据平面的被动监听攻击可能导致敏感信息的泄露。通过监控迁移路径以及相关的网络数据流,攻击者能够从被迁移虚拟机的内存中提取出很多数据,包括密码、秘钥、应用数据以及其他重要资源。

2)主动修改:

内部攻击者可能在虚拟机进行网络迁移时对内存数据进行篡改,从而造成巨大威胁。这样的中间人攻击可能导致虚拟机完全被攻陷。

即使采用了适当的加密和身份鉴别管理机制,攻击者还是有可能通过监听迁移数据流来捕获关键信息的。例如,攻击者可以通过迁移数据流的特征,如数据迁移大小和耗时来鉴别是哪个虚拟机进行的迁移,从而确定该虚拟机迁移的目标主机。这个信息可能被攻击者用来针对某个特殊虚拟机或者迁移虚拟机所在的主机发起第二轮攻击。

目前主流的云平台,如Xen和VMware,默认都不开启数据平面保护功能,从而造成安全隐患。

3. 动态迁移中迁移模块的攻击方法

执行动态迁移功能的VMM模块需要能够抵御外部的攻击。迁移模块提供了虚拟机迁移的网络服务。通用的软件漏洞,如栈溢出、堆溢出、整数溢出等可能被远程攻击者用来攻陷整个VMM。由于虚拟机迁移一般不认为是一个公用服务接口,因此迁移模块中的代码很可能不像其他部分代码一样经过了严格的源代码安全审计,这就更有可能引发安全漏洞。

这种软件漏洞攻击几乎在各种软件中都很常见,在VMM迁移模块中这种漏洞需要格外注意。由于VMM控制着其上运行的所有虚拟机,因此VMM自身的漏洞相比其他普通软件漏洞的危害要大得多。如果攻击者试图通过迁移模块来攻陷VMM,此VMM上运行的所有虚拟机以及将来可能迁入到此VMM上的虚拟机都会被攻陷。在Xen平台上就曾经多次曝出整数溢出漏洞,这些漏洞都有可能导致整个VMM被攻击者所完全控制,从而造成安全威胁。

三. 现有几种方法的缺点和局限性

1)动态迁移中数据平面的攻击方法和动态迁移中迁移模块的攻击方法只是针对数据平面和迁移模块进行攻击演示,但是一般的云平台的数据迁移都是经过加密的,因此数据平面攻击不会奏效,而针对迁移模块进行攻击需要依靠迁移模块的安全漏洞才能完成,随着云平台软件版本的不断提供,现有的安全漏洞会被不断修复,从而导致无安全漏洞可用,针对迁移模块的攻击方法也就无法实现。

2)现有的动态迁移中控制平面的攻击方法,只是提出了大概概念,缺乏具体的实施方法,因此对实践中的云平台控制平面安全加固指导作用不大。

目前云环境下的虚拟机动态迁移安全问题,主要分为控制平面安全、数据平面安全和迁移模块安全三类。现有的方案主要针对数据平面安全和迁移模块安全进行了安全防护,缺乏对控制平面安全的分析,该领域有待进一步研究。

时间: 2024-10-08 14:20:15

OpenStack虚拟机迁移机制安全性分析的相关文章

Java虚拟机类加载机制——案例分析

原文出处: 朱小厮 在<Java虚拟机类加载机制>一文中详细阐述了类加载的过程,并举了几个例子进行了简要分析,在文章的最后留了一个悬念给各位,这里来揭开这个悬念.建议先看完<Java虚拟机类加载机制>这篇再来看这个,印象会比较深刻,如若不然,也没什么关系~~下面是程序代码: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 package jvm.cla

Openstack针对nova,cinder,glance使用ceph的虚拟机创建机制优化

 今天在开源中国社区看到有如下一个问题: 已经成功把ceph作为cinder和 glance的后端,但是如果作为nova的后端,虚拟机启动速度非常慢,网上查了一下是因为openstack创建虚拟机的时候通过ceph取镜像创建虚拟机再把虚拟机存回ceph的步骤浪费了很多时间,是否有办法不把镜像取到本地,而是直接在ceph的存储池里完成虚拟机的创建呢? 实际上,我当前也是把ceph作为nova,cinder,glance三者的后端,创建虚拟机速度非常慢.查了一下相关和资料,是有新的处理方式,当前

别以为真懂Openstack: 虚拟机创建的50个步骤和100个知识点(2)

二.nova-api 步骤3:nova-api接收请求 nova-api接收请求,也不是随便怎么来都接收的,而是需要设定rate limits,默认的实现是在ratelimit的middleware里面实现的. 然而有时候,我们希望实现distributed rate-limiting,从而Turnstile是一个不错的选择. https://github.com/klmitch/turnstilehttp://pypi.python.org/pypi/turnstile 步骤4:对Token的

在Ceph中创建虚拟机流程改进之分析

作为个人学习笔记分享,有任何问题欢迎交流! 最近在Gerrit中看到一个change:https://review.openstack.org/#/c/94295/ , 它主要是对当前在Ceph中创建虚拟机的流程的改进.如果glance的backend是ceph, 则nova创建虚拟机到RBD的流程是这样的: 通过glance从ceph中下载image --> 本地 --> 复制image到rbd 这个change的目的就是:不需要下载到本地,直接在rbd中复制image,以提高虚拟机创建的速

OpenStack在线迁移

OpenStack迁移需要将虚拟机创建运行在共享存储上才可以进行迁移. 一.配置共享存储 1.环境 OpenStack三个节点icehouse-gre模式部署一文部署了的OpenStack环境. IP如下: controller:10.1.101.11 network:10.1.101.21 compute:10.1.101.31 compute2:10.1.101.41 确保环境配置正确. 修改各个节点的nova.conf中vncserver_listen为: vncserver_listen

虚拟机类加载机制(3)——线程上下文类加载器

之所以将线程上下文类加载器(Thread Context ClassLoader)单独拿出来写,确实是因为它涉及的东西比较多,既然带有线程两个字,一定也是非常重要的一个东西. 我们首先来回顾一下类加载器的双亲委派模型. 在上一章<虚拟机类加载机制(2)——类加载器>中我们解释了何为类加载器的“双亲委派模型”,知道了双亲委派模型给我们带了一个好处就是Java类随着它的类一起具备了一种带有优先级的层次关系.简单的例子就是Object类在程序的各种类加载环境中都会由启动类加载器来加载,换言之,它无论

SEAndroid安全机制框架分析

我们知道,Android系统基于Linux实现.针对传统Linux系统,NSA开发了一套安全机制SELinux,用来加强安全性.然而,由于Android系统有着独特的用户空间运行时,因此SELinux不能完全适用于Android系统.为此,NSA针对Android系统,在SELinux基础上开发了SEAndroid.本文就对SEAndroid安全机制框架进行分析,以便后面可以更好地分析其实现细节. 老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注! SEAnd

虚拟机类加载机制详解

目录: 1.类加载的时机 2.类加载的过程 3.类加载器 一.类加载的时机 类从被加载到虚拟机内存中开始,到卸载除内存为止,他的整个生命周期包括:加载(Loading).验证(Verification).准备(Preparation).解析(Resolution).初始化(Initialization).使用(Using)和卸载(Unloading),这七个阶段的发生顺序如下图 上图中,加载.验证.准备.初始化和卸载这5个阶段的顺序是确定的,类的加载过程必须要按照这种顺序按部就班地开始,而解析阶

转载---虚拟机类加载机制

虚拟机类加载机制  虚拟机把描述的类的数据从class文件加载到内存后,并对数据进行校验,转换解析和初始化,最终形成可以被虚拟机直接使用的Java类型,这就是虚拟机的类加载机制.  类加载的时机 类被加载到虚拟机内存开始,到卸载出内存为止.它的整个生命周期包括:类加载(Loading),验证(Verification),准备(Preparation),解析(Resolution),初始化(Initialization),使用(Using)和卸载(Unloading)7个阶段.其中验证,准备,解析