云环境下基于SDN的高效流量监控方案

刘世嘉，王 勇,+，刘玉明

(1.桂林电子科技大学 计算机与信息安全学院，广西 桂林 541004；2.桂林电子科技大学 广西云计算与复杂系统高校重点实验室，广西 桂林 541004；3.桂林电子科技大学 广西云计算与大数据协同创新中心，广西 桂林 541004)

0 引 言

近年来云计算技术受到各大厂商追捧，其高速发展的背后，安全问题日显严重[1]。传统数据中心多为南北向流量，而随着云计算技术的到来，云存储、并行计算等需要大规模集群协同的业务产生了大量的东西向流量，推动了南北向流量往云平台内部虚拟机间产生的东西向流量转变[2]。传统安全设备和流量采集方法[3]对东西向流量的安全防护无能为力，因此东西向流量的接触盲区，无疑为云安全态势分析提出了新的难题。为了实现云环境中东西向流量的可视可控，近年来相继出现了多种流量捕获方案[4]，而现有的绝大数方案都是以SDN流量牵引[5]为基础，通过SDN将所有虚拟机产生的东西向流量牵引进软件安全检测系统进行检测[6]，从而实现东西向流量的监控。但是，软件防护系统的性能受制于宿主物理机性能，所有东西向流量的汇入检测会带来巨大的负载，可能会造成单点失效的问题，导致流量无法转发，用户业务开展受到影响。基于上述的问题，本文提出一种的高效的流量采集与检测方法来监控流量，通过SDN控制器对流量进行自适应采样，避免因密集的固定周期采样给控制器带来额外负载，之后提取出特征信息，经常用分类算法的类别划分处理后，再下发不同级别的流表策略，先快速过滤掉可被识别的正常流量，牵引需要检测的东西向流量进入软件安全检测系统，以此减小需要捕获的流量的规模。在既不影响控制器性能，也不影响检测率的同时，避免占用过多流表项，有效降低了带宽的占用，减小了软件安全检测系统的负载。

1 相关工作

为了能够获取东西向流量，Giotis K等[7]提出一种将sFlow与Openflow交换机结合的方法来提升异常检测的效率和扩展性，该方法分为3个阶段：流量捕获、异常检测、攻击缓解，其中流量捕获部分采用了SDN流表统计信息采集与sFlow插件主动采集结合的方法，保证了处理效率。但是，在云环境多租户应用场景下，sFlow无法识别不同租户产生的相同地址且不易大规模部署。Peng H等[8]利用SDN进行流量采集，方法是固定10 s轮询周期对交换机收取流表统计信息，提取出特征以构建多维流特征向量交由DPTCM-KNN算法进行异常流量的分类检测。该方案使用的固定轮询周期，在周期设定的长短上会对测量精度与设备负载产生影响，需要平衡三者的关系，否则会加重交换机的负载。Zanna P等[9]提出一种在控制器集成IDS模块的方法，利用控制器下发流表的方式动态阻止入侵。该方案通过Packet In消息上送所有待检测流量至SDN控制器，当流量规模增大时，会加重控制器负载，容易造成单点失效。Ha T等[10]提出一种利用SDN将流量镜像到多台IDS中进行检测的方法，将同类型攻击统计成组后镜像到同一台IDS，借此提升检测率并负载均衡被检测流量。该方案的流量采集仍然是先汇集到一台交换机后再进行分发检测，且方案在传统三层网络架构下实施，云环境的多计算节点网络架构难以依此进行部署。池亚平等[11]提出一种IDS与控制器联动的入侵防御方案，通过将所有流量重定向到Snort进行检测，在检测到入侵后通过控制器下发策略阻止入侵。该方案Snort部署于计算节点上，所有流量的汇入会增加负载，影响计算节点性能，同时也会对其上的虚拟机性能造成影响，并且会产生大量过期的重定向流表项。邵国林等[12]利用OpenFlow技术将所有虚拟机流量重定向至外部IDS检测，检测完成后需要将合规流量重新注入。该方案因需要将流量在IDS进行二次转发，当流量规模增大时，IDS的转发性能成为瓶颈，会造成单点失效，影响正常业务流量的转发。

上述方法虽然都将SDN技术运用到流量的捕获中，但多数是欠考虑地牵引所有流量到软件防护/检测系统，因其工作重点在入侵检测上，并没有考虑到云环境中产生的大规模流量对其负载产生的影响。为此，本文设计的方案提出通过自适应流量采样并分级别预处理的方法，有效缓解软件检测系统的负载，降低安全控制信道的占用和对控制器性能的影响。

2 基于SDN的高效流量监控方案及相关设计

