第2章 SDN/NFV环境中的安全问题
1.架构安全
SDN强调了控制平面的集中化，从架构上颠覆了原有的网络管理，所以SDN的架构安全就是首先要解决的问题。例如，SDN实现中网络控制器相关的安全问题。
1.1 SDN架构的安全综述
从网络安全的角度，SDN带来了网络架构的革新，也引入了新的安全威胁和挑战。从架构层面来看，新引入的SDN控制器由于逻辑集中的特点，自然易成为攻击的对象；开放的API接口也使应用层的安全威胁将扩散到控制层，进一步威胁到基础设施层承载的用户业务；SDN控制层和基础设施层之间新引入的协议，如OpenFlow协议及其实现，需要经过长期的安全评测；在基础设施层，SDN交换机在控制器的控制下完成流转发，SDN数据流也可能面临由南向协议、控制层相关的安全问题导致的威胁。
1.2 集中控制平面：SDN引入的新问题
控制器承载着网络环境中的所有控制功能，其安全性直接关系着网络服务的可用性、可靠性和数据安全性。攻击者一旦成功实施了对控制器的攻击，将造成网络服务的大面积瘫痪，影响控制器覆盖的整个网络范围。同时，控制器具有全局视野，它从各交换机收集了全局拓扑，甚至全局流信息。
脆弱的SDN控制器的具体安全风险如下。
- 可通过流的重定向使流绕过安全策略所要求的安全机制，从而使安全机制失效。
- 如DNS查询被破坏，使业务流无法建立；只通过SDN控制器就可改变流转发路径，将大量的数据流发往被攻击节点；
- 中间人攻击，非安全的控制通道容易受到中间人攻击。
- 流的完整性被破坏，如插入恶意代码。
因此，控制平面的安全是SDN安全首先要解决的问题。下面从针对控制器的主要威胁入手，分析它们的威胁方式、影响及相应的解决对策。
攻击者利用控制器安全漏洞或南向协议（如OpenFlow）实施拒绝服务攻击
当数据包到达SDN交换机时，交换机对包的处理流程如下图所示。当包不匹配所有流表中的所有流表项时，交换机将包通过与控制器间的安全信道转发给控制器处理；当匹配了任一条流表项时，则检测流表项中的actions字段，根据该字段中指定的操作动作，对此包进行相应处理。这个处理流程，使得通过数据平面对控制平面的控制器进行攻击成为可能。
至少有如下两种攻击方式。
- 攻击方式一：攻击者通过攻击交换机，让其将所有包转发给控制器处理，从而使控制器受到拒绝服务攻击，如下图：
SDN交换机的OpenFlow协议的流表中，每个表项包括3个域：头域、计数器和操作。当操作域值为CONTROLLER时，交换机需将数据包封装后通过类型为OFPT_PACKET_IN的消息转发给控制器。
根据这一工作机制，攻击者可通过修改交换机流表中各表项的actions字段，使交换机将所有数据包都转发给控制器，从而导致控制器需处理大量的PACKET_IN消息。具体的攻击方法可以是攻击交换机，直接修改流表项；也可以是攻击控制器（或伪造控制器身份）向交换机下发配置指令，修改actions字段。
- 攻击方式二：根据OpenFlow协议，当交换机接收到一个数据包时，如果无法在流表中找到相应的转发端口，交换机将通过PACKET_IN消息向控制器转发此包，请求控制器下发相应转发流规则。因此，攻击者可以伪造大量在交换机流表中不存在或无法处理的数据报文，由交换机提交这些报文给控制器进行处理，从而占用控制器资源，造成拒绝服务攻击。从终端发起传统的TCP/SYN、UDP、ICMP洪泛攻击就可以完成这种攻击。
PACKET_IN消息消耗的控制器资源包括控制器查找、计算流路径所需的计算资源以及控制器南向接口的带宽资源。
本质上，这类攻击方式是一种OpenFlow洪泛攻击，因此传统的防御思路仍可采用。
防御的第一步是流（或包）信息的收集。SDN是面向流的网络，因此较易实现基于流的检测和防御。通常采用的方法是通过控制器周期性地读取交换机的流表信息。根据OpenFlow协议，控制器可通过OFPST_FLOW或OFPST_AGGREGATE消息向交换机询问一条、多条或全部流表项的流信息。从流表中直接可读取的流信息包括流的头域和计数器，头域包括流的源和目的地址、协议等，计数器可提供整个流表、一条流、一个端口和一个队列的较简单的统计信息。
流统计信息的收集常由控制器定期向交换机查询，异常检测也常由控制器上的应用完成。传统的异常检测方法也被应用于SDN控制器的抗DDoS攻击检测。
主要的防护机制包括两种思路：流量控制提供主动遏制手段。多控制器结构中，可采用L7应用层负载均衡提高控制器在DDoS攻击下的生存性。
非法接入控制器
攻击者可以通过传统的网络监听、蠕虫、注入恶意程序等方式窃取SDN网络管理员的账号和密码，伪造合法身份登录控制器并进行非法操作；也可以利用SDN控制器自身的软硬件漏洞，通过恶意应用进行渗透攻击提升操作权限，获取对控制器的非授权操作。
以下措施有助于应对上述安全威胁。
1）建立安全通道，执行严格的身份认证。强制通过加密信道访问控制器有助于防止窃听控制器管理员的账号和口令。
2）应用软件的安全测试、应用隔离和权限管理。
1.3 开放API：不安全的应用接口
不安全的南/北向接口，可能使得整个网络的安全受到威胁：
- 网络行为被修改。如果恶意攻击者通过注入等手段，使某应用发送的请求的参数与业务逻辑期望不符，可使该应用的网络行为被篡改，从而下发恶意指令。
- 网络通信被非法监听。如果接口是未加密的，攻击者就能监听整个调用过程，从而使敏感信息被窃取。
- 截获并修改数据包。攻击者可以采用中间人攻击，重放或修改后重发请求，达到伪造请求的目的。
- 引发DDoS攻击。如果应用接口没有检查机制，容易被攻击者反复调用，向网络设备下发大量无用的流表，可能影响数据平面效率；或者攻击者将大量流量引到某些性能较弱的节点，造成该节点被拒绝服务。
可能的解决方法如下。
- 设置API权限。控制层可对不同应用的API调用设置不同的权限，以防一般权限的应用程序调用高级别的接口命令。
- 策略检查。控制器可对通过API接口下发的应用层策略进行规则检查，检测下发的规则是否有冲突，是否符合安全策略、业务逻辑和行为特征，检测规则下发后是否可能导致网络发生异常。
- 信任评级。对应用进行信任评级，根据应用层参数及应用的历史行为计算应用的信任度，每个应用对每个控制器的信任级别可以不同，各个控制器可以为不同级别的应用设置一个信任阈值，当应用的平均信任值大于该值时就执行相应权限的命令，否则不执行。
- 中间层检查。在控制层和基础设施层间定义一个中间层，用来检查来自控制层的信息，并下发给网络设备。
1.4 数据平面：传统数据流的安全问题
数据平面的主要攻击对象是数据平面的关键节点-SDN交换机，可通过消耗流表资源对SDN交换机实施拒绝服务攻击。具体方式包括直接入侵交换机，用虚假信息填满流表，或通过向控制器发送大量数据包，致使控制器为每个数据包建立一条转发流规则，从而导致流表溢出。
应对这种拒绝服务攻击的方法如下
- 采用流控、事件过滤、拥塞丢包和超时调整等方法限制流量。
- 流聚合。在控制器上将多条具有相同动作的流聚合成一条流，从而通过降低流操作的粒度降低控制器的负载，减小流表溢出的概率。
- 在交换机和控制器上实施攻击监测。
- 在控制器上实施严格的访问控制策略。
与传统网络相比，SDN交换机有更多的控制层交互，控制接口的功能更强大。因此，除直接渗透有脆弱性的交换机外，攻击者通过部署非法应用、入侵控制器都可实现对交换机流表的非法操作，完成以下对用户数据流的攻击。
𝟙）改变流转发路径，实施中间人攻击，进行信息窃取和篡改。
𝟚）修改对数据包的操作动作，改变交换机在转发流时对数据包的操作动作。例如，丢弃数据包实施拒绝服务攻击，非法复制数据包并通过另外的路径转发给攻击者窃取信息或实施中间人攻击。
𝟛）设定非法信息的转发路径，从而占用某用户的转发端口等网络资源实施拒绝服务攻击，或通过注入精心设计的数据包进行会话劫持攻击。
SDN可对网络基础设施层的软件定义能力实现MTD（Moving Target Defense），从而变换数据平面的攻击面，增加攻击成本和难度，利用SDN可实现从物理层到应用层的全协议栈的MTD；通过SDN提供数据的多路径传送，可提供L4负载均衡在网络不同路径间分割数据包，从而提高网络在DDoS攻击下的生存能力，并提高窃听难度，也可利用多路径提供不同等级的安全信道。
SDN还可为数据平面提供类似于传统面向连接网络的信令功能。以下展示了可信通道应用提供的安全策略是如何控制敏感数据在SDN网络中安全传送的。
𝓐 要发送敏感数据的一方M1首先发送一个信令包到网络中，这个包中包含了敏感数据在网络中传输时的安全策略，如哪条链路或交换机是恶意的，尽量避开。
𝓑 这条消息会通过PACKET_IN消息被控制器获取，并且这个包中有关于M1和控制器之间的认证信息，使得双方互相建立信任关系。
𝓒 控制器把策略发送给TPA（Trusted Path Application）。
𝓓 TPA会根据这个安全策略来指定合适的可信通道，并且TPA会下发OpenFlow命令给底层交换机，如生成流表项来建立敏感数据的可信通道。
𝓔 M1会收到来自控制器发来的确认信息，告诉M1敏感数据的可信通道已经建好。
𝓕 至此，M1就可以传送敏感数据给M2了。
利用类似思想，还可以设计更多的“信令包”，在数据通信前提交给控制层，以完成其他功能。例如，在“信令包”中提交用户信息，从而为流提供认证功能，网络只为经过授权的用户建立流。
2.协议安全
2.1 南向协议介绍
南向协议主要侧重于南向接口上的数据转发、网络配置、数据平面信息收集等功能。
OpenFlow协议
OpenFlow是SDN的标志性技术，他体现了SDN的核心思想：控制与转发分离。它通过流表控制技术支持用户对数据流行为进行控制。OpenFlow交换机根据流表来转发数据包，代表数据转发平面；控制器通过全网络视图来实现管控功能，其控制逻辑表示控制平面。
OpenFlow协议的发展演进一直都围绕着两个方面，一方面是控制平面的增强，让系统功能更丰富、更灵活；另一方面是转发层面的增强，可以匹配更多的关键字，执行更多的动作
OpenFlow协议支持3类消息类型：由控制器发起的Controller-to-Switch消息、用于交换机向控制器通知状态变化等事件的Asynchronous消息和主要用于维护连接的Symmetric消息。控制器和交换机之间通过这3类消息进行连接建立、流表下发和信息交换，实现对网络中所有OpenFlow交换机的控制。
OpenFlow的流表由很多流表项组成，每个流表项就是一个转发规则。每一个流表项有3部分内容：
头域是一个十元组，除了传统的七元组之外，增加了交换端口、以太网类型、VLAN ID，并且还可以进行扩展；
计数器主要用来记录流、端口相关的统计数据；
操作则是转发、丢弃等对流的操作。
ForCES - Forwarding and Control Element Separation
ForCES即转发与控制单元分离，是IETF路由领域的ForCES工作组的内容，致力于开放可编程的IP路由器体系结构和协议，其基本思想是把IP路由器分成转发组件FE（Forwarding Element）和控制组件CE（Control Element）。
ForCES将路由器的控制单元从路由器体系结构中分离出去，成为控制平面，路由器原来的体系结构只保留转发单元的功能，从而将转发和控制功能在物理上分离开来。ForCES协议则用于路由器控制单元和转发单元之间的通信与交互，CE通过ForCES协议来完成对FE的控制和管理操作。
如下图所示，一个ForCES的网络单元NE可以包含多个CE和多个FE的实例，一个CE可以控制多个FE，同时一个FE也可以由多个CE控制。FE包含一个或多个物理介质接口Fi/f，该接口用来接收从该网络单元外部发来的报文或将报文传输到其他的网络单元，这些FE接口的集合就是NE的外部接口。除了这些外部接口，网络单元内部还有一些内部互联，用于CE和FE之间通信及FE之间转发报文的接口。在网络单元外部还有两个辅助实体：CE管理者和FE管理者，它们用来在前关联阶段对相应的CE和FE进行配置。为了方便起见，在ForCES体系结构的组成成分之间使用参考点来标记其逻辑交互，参考点分别为Fc、Ff、Fr、Fi、Fl、Fi/f和Fp。完成CE与FE之间交互的ForCES协议是在Fp参考点上定义的。
PCEP - Path Computation Element Protocol
PCEP是由IETF的PCE工作组于2006年为MPLS网络域间流量工程（即显式路由）等应用提出的，以支持集中化的路径计算。PCE工作组的体系结构基于两个核心功能模块：PCC（Path Computation Client）部署在路由器等数据平面节点上，在控制平面上则部署PCE服务器，实现路径计算单元PCE（Path Computation Element），负责计算来自PCC的路径计算请求。PCEP则是为PCE和PCC之间通信而提出的相关通信协议。
为了支持集中的路径计算，控制平面上还需要有TED（TrafficEngineering Database）功能模块，主要负责收集网络拓扑和当前的带宽、资源利用率等链路信息，但PCEP中并不包括这些信息的交互，而是由TED通过路由协议或由网管的其他机制获取。PCE从TED获取链路和网络参数计算出一条满足约束条件的最佳路径。
PCEP协议描述的一次会话主要分为以下4个阶段。
① 会话的初始阶段，在PCE和PCC间建立TCP连接。在此初始阶段包括的消息类型为用于PCE和PCC或者PCE和PCE之间的消息开启的Open消息，以及用于保持维护该次会话的Keepalive消息。
② 路径计算的请求阶段，发送PCE和PCC之间或PCE和PCE之间进行路由计算的请求消息，即发送包括请求路由的详细信息、路由的约束条件以及其他特殊的约束条件等信息的请求PCReq。
③ 路径计算的响应阶段，PCE根据TED链路信息，结合约束条件进行路径计算，并发送包括详细路由、节点信息、带宽等信息的响应消息。
④ 会话的关闭阶段，用于处理Close结束消息、异常和错误等信息。
可将PCEP粗粒度的域间路径计算和OpenFlow细粒度的流表操作相结合，在SDN控制器上部署PCE服务器来完成域间的路径计算，并在SDN控制器与路由器之间运行PCEP协议。但PCEP协议本身并不涉及数据平面的信息收集，因此仍需SDN控制器通过BGP-LS等协议来获得路由器利用路由协议收集的拓扑信息。
OF-Config - OpenFlow Configuration and Management Protocol
OF-Config是网络配置管理节点与交换机的接口，以完成对OpenFlow交换机的远程配置和管理，如配置控制器IP地址，如何对交换机的各个端口进行enable/disable操作。
OF-Config在OpenFlow架构上增加了一个被称作OpenFlow配置点的节点，它可以是控制器上的一个软件进程，也可以是传统的网管设备。OpenFlow配置点通过OF-Config协议对SDN中的网络资源进行管理，包括OpenFlow交换机上所有参与数据转发的软硬件（如端口、队列等），因此OF-Config协议也是一种南向接口。它与OpenFlow之间存在着密切的关系，随着OpenFlow标准的演进，OF-Config的版本也与其保持同步。
NETCONF
NETCON是基于XML的新一代网络管理配置协议，以替代CLI、SNMP。
NETCONF协议通过一组可选特性来适应任何设备架构，同时开发人员还可以创建其他的“特性”。因此，NETCONF设备可以包含任何专有功能。为了保证对不同网络配置需求的适应性，NETCONF协议自上而下分为内容层、操作层、RPC层和传输层
I2RS - Interface to the Routing System
I2RS的核心思想是在传统网络设备的路由及转发系统上定义开放接口，使外部应用或控制实体可读取路由器中的信息，从而可基于拓扑变化、流量统计等信息动态下发路由状态、策略到转发设备上，以支持网络的可编程能力。I2RS沿用了传统网络设备中的路由、转发等结构与功能，并在此基础上进行功能的扩展与丰富。
通过I2RS控制器或网络管理应用，用户应用可以完成对路由系统的实时或事件驱动的交互，这使得信息、策略和操作参数能被注入路由系统中，也可以从路由系统中读取这些信息，从而在现有的网络配置管理功能之外提供更强大的实时可编程的网络配置能力。
协议对比
| 协议 | 组织 | 提出时间 | 设计目标 | 技术特点 |
|---|---|---|---|---|
| OpenFlow | ONF | 2007年 | 数据转发，SDN交换机流表操作 | SDN控制器与交换机见的细粒度流表操作，侧重于转发功能，追求商用设备的高性能和低价格 |
| ForCES | IETF | 2014年 | 控制欲转发分离的IP路由体系结构 | 定义了框架和相关协议，用于规范控制平面和转发平面之间的信息交换 |
| PCEP | IETF | 2006年 | MPLS网络中集中的零计算，域间流量工程 | PCEP协议定义了PCC和PCE交互过程中消息报文格式与其相关作用，其中包括会话初始化、请求恢复、安全管理、状态通知、出错反馈等 |
| NETCONF | IETF | 2006年 | 基于XML的网络配置 | 设计了一种网络协议框架，以适应不同网络的配置管理需求，包括采用OpenFlow协议的网络 |
| I2RS | IETF | 2015年 | 为访问路由系统信息设计的接口，以实现可编程的路由重定向，支持流量工程、DDoS流量清晰、静态组播树、动态VPN部署等应用 | 为支持网络可编程能力而设计的路由系统标准接口，以访问路由器内的路由信息表RIB、拓扑、接口、策略等信息。与原有的网络管理和配置功能相比，它强调快速、异步和双向的接口通信 |
| OF-Config | IETF | 2013年 | OpenFlow节点的管理配置 | 无实时性要求，不影响流表操作，功能简单，如配置控制IP地址、设备的队列、端口等资源，支持远程修改设备的端口状态 |
2.2 OpenFlow协议安全
信息泄露
信息泄露攻击的目的是嗅探出控制器和交换机的信息，特别是流表信息。例如，侦测一条流表规则是否存在于交换机或控制器中，甚至流表项对应的操作动作和转发策略，这些信息可能会被攻击者用来判断网络服务的状态，也可能被用于后续的网络攻击。
要获取流表信息，通过攻击获得权限提升，从而读取流表规则是一种方法。当无法获取直接的访问权限时，还可以通过边信道攻击设法得到流表信息。
交换机收到一个包后有以下3种可能的处理方式。
1）当数据包完全由交换机的数据平面（通过硬件）转发时，转发速度最快。
2）数据包也可能被交由交换机的控制功能处理，如交换机的数据平面不支持的转发操作时。这样会花费更多的时间。
3）交换机可能把数据包（或包头）发到控制器，这时的速度是最慢的。
通过大量的发包观察，对不同数据包的转发时间分布进行分析，从而得到合适的门限值，就可以根据数据包的转发延时来判断数据包是以何种方式发送的，哪些包直接由交换机处理，哪些数据包被发往控制层，继而便可以判断流表规则是否存在，以及一条新的流表规则在何时创建。
当交换机支持流聚合时，通过这种信息泄露攻击，有较大的概率可以探测到交换机中是否存在某台主机相关的流规则，从而得到网络中活动主机的地址信息，即使这些主机都禁止了ping操作。采用类似的方法，通过更精确的时间测量，还可得到部分流表操作动作，例如，是否有一些数据流由流表设定为强制转发给控制器处理；转发端口是虚拟端口还是硬件端口。
同样，分析不同数据包的响应延时，若发现后序数据包的转发延时明显小于前面的数据包，就可以确定以某一速率发送数据包时，流表规则何时能建立，这个信息有助于提高对控制器的拒绝服务攻击的效率。根据以上分析，这类攻击方法主要是通过边信道攻击来实现的。因此，可以采用应对边信道攻击的方法来对抗SDN网络中的上述信息泄露攻击。
- 采用主动安全策略。例如，设计流规则建立机制，消除延时与网络拓扑间的关联关系。
- 随机化。例如，在数据平面加入随机延时，从而增加响应时间变化的随机性，增加测量的难度。这种方法之前也被用于应对针对RSA和AES的边信道攻击，但对于SDN网络，数据平面加入额外的延时势必会影响一些实时业务的服务质量。
- 攻击检测。在控制层设计攻击检测应用，检测相关攻击流量，这些流量有较明显的特征，在控制层并不难检测。
非法接入与协议传输安全
OpenFlow交换机和控制器通过监听TCP端口6634/6633建立TCP连接后，双方只需通过Hello消息的交互就可建立通道。其中，Hello消息只带有OF头，即其主要作用基本是保证双方协议版本的一致性，并无任何身份和验证信息，因此很容易实现节点的非法接入。
另外，OpenFlow协议包交互时，也没有设计任何机密性和完整性保障机制，控制指令容易被窃听和篡改。
OpenFlow协议的认证和通信安全可以通过建立SSL/TLS安全通道来提高，由认证中心为交换机和控制器发放证书，同时为指令的传输提供一个安全通道。OpenFlow协议并不强制要求实现SSL/TLS。
连接建立的安全
OpenFlow协议要求在建立连接的过程中，双方必须先发送OF_HELLO消息给对方，如果连接失败，那么会发送OF_ERROR消息。攻击者可以通过中途拦截OF_HELLO消息，或者伪造OF_ERROR消息，从而阻止连接的正常建立。
如果OpenFlow连接在中途中断，则交换机会尝试与其他备用控制器建立连接。如果也无法建立连接，则交换机会进入紧急模式，将正常流表项从流表中删除，所有数据包将按照紧急模式流表项转发，正常的数据转发完全失效。
actions动作处理的安全
OpenFlow协议要求下列行为列表中的11种类型的行为不能出现重复。
- copy TTL inwards：应用对数据包向内复制TTL的动作。
- pop：应用对数据包的标签（tag）弹出（pop）动作。
- push-MPLS：应用对数据包压入（push）MPLS标签的动作。
- push-PBB：应用对数据包压入PBB标签的动作。
- push-VLAN：应用对数据包压入VLAN标签的动作。
- copy TTL outwards：应用对数据包向外复制TTL的动作。
- decrement TTL：应用对数据包的TTL减一的操作。
- set：应用对数据包所有set字段的动作。
- qos：应用所有QoS的动作。例如，对数据包设置队列。
- group：如果指定了组行动，则按照这个序列中的顺序执行组行动存储段中的行动。
- output：如果没有指定组行动，则报文就会按照output行动中指定的端口转发。
但是，许多底层交换机在执行时不检查控制器下发的Apply-Actions行为列表，那么攻击者可以利用这一漏洞随意额外标记数据包，在Apply-Actions行为列表中增加某些重复行为，从而达到恶意目的，并且该行为对上层来说是完全透明的。例如，额外增加output行为，旁路出另外一条流达到窃听的目的，或者恶意增加decrement TTL行为，使数据包在网络中因TTL耗尽而被丢弃。
3.资源安全
3.1 NFV和Hypervisor兼容性
将物理安全设备移植到虚拟化系统，变成一个NFV中间设备，是一个很大的挑战。其原因有两点：第一，很多设备，如防火墙和入侵防护系统IPS，需要使用定制化的网卡驱动和内核，以达到更好的性能，然而在计算节点的通用Hypervisor上部署，则需要解决兼容性问题，如DPDK驱动集成等；第二，一些虚拟化系统提供了自有的用于流量牵引的Hypervisor应用接口，这虽然是未部署SDN控制器时的一种解决办法，但是往往会耗费安全人员大量的精力去适配这些非标准的接口，甚至有主流虚拟化系统并未对外开放此接口，造成虚拟化环境中无法部署工作在L2网络的安全机制。
3.2 系统可用性
在虚拟化条件下，网络本身并不可靠，所以心跳机制不能保证整个安全机制的可用性。
另外，虚拟安全设备本身存在性能瓶颈，所以当Web网站出现大量的并发连接时，中间的虚拟安全设备可能出现拒绝服务的情况。
4.应用安全
4.4 网络虚拟化对网络安全的挑战
私有云系统利用现有的网络技术和虚拟化技术，可以保证用户空间隔离和基础的访问控制。然而网络安全还包含其他很多方面，如深度包检测、恶意行为检测和防护、安全审计和数据防泄露等。这些安全功能目前还依赖于独立的物理或虚拟网络中间设备实现。
作为网络安全设备，正常工作的前提是对流经的数据可见可控，然而在虚拟化环境中，这些设备的部署和工作模式都受到了挑战。
首先是流量的可见性。IPS与计算节点一样，直接连在物理交换机上。假设两个虚拟机VM1和VM3分别在不同的节点Host1和Host2中，且节点间通过隧道相连，此时VM1→VM3的数据包首先到节点Host1的虚拟交换机上，然后经过隧道封装到物理网络中。此时IPS设备可以看到数据包，但是封装后的数据包，所以设备无法理解该数据流真正的含义。再退一步，假设节点间没有用隧道，而只是用普通网络相连，并通过VLAN区分不同的虚拟网络，IPS看到的是带着VLAN的数据包，虽然理解数据包本身没问题，但处理引擎将面临不同租户有同样虚拟网络造成的地址重叠问题，同样会出问题。
其次是流量的可控性。假设两个虚拟机VM1、VM2在同一个节点Host1中，那么VM1→VM2的数据包如上图的虚线所示，直接通过虚拟交换机传输到目的虚拟机，根本没有经过物理IPS设备。此时该设备就无法对数据流进行阻断或做其他控制操作。
因此防护虚拟化设施就需要调整对策：改造安全设备本身，使其兼容多租户环境；改变数据流向，使安全设备对流量可见可控。
兼容虚拟化多租户安全设备的部署
有四种方案：
1）修改处理引擎。现有设备不做大改动，仅在数据包处理时增加解隧道和封装隧道的功能，并在处理引擎中增加租户等标识。
2）安全设备虚拟机服务链。交付硬件设备，但实现的是完整的虚拟机管理和流量牵引功能，可根据安全策略启动相应的安全设备实例，并引导流量形成内部服务链。
3）硬件虚拟化。交付硬件设备，内部可在虚拟网络设备上启动多个虚拟安全设备。
4）安全设备虚拟机。交付安全虚拟机镜像，安装在计算节点中。这些虚拟安全设备所在的计算节点和物理安全设备都可通过隧道技术相连，并能解析和处理流经的虚拟网络流量。
再谈改变数据流向的3种方法
1）通过实现虚拟化系统API来改变数据流向。
下图所示展示了东西向和南北向流量的牵引。如果要监控同属一个虚拟网络的两个虚拟机的东西向流量，如左边节点中的虚拟机VM1和VM2，则可利用虚拟化系统提供的Hypervisor API，将东西向流量导入同主机内的安全设备虚拟机；如果要监控虚拟机与外部网络通信的南北向流量，则需要利用虚拟化系统提供的路由API。
受限于虚拟化系统API的开放程度。对于东西向流量而言，vSphere vShield和NSX目前没有公开，而且即便开放了，也仅支持安全设备虚拟机部署模式。
2）通过SDN牵引来改变数据流向。
当虚拟化系统与SDN结合之后，可使用SDN控制器指引底层实体或虚拟交换机的网络流量，即可将原本需要使用虚拟化系统API实现的功能，利用南向协议来完成。 由于它不需要考虑安全设备的位置 ，因此所有的部署模式都支持。
下图展示了SDN牵引的原理。当确定要监控VM1→VM2的流量时，安全中心会从计算节点或安全节点找到一个IPS设备，然后向VM1所在交换机到IPS所在交换机的路径P上的所有交换机下发重定向的流指令。如果选择计算节点的IPS，则路径为P1；如果选择安全节点上的IPS，则路径为P2。这样所有源为VM1且目的为VM2的数据包沿着路径P到达IPS设备，经过检查后数据包从IPS输出端口输出，此时SDN控制器根据拓扑计算从IPS到VM2的路径，并下发流指令，沿途交换机将数据包传输到VM2。
3）通过人工配置来改变数据流向。
凡是可以通过SDN实现服务链流量牵引的方法，都可以通过人工配置底层网络设备来实现。
4.5 SDN带来的安全隐患
网络虚拟化关注的是网络资源管理，而SDN关注的是网络流量调度，如果仅将两者简单叠加，则必然会出现一些问题。例如，SDN对底层流量的操控可能会破坏虚拟化的流量隔离；而虚拟化对交换机的配置又可能破坏SDN网络的控制平面，最终破坏系统的安全性和可用性。
租户隔离
以OpenStack Neutron为例，使用Open vSwitch Plugin，SDN控制器使用Floodlight。
Neutron使用全局隧道与局部VLAN技术结合的方式，实现了租户间流量的隔离，这种映射关系体现Neutron OpenvSwitch Agent在节点的br-int上设置VLAN，并在br-tun中设置Tunnel ID与VLAN之间的转换。因为原生Neutron中存在租户隔离，所以租户之间的流量是不能通信的。
但是引入Floodlight后，它会接管底层网络设备的通信。它首先将虚拟交换机中的原有流表全部删除，然后在收到PACKET_IN后，仅根据源目的地址计算路由后下发流表。虽然br-int上的端口有VLAN tag，但br-int的actions=NORMAL流被删除后，就没有工作在传统模式，所以隔离并没有起作用。
访问控制
虚拟化系统可以使用IPTABLES等在Linux网桥和命名空间中实现访问控制，而SDN控制器可以在虚拟交换机上实现L2~L4的访问控制。引入SDN后，计算节点和网络节点的交换机br-int可做访问控制：
此时，要实现VM5对外的访问控制，到底是在SDN控制器上应用配置ACL，还是在虚拟化环境中设置安全组或FWaaS，对于安全管理员来说是一个挑战。这是因为冲突、过时或不恰当的配置会给安全管理带来巨大的麻烦。
例如，在安全组中允许VM5到VM2的ICMP访问，但SDN控制器中的防火墙模块禁止VM5对外的ICMP请求，那么在虚拟化系统中排查VM5不能ping通VM2显然是没有结果的。
网络虚拟化模块通常在逻辑资产间关系的层面考虑访问控制关系，而SDN控制器根据上层应用策略，在数据流层面考虑访问控制关系，所以两者的知识、决策逻辑都不一致。如果不能很好地整合起来，则会给整个系统带来巨大的风险。
所以在设计SDN控制器与虚拟化系统集成时，需要将数据流的两端主机与虚拟化系统中的资产信息关联起来，SDN控制器在决定两点间是否可达时，需要考虑源目的虚拟机所在网络是否是隔离的，以及这两点是否遵从所有SDN应用的访问控制策略，同时也遵从虚拟化系统的访问控制策略。当虚拟机启动时，除了将虚拟化系统的访问控制策略生效外，还需要通知SDN控制器，更新其知识库和相应的访问控制策略。
5.系统实现安全
SDN架构包括应用、控制器、交换机，以及管理系统；虚拟化系统包括控制节点、管理节点、存储节点和计算节点，这些组件背后运行的都是软件，而软件就可能含有脆弱性，从而被攻击者利用并获得非授权的访问权限，从而阻断或恶意操纵流量。例如，目前大部分白牌交换机都运行基于Linux的开放操作系统，那么这些交换机就需要面对Linux操作系统的所有风险。
在一些云计算系统中，数据网络可能与管理或控制网络共享。也就是说，租户可以访问SDN或虚拟化系统的控制节点，在获得控制平面的权限后，即可操纵底层的路由器绕过部署在某处的安全设备。
开发一个软件系统的过程中，在架构、协议和应用等方面可以做大量的安全性设计，但是在系统实现的过程中，离不开人的因素，所以当系统越大、涉及的组件越多、第三方应用越不可控时，就应假定该系统是不安全的。这就需要人们使用脆弱性评估、渗透测试和安全检测等方式，不断发现系统的问题并及时修复。
