松耦合云环境下的虚拟网络异常实体检测研究

张舟远 吴承荣 叶家炜

(复旦大学计算机科学技术学院 上海 200433)(教育部网络信息安全审计与监控工程研究中心 上海 200433)

0 引 言

随着云计算技术应用规模的不断扩大，对数据中心网络的要求也逐渐提高。由于传统网络在拓扑和IP地址空间等方面存在着固有缺陷[1]，为了克服这些缺陷，就产生了网络虚拟化的基本需求。

网络虚拟化技术[2]可以将一个物理网络划分为多个完整而又彼此隔离的逻辑网络，即虚拟网络。这些虚拟网络通过同一套物理设备提供给云平台中不同的租户。租户可以通过自定义的方式向云管理人员申请并获得具备自己所需要的拓扑结构和IP地址空间的网络，从而满足了新型数据中心的需求。对于租户而言，除了上述需求外，虚拟网络的安全问题也是非常需要关注的问题。与传统物理网络不同，虚拟网络中的网络设备既包括了传统的物理网络设备，又包括了部署在物理服务器上的虚拟网络设备。因此虚拟网络除了需要应对传统的网络安全问题以外，还需要有应对新的网络安全的能力。

当前的主流云平台，尤其是以OpenStack为代表的开源云平台，其整体架构大多都是松耦合的。在这样的整体架构下，云平台中的各层次，每个层次中的各模块都可以独立进行设计开发和维护，带来极大的便利。但与这种便利相对应的，则是层次和层次之间的依赖性降低，缺乏良好的反馈机制。当底层出现状况的时候，上层往往难以及时发现这些问题，从而给整个系统带来安全隐患。虚拟网络异常实体问题就是其中的一种安全问题。所谓虚拟网络异常实体，指的是云平台中没有正常地在云管理平台以认证和发出请求的方式，而是以直接调用底层的相关管理工具或者是API的方式直接添加、删除或者是改变配置的虚拟网络端口以及连接在该端口上的虚拟机。

本文对松耦合云环境下出现虚拟网络异常实体问题的原因进行了探讨，提出一种能够及时发现虚拟网络异常实体的方案，并通过实验对该方案的有效性加以验证。

1 相关工作

网络安全历来是一个非常重要的问题，而随着虚拟网络的出现和发展，网络安全问题也迎来了新的挑战。一般认为，虚拟网络由于可以使用更为细粒度的访问控制，因此安全性要高于传统网络。早在2008年和2009年，文献[3-4]就指出了虚拟环境下存在通过攻击Hypervisor获取整个系统控制权，进而实施其他攻击手段的安全问题。尽管当时主要把研究重点放在了虚拟机安全管理上，但随着网络虚拟化技术在云计算中的大量应用，无论是学术界还是工业界也都已经开始对虚拟网络的安全问题进行了相关研究，提出各自的解决方案。

学术界的主要研究思路是基于开源软件来提出并开发相应的解决方案。例如，文献[6]将处于同一虚拟网络的虚拟机放置于同一台物理机中，并将物理网卡配成多IP模式作为地址池，物理网卡与支持网络虚拟化的物理交换机相连，物理机与物理交换机之间通过部署防火墙来实现网络安全。文献[7]则在每台物理机的Hypervisor上部署了沙盒，并基于安全策略来保证虚拟机的网络安全。文献[12]探讨了软件定义网络(SDN)环境下的虚拟网络安全问题。文献[13]进一步将SDN和NFV(网络功能虚拟化)集成到OpenStack中，提高其网络安全性。文献[14]通过将入侵检测系统(IDS)和蜜罐网络集成到云环境中的方法实现减轻已知和未知的攻击。此外，还有部分研究将重点放在了虚拟网络中传输数据本身的安全上，例如文献[11]设计了一种基于加密传输的网络虚拟化系统来保证网络中数据的安全。

工业界根据搭建虚拟网络的解决方案的不同，有着不同的虚拟网络安全机制。主要分为两种：(1) 以VMWare和Cisco(思科)为代表的商用虚拟网络解决方案；(2) 以OpenStack为代表的开源虚拟网络解决方案。

商用解决方案包括了以VMware为代表的软件解决方案和以Cisco为代表的硬件解决方案。其中：VMware提出了一种名为NSX[8]的虚拟网络解决方案和产品，该产品底层使用了VMware自己开发的VDS虚拟交换机，上层则和VMware vSphere相结合，各层次之间耦合度很高，具备非常良好的交互与反馈机制，管理人员可以很好地掌握整个系统的运行情况；Cisco则提出了一套名为ACI[9]的虚拟网络解决方案，该方案的特点在于其仍将硬件作为虚拟网络的核心，所有对网络的操作都是基于硬件设备能力来实现的，并且采用了新的网络协议，使得其相比较于使用乐高积木式组建网络的软件方案的功能更为强大。