2.1 总体方案设计

本文提出的基于SDN的高效流量监控方案由3个主要模块组成：一是自适应流量采样模块，提供可根据各条流的带宽占用情况，动态调整采样频率的功能；二是包处理模块，提供对采样来的流量提取特征信息并转存至通用存储识别模块待检测分类的功能；三是策略响应模块，提供分级别响应不同流表策略对流量进行具体牵引控制的功能。方案的总体架构如图1所示。

图1 本文设计的方案总体架构

2.2 自适应流量采样模块

为了实现对流量的后续识别处理，首先需要通过OpenFlow交换机将流量上送至控制器，也即对流量进行采样。通过触发Packet-In消息，OpenFlow交换机可以将指定流量封装后上送至RYU控制器处理，而触发Packet-In消息的方法分为两种：匹配到流表项中的行动主动上送；不存在与流表项一致的条目被动上送。需要注意的是，上送控制器的过程需要占用交换机与控制器间的安全信道带宽。目前，控制器多以固定频率的方式进行轮询以采集交换机的流量统计信息，高频率的轮询能够提升流量统计信息的精度，但也会挤占过多交换机与控制器间的安全信道带宽，同时也会给控制器造成过大负载。因此，需要一个合适的方案来平衡采样精度与性能负载间的关系。

本文设计的方案的自适应流量采集模块，通过动态操作FlowMod构造流表的hard_timeout参数，使流表在到达指定的时间后实现超时自动删除，从而让该条流的后续流量在没有下发新的流表前触发流表项中的被动Packet-In消息，将流量封装后上送至控制器，实现流量的采样操作。为了平衡采样精度与性能负载之间的关系，还需要通过FlowMod为流表设置FlowRemoved标记，该标记在每条流表超时删除后能够上报其持续时间内的流量统计信息，根据回收各条流表超时后的统计信息计算出其持续时间内的带宽占用情况，以此动态规划下一次的hard_timeout超时时间。当带宽占用小时，通过降低超时时间提高采样的频率保证精度，反之则增加超时时间减小采样频率降低性能负载。

流表hard_timeout的超时时间(T)的计算过程如式1所示

T=(byte_count/duration_sec)*τ+

(1)

其中，byte_count为流表存活期间匹配的流量大小、duration_sec为流表存活时间，两者通过回收的流表统计信息中获取；τ为在30 s的时间区间内划分出的时间窗口间隔；为 [1,2,…,τ] 上等概率取值的随机变量，引入该变量可以避免因超时时间相同而在某一相同时刻出现峰值流量增加控制器负载，而造成控制器单点失效的情况。在计算流表超时时间时，取10 Mbps～100 Mbps的带宽范围，τ取 3 s 为间隔进行实验，在本文的实验中表现较好。由上述设计实现的伪代码见表1。

2.3 包处理模块

包处理模块的作用是对前一步采集的流量进行解析并

表1 自适应流量采样算法

提取特征信息转存后待分析，经过Packet_In消息封装后的数据包到达RYU控制器，由Packet_In消息处理模块进行解包，通过引入队列操作将获得的数据包依次送入包处理模块，以此缓解当控制器遇到峰值负载而造成丢包的问题。

包处理模块通过get_protocols方法对数据包进行层层解析，从数据包中可获得的字段见表2，将这些信息连同时间戳按不同数据包组织成一一对应的键值对存入特征字典，之后转存至通用存储识别模块的Redis内存数据库待后续分类，此处根据存储需求，选用了Redis常用数据存储类型中的队列类型，通过使用PUSH、POP等操作可以快速的将任务按FIFO顺序依次进行出入队列操作。

表2 数据包提取的字段

将所有由包处理模块组织好的特征字典依次存入Redis队列后，可方便地提供兼容接口被常用检测分类方法如Snort、AC自动机、DFA算法等提取检测过滤部分威胁低的正常流量，本文中利用建立的白名单规则进行快速分类，经分类后再分别存放入不同的Redis队列以供后续的策略响应模块调用下发流表策略。

2.4 策略响应模块

方案中策略响应模块完成对检测后流量的具体控制，利用RYU灵活的FlowMod流表构造能力，从Redis队列中取回分类好的结果进行解析并构造出不同的流表规则后下发给交换机。策略响应模块还预留了扩展接口，可以根据需求触发更多级别的控制事件，提供更加细粒度的流量控制能力。本文设计的方案根据流量不同的类型，将风险级别划分为3个等级，实现不同粒度的控制，针对风险级别，给出以下划分依据。

(1)正常级别的流量，确定正常的流量不需要转送至软件安全检测系统进行进一步的检测，直接下发去往目的地的正常转发流表，优先级最低；

