浅谈网络虚拟化安全
浅谈网络虚拟化安全
摘要:本文简要介绍了网络虚拟化的发展,分析了网络虚拟化方面的一些安全问题,并给出了一些可行的措施
关键字
网络虚拟化
安全
SDN OpenFlow
经过多年的技术准备和商业模式探索,云计算已然进入快速发展的阶段。当前有不少大型数据中心和的企业
IT
系统可为云计算提供设施级别的强大支撑平台,然而业务快速增加给数据中心和大型企业的复杂网络管理带来了极大的挑战。网络虚拟化技术和软件定义网络(
SDN
,
Software Defined Networking
)技术以软件可编程的方式管理虚拟和实体网络资源,很大程度上解决上述问题,近年来得到了极大的关注。本文主要介绍了面向数据中心和企业级应用的网络虚拟化技术,并探讨网络虚拟化对于传统安全的挑战,与之可能的安全解决技术。
1 网络虚拟化技术简介
在虚拟化应用中,大规模应用对计算和存储的天然需求使得计算虚拟化和存储虚拟化技术较为成熟,与之相比,网络虚拟化的相关技术还在开发阶段,远没有达到成熟的程度。不过随着应用规模不断变大和业务快速变化,实体和虚拟网络的融合、快速管理和可扩展性将成为巨大的挑战,网络虚拟化已受到越来越多的关注,可预计其发展会进入快车道。
网络虚拟化将物理和虚拟网络资源整合成一个可管理的虚拟网络,特别
SDN
的出现对网络管理带来了颠覆性的变化:可通过编程的方式迁移虚拟机、动态组网,大大加快变更网络拓扑的进度。
ONF
指出
SDN
具备三个核心特征
[1]
:控制平面和数据平面相互分离、智能和状态在逻辑上集中以及底层网络基础设施从应用中抽象出来。
SDN
是层次化的集中控制架构,如图
1
所示:网络控制器处于
SDN
架构的中心,北向与应用连接,进行业务交互;南向连接底层的交换机,下发路由控制命令。功能上,网络中心的控制器掌握网络拓扑、数据转发的策略,而分布在各处的网络设备接受控制器的命令,执行数据转发和路由的行为。操作上,网络管理员可以随时更新网络拓扑、调整网络规模,或快速部署安全策略,如果操作失败或存在问题可方便的进行回滚恢复到原来的状态,可见
SDN
确实提供了快捷方便的网络管理途径。
图
1 SDN
的应用实例
需要说明的是网络虚拟化、
SDN
和
OpenFlow
三者不是等价的。网络虚拟化可以不使用
SDN
技术,
SDN
也不一定要用于虚拟化环境,但
SDN
的控制数据平面分离非常适合网络虚拟化的场景。同样地,
OpenFlow
是一种可实现
SDN
场景的控制器
–
设备协议,但非唯一的
SDN
实现方式,还如
NVGRE
等技术。本文在讨论网络虚拟化时都是基于
SDN
的,所采用的协议标准是
OpenFlow
。
主流的网络虚拟化解决方案
通过软件重构网络是大势所趋,不同厂商在
SDN
中根据自身情况制定各自的策略,总体来说,
SDN
的研发领域可能会出现三足鼎立的局面:
OpenFlow
标准的相关开源系、
Cisco
主导的
Cisco One
系和
Vmware
主导的
SDN
系,参与三个体系的厂商关系如图
2
所示。
图
2 SDN
厂商阵营图
1.2.1 OpenFlow/ONF
当前参与量最大的开放
SDN
阵营是由
90
多家公司组成的非盈利组织组成的
ONF
(
Open Networking Foundation
),其成员不乏
IBM
、
Intel
、
等重量级的公司,还有
BigSwitch
、
Citrix
等专注虚拟化的公司,此外还有国内的企业如腾讯、华为和中兴等。
ONF
最重要的成果是
OpenFlow
,
OpenFlow
是网络控制器和交换机之间通信的协议,控制器通过统一的路由策略下发基于流的数据交换命令,实现了上层软件管理和更新路由表、底层交换机执行转发策略的软硬件分离模式。
OpenFlow
协议处理数据的过程如图
3
所示,交换机在遇到未知模式的数据包时,会向控制器上传相关特征,控制器检查自己的策略库,生成数据交换的模式,然后将这些模式以控制信息的形式下发到对应的交换机,从而底层的交换机可以根据全局的路由策略执行相应的数据交换。
由于
OpenFlow
定义了控制器和交换机间的通信协议和安全通道,并规定交换机应遵循的规则,交换机只执行数据交换的功能,所以各厂商容易开发出支持
OpenFlow
的交换机,如
Nicira
的虚拟交换机
Openvswitch
和
NEC
和
IBM
等支持
OpenFlow
的实体交换机。对应地,控制器负责整个
SDN
中的网络拓扑管理、数据包路由决策、
QoS
管理和安全控制等复杂的功能,所以控制器是整个网络的核心,当前比较著名的控制器有
BigSwitch
的
floodlight
、
Nicira
的
nox
和
NEC
的
ProgrammableFlow Controller
等。
OpenFlow
只定义了控制器
–
交换机的南向通信标准,没有给出应用
–
控制器的北向接口标准,所以相关厂商可以针对控制器开发自己的网络应用时,需要考虑不同控制器的应用接口。
图
3
基于
OpenFlow
协议的数据交换
1.2.2 Cisco One
2012
年
7
月,
Cisco
公司推出了自己的
SDN
计划
“
思科开放式网络环境
(
Cisco ONE
,
Open Network Environment
)
“
。
Cisco ONE
在 实现网络环境的可编程性的同时,有更大的战略规划:它将
SDN
定位于五个目标市场:学术和研究、企业、服务提供商、云服务提供商和数据中心,并认为
OpenFlow
只是其中的学术和研究市场。
Cisco ONE
是对
OpenFlow
功能的扩展,包括
Cisco onePK
开发套件和
Nexus 1000V
等虚拟覆盖网等技术。其中
Nexus 1000V
包含了控制器
Virtual supervisor module (VSM)
和交换机
Virtual Ethernet module (VEM)
,实现了完整的
SDN
功能。
1.2.3 VMWare/Nicira
老牌虚拟化巨头
VMware
在网络虚拟化方向也有大量投入。早在做研发服务器虚拟化时,
VMware
就使用虚拟网桥和
NAT
的方式建立了宿主机和虚拟机之间虚拟网络。在最新的企业级虚拟化产品
vSphere
中,网络虚拟化解决方案要有两方面:管理虚拟网络中的数据和流量的
Network I/O Control
,以及集中式管理、监控和可视化虚拟网络的
Distributed Switch
。
此外,
VMware
于
2012
年收购了
Nicira Networks
公司,后者主导开发了虚拟交换机项目
Openvswitch
。可预见
Vmware
将
Nicira
的网络控制器等产品集成到
vSphere
后,会在
SDN
方向进一步发力,保持其在虚拟化市场中领先的地位。
网络虚拟化面临的安全挑战
虚拟化给数据中心和企业网络带来了新的问题和挑战。一方面,传统的安全产品和安全解决方案无法解决在虚拟化后出现新的网络安全问题;另一方面,网络虚拟化自身也面临一些安全问题。网络在虚拟化后主要的问题有:
- 物理安全设备存在观测死角
虚拟机与外界存在数据交换,在虚拟化环境中的数据流有两类:跨物理主机的
VM
数据流和同一物理主机内部的
VM
数据流。前者一般通过隧道或
VLAN
等模式进行传输,现有的
IDS/IPS
等安全设备需要在所有的传输路径上进行监控,后者只经过物理主机中的虚拟交换机,无法被实体的安全设备监控到,成为整个安全系统的死角。攻击者可以在内部虚拟网络中发动任何攻击,都不会被安全设备所察觉。如图
4
中攻击者在虚拟机
VM1
中攻击
VM2
,数据流量没有经过物理交换机的,也不会传输到防火墙和
IDS
。所以虚拟化改变了数据的流向,增大了大量物理设备不可见的区域,增加了整个虚拟化网络的安全管理难度。
图
4
物理安全设备无法观测到内部虚拟网络的数据交互
- 虚拟网络的数据流难以理解
虽然安全设备无法获得物理主机内部的
VM
间的数据包,但可以获取跨物理主机间
VM
的数据流。尽管如此,传统的安全设备还是不能理解这些数据流,也就无法应用正确的安全策略。例如在图
5
中,租户
X
和租户
Y
分别在两台物理主机上租用了一台虚拟机,当租户
X
从
VM1
向
VM3
发数据包时,防火墙能接收到物理主机
1
到物理主机
2
的数据包,但不知道到底是租户
X
还是租户
Y
的程序在发送数据包,也不知道是哪两台
VM
在通信。此外,很多虚拟机之间的数据包是经过
GRE
隧道传输的,所以传统的网络安全设施可能不能解析这些封装后的数据流。
图
5
物理安全设备不能理解跨物理主机间数据流
- 安全策略难以迁移
虚拟化解决方案的重要优点是弹性和快速,例如当
VM
从一台物理主机无缝快速地迁移到另一台物理主机时,或当增加删除
VM
时,网络虚拟化管理工具可快速调整网络拓扑,在旧物理网络中删除
VM
的网络资源(地址、路由策略等),并在新的物理网络中分配
VM
的网络资源。相应地,安全解决方案也应将原网络设备和安全设备的安全控制(
ACL
和
QoS
)也跟随迁移,然而现有安全产品缺乏对安全策略迁移的支持,导致安全边界不能适应虚拟网络的变化。
- 网络流量不可见
在传统网络中,所有数据包经由交换或路由设备,这些设备具有可以感知并学习当前环境的数据流量,可以针对目前的网络状况动态调整路由策略。但基于
OpenFlow
的
SDN
架构中的网络控制器只会收到底层设备发来的部分的数据包,并不了解控制域中大部分直接被转发的数据流具体内容。
- 控制器的单点失效
除了传统网络升级到
SDN
后网络层的新问题外,
SDN
本身也会存在漏洞,特别是复杂的
SDN
的控制器。数据平面和控制平面的分离主要是由控制器实现的,所以控制器就成为了网络虚拟化的最重要的设施。
然而控制器需要应对各种动态的网络拓扑、解析各种类型的数据包、接收上层应用的信息,并控制底层网络设备的行为,所以功能实现将会非常复杂,也就可能存在不少漏洞。当攻击者攻破控制器,就可以向所有的网络设施发送指令,很容易瘫痪整个网络;或将某些数据流重定向到恶意
VM
,造成敏感信息的泄露。
- 多应用不一致策略导致绕过控制器
控制器控制整个网络的拓扑,处理几百甚至上千个应用的路由策略,每个应用的路由路径可能不同,那么如果这些不同应用产生的路由项之间存在不一致,就可能会出现非法路径。
Porras
等人提出图
6
的攻击场景
[2]
,系统根据安全策略应禁止主机
10.0.0.2
与主机
10.0.0.4
通信,但如果控制器中有三项看似合法的不同应用需要的路由策略,那么当数据包从
10.0.0.2
传输到
10.0.0.3
,会在交换机上被替换掉源和目的地址,成为从
10.0.0.1
传输到
10.0.0.4
的数据包,最终被允许转发,而这原本应该是被禁止的。可见控制器中的路由项如果不一致,攻击者就有可趁之机绕过控制器实施攻击。
图
6
控制器上三条合法策略组形成一条非法路径
- 控制信息难验证
除了攻击控制器外,控制器和网络设备间的通信也可能存在安全问题。虽然
OpenFlow
协议规定两者通信可使用加密的通道,但如何保证交互双方可信是一个问题。
一方面,攻击者假冒网络控制器,发送恶意控制命令即可改变网络拓扑、破坏安全策略,或修改数据流绕过防火墙。另一方面,攻击者也可以通过控制某些网络设施,向控制器发送伪造的数据包,影响控制器对网络流量的判断。
如果不解决网络虚拟化后产生的安全威胁,就可能会破坏整个网络的可用性和可靠性,造成租户的隐私泄露,并给攻击者后续攻击内部
VM
提供条件。
3 网络虚拟化的安全对策
本章主要针对探讨虚拟化环境中出现的安全问题,提出一些可行的安全对策。首先是确保新增的网络设施的安全,然后检测虚拟资源的安全性,最后设计自动高效的安全控制
–
网络控制联动机制。
3.1 保护 SDN 网络的虚拟资源
传统的网络安全认为被攻击目标有应用、服务器和实体网络,
SDN
场景还增加了网络控制器和虚拟网络设备,所以网络虚拟化安全的第一步就是要保证这些新资源的安全。
3.1.1 设计安全可靠的网络控制器
网络控制器是
SDN
网络的中心,也是其前置安全保证,所以保障网络虚拟化必须设计一个高可信、安全和健壮的网设计控制器。
首先,控制器需要加入审计机制,检查访问控制器的用户,保证是合法可信的,避免恶意攻击者发动各类攻击,并记录原始日志,做到定时或事后检测异常行为。
其次,保证控制器和交换设备的通信安全,如
OpenFlow
协议就要求两者通信必须存在一个加密通道,需防止中间人攻击。
最后,针对内部攻击或管理员不正确的配置,安全产品可实时或定时检测控制器的路由规则是否兼容并满足安全需求。如针对前面提到的”控制器不一致策略”问题,
Porras
等针对控制器
Nox
设计了一个第三方插件
FortNox
,可实时检测规则是否冲突。
3.1.2 保证虚拟网络设备安全
在大二层交换网络中,虚拟网络设备主要是指支持
OpenFlow
的虚拟交换机,如果交换机出现异常,会造成网络拓扑变化,甚至会影响控制器的正常工作。
为保护虚拟交换机,需要及时更新
Hypervisor
软件,防止攻击者逃逸虚拟机后利用被攻破的虚拟交换机发送恶意或异常的消息。
此外,应设计网络设备配置的一致性检查,避免发生网络风暴,减少控制器端收到的非必要
PacketIn
数据包请求。
3.1.3 保证控制器和网络设备的通信安全
当前
OpenFlow
协议中规定控制器和交换机之间的通信使用
TCP
或
TCP/TLS
协议,如果使用不加密的
TCP
方式,攻击者很容易伪造交换机的消息,扰乱控制器所获知的网络拓扑;但如果使用认证的加密方式,在大规模网络中控制器容易遭受拒绝服务攻击。所以设计一个轻量级可认证的通信方式,保证控制器收到的消息秘密性、完整性和可用性,将是一个重要的研究课题。
3.2 推出支持虚拟化的安全产品
针对传统安全产品对内部网络不可见的缺点,安全厂商需推出支持虚拟化的安全产品,这些安全产品以软件的形式存在,并兼容主流的虚拟化解决方案,可监控内部虚拟网络中的数据流。一般而言,支持虚拟化的安全产品通常有 虚拟机形态和
Agent
形态。前者可以不对网络拓扑和计算节点不进行任何改动,非常方便,但缺点是安全产品容易遭到被感染的虚拟机的攻击,配置也比较复杂;后者可感知虚拟机和网络变化并应用策略,而且产品部署在
VM
不可见的
Hypervisor
层面,在很大程度上减少了对安全产品的攻击,但需要修改物理主机的系统。可预见虚拟机形态和
Agent
形态会相互配合,与安全控制器协同,完成较完备的安全功能。
3.3 设计软件定义的安全解决方案
要想达到真正的软件定义安全(
SDSec, Software-Defined Security
),就需要在保护现有和新增设备,以及内部虚拟网络的基础上,深刻理解
SDN
的工作模式,提出松耦合但与之匹配的安全架构,设计网络控制器和安全控制器联动的安全机制,建立基于环境的数据传输决策模型。
SDN
网络与传统网络的最大不同是可编程化(
programmable
),整个网络的数据流和拓扑都是在控制器的指令下快速变化,那么安全产品必须理解这种变化,并能程序化地快速自动调整底层设备策略。对于虚拟化场景下的主体,
Vmware
公司首席安全和网络架构师
Rob Randell
认为可被分成三级
[3]
:虚拟数据中心
vDC
、虚拟应用
vApp
和虚拟机
VM
(如图
7
所示),然后将各类安全应用根据功能组成策略模板,最后多个策略模板可以组成若干个安全组。安全组间能组成复杂的策略,应对不同级别的主体。那么对于一个虚拟化应用而言,不管其
VM
分布在何处,也不管其数据流的路径是什么,总能建立安全组的结构,使之能处理该应用的工作流(
workload
),实现安全管理的功能。
图
7
虚拟化场景下安全策略的分解
结论
SDN
和
OpenFlow
将网络的逻辑视图与物理视图分离,使得网络配置更加灵活,硬件设备成本大大下降,是计算机网络的又一次革命。
SDN
带来了巨大的便利的同时,也带来了大量尚未解决的安全问题。本文在分析了
SDN
的安全挑战后,给出了一些安全对策。
虽然网络虚拟化为数据中心和企业的网络安全带来了巨大的挑战,但也给网络安全防护带来了提供了新思路和新方法,如
SDN
集中式控制提高产品防护能力、为快速重定向可疑的
DdoS
流量、快速自动地构建攻防实验网络,并降低安全产品的成本。所以研究虚拟环境下的安全问题,研发支持
SDN
的安全产品对保护整个虚拟化网络是必要且有益的。
1 F5 Networks
:
SDN
与
ADN
竞争还是合作?
2 Phillip Porras, Seungwon Shin, Vinod Yegneswaran, Martin Fong, Mabry Tyson, Guofei Gu. A Security Enforcement Kernel for Openflow Networks. Proceedings of the ACM Sigcomm Workshop on Hot Topics in Software-Defined Networking (HotSDN), August 2012.
3 Rob Randell, How the software defined datacenter is turning security on its head, RSA conference, 2013