以OpenStack[5]为代表的开源云平台则采用了轮询的方式来检测虚拟机的网络连接，一旦发现虚拟机没有连接到虚拟网桥上就会通过管理工具在对应的网桥上重新创建虚拟端口。但由于设计这一机制的目的是为了解决虚拟交换机运行时自身出现故障的问题。因此只能判断虚拟机所对应的虚拟端口是否存在，既无法保证虚拟端口是否被正确配置，也无法感知不受OpenStack管控的虚拟端口。其各不同层次的组件通常分属不同的开源产品，虽然每个产品都能够提供一定程度的安全管理机制，但由于层次间的耦合程度低，尚未出现一个系统的统一安全管理方案，也没有专门针对虚拟网络异常实体问题进行过相关设计。本文主要针对松耦合架构的开源云平台下存在的虚拟网络异常实体问题进行研究。

2 虚拟网络异常实体问题分析和检测

2.1 松耦合云环境下的虚拟网络异常实体问题

图1以OpenStack为例，展示了松耦合云环境下虚拟网络的典型结构。租户或管理员通过云平台Portal提供的图形化界面进行配置，云平台通过分别调用Nova和Neutron的相关API对底层设备进行操作。

图1 OpenStack环境下虚拟网络典型结构

在这样的结构下，各层次之间缺乏良好的反馈机制，只有在上层调用下层提供的服务时，下层才会将执行结果返回上层，下层本身不会主动向上层报告自身的运行情况。这是因为在OpenStack环境下，云平台的下层，即资源调度层和资源层，大量使用了第三方软件，而这些第三方软件本身不具备主动对上层反馈的机制。在正常情况下，租户或管理员经过云平台Portal的认证，自上而下一层一层地对虚拟交换机进行操作，每一层都会将调用结果反馈给上层并且在日志中留下记录，因此这样的设计不存在问题。然而在非正常情况下，例如没有经过云平台的认证而是直接调用底层虚拟交换机提供的管理工具进行操作时，由于底层设备不会主动向上层报告，因此上层的云管理平台无法及时获取相关的信息并加以处理，从而导致虚拟网络异常实体的出现。这些异常实体或者成为垃圾资源无法正常使用，从而影响租户的正常业务，或者成为攻击者的“肉机”或跳板，从而危害整个系统安全。

根据对虚拟交换机的不同操作，虚拟网络异常实体可以分为两类：(1) 不受OpenStack管控的虚拟网络端口及相关联的虚拟机；(2) 被篡改网络配置的虚拟网络端口及相关联的虚拟机。下面分别介绍这两类虚拟网络异常实体及其形成原因。

第一类虚拟网络异常实体，即不受OpenStack管控的虚拟网络端口及相关联的虚拟机，指的是攻击者绕过云管理平台的认证机制，直接调用Open vSwitch等虚拟交换机提供的管理工具，将不属于OpenStack管控的虚拟机接入OpenStack网络中。这些虚拟机无法通过OpenStack进行管理，但是可以作为内部网络成员和所接入网络内的虚拟机正常通信，且不受部署在虚拟网络边界的网络安全系统如防火墙等的影响。同时，由于将虚拟机接入OpenStack网络的操作没有经过OpenStack的任何一个模块，因此OpenStack既无法感知这些虚拟机，也无法发现虚拟机接入网络的任何操作，于是就会产生第一类虚拟网络异常实体。

第二类虚拟网络异常实体，即被篡改网络配置的虚拟网络端口及相关联的虚拟机，包括两种情况：(1) 通过篡改虚拟网络端口的配置使虚拟机接入其他网络；(2) 通过篡改虚拟网络端口的配置将虚拟机从虚拟网络中删除。在这两种情况下，虚拟机的网络配置都和云管理平台中所记录的网络配置不同，从而形成异常实体。由于OpenStack的架构是松耦合的，其主要模块无法通过底层的主动报告来获取其运行情况，而只能采用定时轮询的方式检测虚拟网络端口的配置是否正确。如果轮询的时间间隔设置得合适，并且能够将发现的异常实体及时报告给安全管理人员的话，这也不失为松耦合架构下的一种可行的安全措施。然而OpenStack的定时轮询机制并不是作为一种安全机制而设计的，而仅仅是为了防止底层的虚拟交换机自身在运行时出现错误，从而保证云管理平台下发的各种指令能够正确执行。正是出于这一目的，OpenStack在发现虚拟网络端口的配置与自身数据库中记录的不同时，只会根据自己记录的信息重新配置虚拟网络端口，而不会向安全管理人员报告，也不会留下任何日志信息供安全管理人员查看。