(2)端口级检测级别的流量，在被检测出某个端口存在风险后，构造流表的action方法将目标端口规则的流量牵引至同节点最邻近的软件安全检测系统进行进一步的检测，优先级高于正常级别；

(3)完全检测级别的流量，通过构造流表的action方法直接牵引至同节点最邻近的软件安全检测系统，优先级最高。

通过上述分级，实现了不同类型流量响应不同级别的流表规则，过滤掉可先被识别的正常流量，减少牵引至软件安全检测系统的流量规模，降低其检测负载，避免因负载过高造成单点失效。

方案采用RYU控制器，并在现有的模块上进行二次开发，实现系统各模块间的整体调度；另外通过Redis内存数据库实现定制的消息中间件及处理方法，促成控制器与通用存储识别模块之间数据存取与检测识别任务的快速解耦和高效处理；在控制流表的设计上，充分利用RYU API的特性，在一条流表实现多种功能的同时，避免因重复调用业务逻辑而造成SDN控制器额外的处理负载；此外，策略响应模块还预留了通用接口，提高了控制功能的可扩展性，能够接入更多对流量的控制逻辑。

3 实验设计与结果分析

3.1 实验环境

为了验证本文设计的方案的性能和检测率差异，通过Mininet、Openvswitch和RYU控制器构建的实验平台的网络拓扑如图2所示，采用的软硬件测试平台见表3。

图2 实验平台网络拓扑图

名称版本CPUIntel Core i7-4790内存16 G操作系统Ubuntu 16.04Mininet版本2.3.0d1Openvswitch版本2.5.4OpenFlow协议版本1.3

3.2 实验设计与结果分析

首先，为了验证本文所提出的方案对控制器的性能和负载产生的影响更小，提炼以文献[10]和文献[11]为代表的流量牵引方案(简称方案α)，去除其入侵防御的业务逻辑并仅保留核心转发逻辑(将所有流量复制并牵引到软件安全检测系统)。利用上述实验平台，在一台虚拟机上开启Iperf服务端，在另一台虚拟机上用Iperf客户端发送以10 Mbps～100 Mbps逐级递增的带宽测试丢包率，发送的流量均视为正常流量转发处理。方案α与本文方案β的丢包率和时延对比如图3和图4所示。

图3 丢包率对比

图4 时延对比

从上图的实验结果可以看到，方案β的时延与方案α相差不大，浮动在正常的范围内。而丢包率对比中，40 Mbps 带宽前由于本文方案的采样逻辑会给SDN控制器性能造成一些影响，丢包率会略高于方案α。当超过40 Mbps 带宽时，方案α因负载增加丢包率逐渐加大，本文方案的丢包数量上升缓慢，随着总包数的激增，整体丢包率要略优于方案α，以上说明本文设计的方案β不会给控制器增加过多负载，且避免了控制器峰值负载给性能带来的不良影响。

另外，为了论证本文方案能够保持更高的检测率，添加方案α和β的入侵防御业务逻辑，利用上述实验平台部署了一台基于Snort的软件安全检测系统用于检测牵引而来的东西向流量，在一台虚拟机上利用Scapy构造并发送正常的网络数据包以模拟实际的网络通信环境，在另一台虚拟机上构造并发送攻击流量以模拟攻击环境。正常流量以10 000至40 000个逐级递增的数量模拟不同规模下的网络负载，攻击流量固定发送5000个，采取10次实验数据取平均值的方法对比了两种方案对攻击流量的检测率，两者的检测率结果如图5所示。

图5 检测率对比

实验结果表明，随着正常流量数量的逐级递增，Snort的检测负载骤然提升系统出现严重的丢包现象，导致方案α的检测率在正常流量超过20 000个后下降明显，到达40 000个后甚至降至64.2%。而本文方案能够让Snort的检测负载保持在一个正常的水平，正常流量数量达到40 000个时仍然能保持90%以上的检测率，效果的提升上显著优于方案α。

4 结束语

以上的实验结果表明，本文提出的一种云环境下基于SDN的高效流量监控方案，通过自适应流量采样模块、包处理模块、策略响应模块对需要监控的东西向流量进行预处理，识别并放行可确定的流量，有效降低了安全控制信道和安全检测系统的负载，能够使安全检测系统的检测率保持在90%以上，远高于被对比的方案，说明本文设计的方案不会对检测率产生负面影响。同时，对比实验结果表明本文设计的方案在带宽超过40 Mbps后，丢包率和时延表现均优于被对比的方案，避免了控制器峰值负载给性能带来的影响。