为了验证上文所论述的异常实体的存在和危害，本文绕过OpenStack平台，直接对虚拟交换机Open vSwitch进行了以下操作：

操作1：使用ovs-vsctl add port命令，将不受OpenStack管控的虚拟机接入OpenStack网络中。

操作2：使用ovs-vsctl set port命令，改变虚拟网络端口配置，从而将相关联的虚拟机接入另外的网络中。

操作3：使用ovs-vsctl del port命令，删除虚拟网络端口，从而将相关联的虚拟机从网络中删除。

每次操作前都先将OpenStack恢复原状，通过这些操作并分别查询Dashboard界面、Neutron日志以及虚拟机本身情况，结果如表1所示。

表1 异常实体问题验证结果

由此可见，OpenStack中出现的两类虚拟网络异常实体既不能通过Dashboard界面进行监控，也不能通过查询Neutron日志进行事后排查，这一点必须引起安全管理人员的重视。

2.2 虚拟网络异常实体检测方案

2.2.1 基本原理

上文曾经提到，定时轮询方案可以作为一种可行的虚拟网络异常实体的检测方案，而OpenStack现有的定时轮询方案还存在着一些问题。本文基于OpenStack的定时轮询思想，并作出一些改进，在不对云平台本身进行改动的前提下提出一种针对虚拟网络异常实体的检测方案。本方案的基本原理是对Open vSwitch和OpenStack中分别记录的虚拟网络信息进行比对，如果发现记录不一致，则存在虚拟网络异常实体。其中：Open vSwitch中记录的是虚拟机的实际网络配置信息，而OpenStack中记录的则是虚拟机应当具备的网络配置信息。本方案的工作流程如图2所示。

图2 虚拟网络异常实体检测流程

根据本方案编写的虚拟网络异常实体检测程序利用Linux提供的cron服务定时启动，并且按照以下步骤工作：

(1) 参数收集 首先需要收集两部分重要参数作为输入。一部分是Open vSwitch的所有连有虚拟机的端口以及这些端口上所连接的虚拟机信息。另一部分是OpenStack上所存储的虚拟机相应的信息以及这些虚拟机的相应网络信息。

(2) 异常检测 用步骤1中所获取的两部分虚拟机信息以及虚拟网络端口信息进行比对，从而发现网络中不受OpenStack管控的第一类虚拟网络异常实体以及OpenStack中实际网络配置和云管理平台中记录的配置不同的第二类虚拟网络异常实体。

(3) 安全告警 如果在异常检测这一步骤中发现了虚拟网络异常实体，那么会在数据库中生成一条告警记录。这条告警记录的信息会及时通过有效的反馈机制告知安全管理人员。

2.2.2 具体实现

根据上文的工作流程具体描述虚拟网络异常实体的检测实现细节。

(1) 参数收集的实现 在检测开始前，需要分别对Open vSwitch上的信息集合(记为Ov)和OpenStack上的信息集合(记为Op)进行信息收集。其中，Ov中的每一项都对应了Open vSwitch中的一个连有虚拟机的虚拟网络端口信息，对于每一个端口可以收集到的信息包括端口名、端口UUID、端口VLAN tag、对应VxLAN的标识VNI、虚拟机UUID、虚拟机MAC地址等。这部分信息中，VNI信息需要从Open vSwitch的流规则中提取，其余所有信息都可以从Open vSwitch的数据库，即ovsdb中获取。Open vSwitch分别提供了ovs-ofctl和ovsdb-client两个管理工具来获取这一部分信息。这里需要特别指出的是，虚拟机的UUID信息和MAC地址信息有可能因为攻击而无法从ovsdb中提取，这时需要调用Libvirt API来获取这些信息。

而Ov中的每一项对应OpenStack中的一台虚拟机及其网络的配置信息，包括虚拟机UUID、虚拟机MAC地址、虚拟机IP地址、VxLAN标识VNI和虚拟网络UUID等。这一部分信息可以分别从Neutron数据库中的ports表、ml2_network表和ipallocations表中提取。为此，可以建立一张视图汇总这方面的信息，如图3所示，图中的device_id、mac_address、ip_address、segmentation_id和network_id字段分别对应了上述信息。

(2) 异常检测的实现 在完成参数收集的工作后，首先开始遍历Ov中的每一项，检查Ov中的每一项(记为Ovi)所记录的虚拟机UUID是否都包含在Op中，如果不在Op中，则可以判定系统中有存在第一类虚拟网络异常实体；如果虚拟机UUID包含在Op中，那么继续比对这台虚拟机在Ov和Op的记录中是否在同一网络中；如果不在同一网络中，那么可以判定系统中存在第二类虚拟网络异常实体且属于第一种情况；在完成对Ov的遍历后，继续遍历Op中的每一项(记为Opi)，检查是否每台虚拟机都在Ov中有记录，如果没有，那么可以判定系统中存在第二类虚拟网络异常实体且属于第二种情况。这一过程可以用图4所示的流程图来表示。

(3) 安全告警的实现 虚拟网络异常实体的告警记录包含的内容如表2所示。告警信息应当及时通知安全管理人员处理，本文使用网页展示的方式进行通知。实际应用中也可以使用电子邮件、短信通知等其他有效的方式。

表2 异常实体数据库表格式

续表2

3 实验验证

3.1 实验环境

本文的实验环境部署在3台硬件配置相同的物理服务器上，详细配置见表3。我们使用这3台服务器搭建了一套小型的OpenStack环境。物理服务器操作系统为CentOS 7，其中一台作为控制节点，安装了MariaDB数据库，其余两台作为计算节点，并使用Open vSwitch作为虚拟交换机来搭建虚拟网络。

表3 物理服务器配置

我们用Python语言编写了用于检测虚拟网络异常实体的脚本程序，并如图5所示部署在计算节点的操作系统上。然后开启Linux提供的cron服务，使用crontab命令配置任务，将该脚本程序设置为每分钟执行一次。控制节点上部署了Java运行环境，使用Java Web技术开发安全告警事件的展示页面，用于展示检测程序写入数据库的安全告警事件。

图5 异常实体检测程序物理部署

3.2 实验设计和结果

为了验证本文提出的虚拟网络异常实体检测方案的有效性，本文通过模拟产生虚拟网络异常实体进行测试实验。通过比较OpenStack的Dashboard页面和虚拟网络异常实体展示页面中是否能够将这些模拟产生的异常实体正确显示来进行功能验证。其中：对于OpenStack，主要查看虚拟网络拓扑信息和相关操作日志；对于展示页面，主要查看是否正确列出了告警事件。在开始实验之前，首先查看原始的OpenStack网络拓扑信息，如图6所示。

图6 OpenStack原始虚拟网络拓扑

本次模拟实验将利用Open vSwitch提供的管理工具ovs-vsctl命令，绕过OpenStack的认证和请求机制，直接把图6中的一台名为demo的虚拟机以篡改虚拟网络端口配置的形式从admin-net2网络移动至admin-net网络。

首先登录demo虚拟机所在的计算节点Compute1，并查看确认Open vSwitch中现有虚拟网络的配置情况，如图7所示。通过OpenStack的Nova模块可以查出，虚拟机demo连接在Open vSwitch上的虚拟端口是qvo44f28f88-20。通过Neutron模块和ovs-db可以查出，admin-net对应在Compute1上的Open vSwitch虚拟网络VLAN tag是1，admin-net2对应的VLAN tag是3。于是使用ovs-vsctl set port qvo44f28f88-20 tag=1命令就实现了把虚拟机demo从原本所在的admin-net2网络篡改到了admin-net网络，从而成功模拟出来第二类虚拟网络异常实体。成功模拟攻击后，分别查看OpenStack的Dashboard界面上的网络拓扑以及虚拟网络异常实体展示页面，结果是OpenStack上显示的网络拓扑与改变网络以前完全一致，并未发现系统中出现了异常实体。而在异常实体展示页面上，则可以看到详细的告警信息，告知管理人员虚拟网络异常实体所在的主机、异常实体的类型、被检测出的时间、相关联的Open vSwitch虚拟端口名称、虚拟机的UUID、MAC地址以及攻击前后端VLAN tag等，并提示安全管理人员进行处理。

图7 Open vSwitch端口信息

实验表明，本文设计的虚拟网络异常实体检测方案确有实效，其他类型的虚拟网络异常实体可以通过类似的实验加以证明。

4 结 语

本文探讨了当前以OpenStack为代表的松耦合架构的云平台中存在的虚拟网络异常实体问题，并提出了一种检测方案。该方案可以及时有效地发现系统中存在的虚拟网络异常实体，并通过实验验证了这一点。在接下来的工作中，我们准备结合操作日志，引入日志关联分析的有关技术来还原这些异常实体产生的操作现场，使得安全管理人员不仅能够及时发现问题，还能查明问题产生的原因，从而能够更加全面地掌握系统的运行情况，最终可以更加高效地处理这些安全问题。