云环境下SDN 的流量异常检测性能分析

马 超，程 力，孔玲玲

(1.中国科学院新疆理化技术研究所，新疆 乌鲁木齐 830011;2.中国科学院大学，北京 100049;3.核工业理化工程研究院，天津 300180)

0 引言

大规模的用户与虚拟化部署催生了复杂的云计算网络，尤其是数据中心，需要更加灵活敏捷的网络响应和面向工作负载的网络资源调度，传统的分布式网络架构已经很难应对这些挑战。一个解决方案是在云中引入软件定义网络(Software-Defined Network)。SDN 是开放网络基金会(Open Networking Foundation)提出的新型网络构架，将控制层和数据层分离是SDN 的基本思想，这使得网络设备成为简单的数据发送设备，而控制逻辑则被部署到逻辑集中控制器中进行统一管理。通过对集中控制器进行编程不仅可以方便地修改网络策略和配置，还能及时地对网络状态做出响应，为控制网络提供更大的灵活性［1］。

正因为有了虚拟网络，云才可以将计算/存储等资源抽象、封装成便于调度管理的逻辑单元，因此，虚拟网络的安全对整个云服务有着至关重要的影响。传统的来自外部的网络攻击，如拒绝服务攻击(DoS)和端口扫描等依然是云计算网络的重要威胁［2-3］。但在云计算规模越来越大的形势下，虚拟机很可能会被攻击者利用从内网发起网络攻击，攻击目标可以是云中心内的其他主机，也可以是Internet 上的主机。这种流量通常只经过本地交换机或Hypervisors 而不会通过安全设备［4］。因此，能够快速、准确地检测到内部网络流量的异常并做出合理响应，是保证网络服务正常运行的重要前提。云计算经过多年的发展研究，在网络异常流量检测方面已经有了一定的积累［5］，SDN 在这方面的研究虽然才刚刚起步，但其自身的优势必将会为网络安全的实现提供更有力的支撑。

云计算与SDN 相融合是一个重要发展趋势。到目前为止，已经有一些工作专注于在SDN 上构建流量检测应用［6-9］，但云环境下的SDN 在检测内部网络攻击时的表现仍不得而知。在云环境中构建SDN 并部署流量异常检测，将其性能、效率与标准云环境进行比较，能够使人们对SDN 的特点和优势有进一步的认识。

1 相关工作

1.1 SDN

为了满足高层次网络策略的需求，网络管理员必须使用厂商规定的、低级的命令分别配置每一个独立的网络设备，比如路由和交换机。除此之外，配置的复杂性、网络的动态性、较少的网络事件响应机制都增加了管理员工作的复杂性。

2008 年，软件定义网络(Software-Defined Network，SDN)概念被提出。SDN 的实现基于OpenFlow规范，由基础设施层、控制层和应用层组成［10］。其中基础设施层主要由网络设备即支持OpenFlow 协议的SDN 交换机组成，它们是保留了传统网络设备数据面能力的硬件，负责基于流表的数据处理、转发和状态收集。控制层主要包含OpenFlow 控制器及网络操作系统，负责处理数据平面资源的编排、维护网络拓扑、状态信息等;控制器是一个平台，该平台向下可以直接与使用OpenFlow 协议的交换机(以下简称SDN交换机)进行会话;向上，为应用层软件提供开放接口，用于应用程序检测网络状态、下发控制策略。位于顶层的应用层由众多应用软件构成，这些软件能够根据控制器提供的网络信息执行特定控制算法，并将结果通过控制器转化为流量控制命令，下发到基础设施层的实际设备中。

SDN 的特殊性吸引了越来越多的学者进行研究。Gelberger［10］分析比较了ProGFE、OpenFlow 这2种SDN 构架与传统网络的性能表现，证明了SDN 的灵活性是以牺牲一部分性能为前提的。Tsugawa 等人［11］讨论了SDN 对云计算的影响及其面临的众多新的安全问题，并认为SDN 对网络的弹性控制会促进产生新的思路来应对网络威胁。

1.2 OpenFlow

OpenFlow 是一种符合SDN 定义的通用标准。OpenFlow 交换机具有高度可编程的特征，利用软件根据需要计算出最优流量路由决定。对于OpenFlow交换机，数据层是可编程的，它包含了一个流表(Flow Table)，流表中有流量规则集，定义了数据层应当如何处理动态网络流量［12］。流量规则提供了基本的指令用来管理如何发送、修改和丢弃经过交换机的包。交换机的控制层只需要支持OpenFlow 协议，通过协议交换机与OpenFlow 网络外的控制器通信，以便发送统计信息、新流量请求和更新规则集等。

OpenFlow 控制器在所有交换机之上，协调整个网络的流量规则，为交换机提供必要的流量规则升级。在条件改变时，OpenFlow 控制器对交换机进行重编程。同时，控制器还提供开放的API，使管理员和研究人员开发自己的控制软件和新的重要功能［13］，进行逻辑部署以制定新流量规则。常用的控制器包括OpenDaylight、NOX 等，其中Floodlight 和Ryu 控制器提供了OpenStack 插件，利用Neutron API在OpenStack 中实现独立的网络控制。

1.3 相关攻击

1.3.1 DoS

DoS 旨在对目标主机发起攻击，使其网络资源或系统资源耗尽，从而无法向合法用户提供正常服务。DoS 可以分为2 种类型［14］，第1 种攻击通过向目标系统发送精心准备的数据包而使系统崩溃，比如Ping of Death 和TearDrop，前者通过发送超过IP 协定能容忍的分组数使对方系统宕机，后者则在每个数据要传送前对分组切割的位移信息进行捏造，造成重组时发生错误。第2 种攻击通过产生大量无用流量占据正常服务所需资源，其中最常见的是Flood 攻击，又分为2 种攻击方式［15］:直接攻击通过直接向目标发送大量SYN 请求，使对方系统中的处理器和内存资源耗尽，无法再有效地处理合法请求;反射攻击则通过大量中间节点向目标发送SYN-ACK 或RST 数据包，使目标服务中断。

在网络安全中，拒绝服务攻击以其危害巨大，难以防御等特点成为恶意攻击的常用手段，Darwish 等人［16］集中讨论了几种传统DDoS(Distributed Denial of Service)攻击对云计算的威胁，并指出这些攻击不仅可以从外部发起，还可以基于云环境在内部进行，单一的防御策略已经难以长期有效地阻断攻击。此外，云计算网络构架的大规模、复杂性也给攻击者带来新的攻击思路，Liu 等人［17］提出了一种在云内部发起的新型DoS 攻击，该攻击通过不完全阻塞云网络中的上传链路达到大幅降低服务性能的目标，证实了在云中进行“小规模DoS 攻击”的可行性。

1.3.2 端口扫描

端口扫描首先会向目标主机的特定端口发送消息，通过收到的应答分析出端口的状态，甚至确定其操作系统和漏洞信息。端口扫描通常分为秘密扫描、FTP 反弹攻击、套接字端口探测、TCP 扫描和UDP 扫描等［18］。

攻击者通过对主机进行端口分析而收集主机的相关信息，这通常是网络攻击的第1 个阶段，也是蠕虫传播的基本手段之一。因此，非常有必要检测从云内部发起的端口扫描［19］。同样，攻击者可以利用这些主机发动分布式端口扫描，实验证明［20］，利用至少32 台主机进行分布式的端口扫描可以避免传统入侵检测系统的检测。

2 研究方法

2.1 流量异常检测

异常流量，就是不属于正常网络服务范围内的流量，包括网络攻击流量、网络病毒流量、非法服务流量等。网络异常流量通常会对网络服务的提供和使用造成影响，甚至导致服务中断，产生不可挽回的损失。部署合适的异常流量检测系统不仅是网络正常运营的保证，也是网络日常管理维护的内容之一。

正常情况下，网络连接通常会局限于某些固定的主机集合，而且这些伴有明确目的的连接(比如浏览网页)成功率很高。但SYN Flood 和端口扫描的行为却不同，它们会不断尝试与主机建立新连接，从而恶意消耗目标主机资源或探索开放的端口，这些特殊连接的直接表现就是具有很高的失败率。针对这个特点，本文选择的2 种流量异常检测算法只对新建立的网络连接请求进行检查，算法检测原理如下。

2.1.1 Threshold Random Walk with Credit Based Rate Limiting

TRW-CB［21］分为2 部分:

1)TRW-CB 建立一个“主机连接历史”集，用以记录一定数量的曾经连接过的目的主机;同时建立一个“首次连接”队列，记录这些“历史连接主机”的信息，包括地址、连接状态等。当本地主机要发出一个连接请求时，先根据“主机连接历史”集判断该目的主机是否被连接过，如果没有，则在“主机连接历史”集中添加该主机，并在“首次连接”队列中追加该主机地址，连接状态为“Pending”。如果目的主机允许连接，则更改状态为“Success”，如果收到拒绝连接的响应(TCP RST)或无响应(超时)，则更改状态为“Fail”。每次连接状态的更改(“Success”或“Fail”)都会发出一次计算，计算的值将与阈值进行比较，判断本地主机是否正常。

2)由于第1 部分的计算需要一定时间，为了防止这段时间内产生大量连接请求，算法引入了信用值。每台主机有1 个初始信用值，每产生1 个新的连接请求，信用值-1，当新连接成功时，信用值+2;一定时间周期内，超过初始值的信用值会产生折损，防止信用值无限膨胀;同时，对于信用值消耗完的主机，每隔一定时间会获得一个信用值，避免了主机“彻底断网”引发的不良后果。

2.1.2 Rate-Limiting

Rate-Limiting［22］通过维持一个“工作集”，限制主机建立的连接数目。当主机发出一个连接请求时，首先会检查这个连接是否在“工作集”中，如果“工作集”没有满载或存在此连接记录，则可以正常进行连接;否则，此连接请求会被转存到“延迟队列”中，每隔一段时间，“延迟队列”中的连接请求会被取出并发送，同时更新“工作集”。当“延迟队列”也达到一定长度，Rate-Limiting 将不再接受任何连接请求。

本文对这种算法进行了部分修改，使其能够针对Flood 攻击进行检测。修改如下:

1)主机发出的连接请求，如果目的地址不在“工作集”中，就直接转存至“延迟队列”。

2)工作集的每个目的地址都带有一个状态。新添加的地址状态为“Pending”;如果目的地址对连接请求有积极反馈，则将状态改为“Ready”;如果主机对反馈进行了确认，则状态更新为“Success”。

3)主机可以与工作集中状态为“Success”的目的地址通信。

4)连接建立后的ACK 数据包不会被检测过滤。

2.2 数据集

为了实现对TCP 端口扫描和SYN Flood 攻击的模拟，本文使用文献［23］中实验收集的流量集。该流量集包含普通网络流量和攻击网络流量，其中，普通流量数据分别在家庭网络、SOHO 网络和ISP 网络等3 个规模的节点上收集，攻击流量则包含若干种攻击在不同攻击速率下的数据包。

考虑到云环境下的流量规模和实验条件限制，本文选取SOHO 网络流量集，包含34 台活动主机，在2小时8 分内产生6 369 925 个数据包，共418 MB;攻击流量部分，包含TCP 端口扫描和SYN Flood 攻击分别在低速率(0.1、1、10 pkts/sec)和高速率(100、1 000 pkts/sec)下的流量集，详细信息见表1。利用Wireshark 将攻击流量随机地融合到普通流量中，也就意味着34 台主机中有8 台主机受到了感染而产生攻击行为。

表1 攻击流量数据

3 实验内容

3.1 实验环境

所有实验内容均在2 台运行Ubuntu 13.10 系统的服务器上进行，每台服务器均配有双Intel(R)Xeon(R)E5620 处理器和16 GB 内存。利用这些服务器搭建完成多节点OpenStack Havana 环境，包括控制节点和计算节点。SDN 的实现依赖于控制器和支持OpenFlow 协议的交换机，因此，在网络节点上部署控制器Ryu 3.7，并利用Neutron-Plugin-ryu 等插件实现控制器与OpenStack 的关联;在控制节点和计算节点上，部署了OpenvSwitch，通过OpenvSwitch 可以方便地实现网络虚拟化，包括对OpenFlow 协议的支持。

2 种异常检测算法用Python 实现并分别部署在Ryu 控制器和OpenStack 环境上。同时，实验中专门建立一台虚拟主机，通过TCPReplay 工具重放普通流量集和经过整合过的攻击流量集，实现对整个网络流量的模拟。在OpenStack 环境下，还需要在网桥上增加相应的规则，将流量集的数据包重定向至虚拟安全设备，这意味着整个中心所有VM 的改动(增加、删除、迁移)都需要重新配置相应的规则。而SDN 下则由交换机和控制器智能处理流量。

3.1.1 SDN 环境

在SDN 中，如果一个数据包不与任何流规则匹配，则该数据包会被转发至控制器，控制器按照策略对该数据包进行处理。根据本文所选2 种算法和SDN 的特点，Ryu 控制器没有必要检查主机发送的每一个数据包，只需要处理新的TCP 连接建立时的几个相关数据报。主要流程如下:

1)当源主机产生一个新连接请求时(SYN)，由于交换机上没有匹配规则，该请求会被转发至控制器，控制器正常地发送该请求。

2)如果目的主机对连接做出积极响应(SYN +ACK)，该数据报同样会被转发给控制器，由控制器转发给源主机;控制器上的异常检测算法判断该连接正常，会在交换机上设置2 条流规则，允许目的主机和源主机间进行通信，之后2 台主机间产生的数据包将依据规则由交换机直接进行转发，无需再经过控制器。

3)如果目的主机没有响应(TIMEOUT)或重置连接(RST)，控制器不会在交换机上设置任何新的规则，此后2 台主机间尝试通信的行为仍然被视为建立新连接。

4)如果源主机被异常检测算法判断为具有恶意行为，控制器撤销交换机上所有与源主机相关的流规则，并设置新的流规则，放弃所有与源主机相关的数据包。

3.1.2 标准OpenStack 环境

在标准OpenStack 环境里，建立一台特殊的主机来模拟安全设备，称为检测主机。检测主机配有4 核心和8 GB 内存，负责处理所有其他实例产生的网络流量，检测会覆盖到每一个数据包。如果相关主机被异常检测算法判断为恶意主机，则放弃所有相关数据包，否则转发数据包至交换机，由交换机正常处理。

3.2 实验目的

对采集到的数据进行以下几个方面的分析:

1)精确度，即检测准确率和误报率。ROC(Receiver Operating Characteristic)曲线可以准确刻画入侵检测系统的准确率与误报率之间的变化关系，被广泛用于输入不确定系统的评估［24］。因此，在SDN 和OpenStack 环境下，分别做出2 种算法对不同攻击、速率的ROC 曲线，可以直观反映出检测算法的精确度。

2)效率。在SDN 环境下，分析通过控制器的数据包占全部数量的比率、控制器上数据包的平均通过率、交换机流表中流的数量和交换机流表中流的峰值数量。

3)CPU 和物理内存使用情况，比较分析2 种环境下的资源使用差异。

4 实验分析

4.1 精确度

在SDN 和OpenStack 环境下，TRW_CB 和Rate-Limiting 这2 种算法都对端口扫描攻击进行了检测。从图1 的ROC 曲线可以看出，SDN 下的TRW_CB 在检测端口扫描攻击时具有更低的误报率，但准确度不及OpenStack 环境下的检测。Rate-Limiting 对高速端口扫描攻击的检测有更高的精确度，SDN 下更是达到了100%的准确率和零误报，见图2。

图1 TRW_CB 对端口扫描的检测

图2 Rate-Limiting 对端口扫描的检测

对TCP Flood 的检测只涉及Rate-Limiting 算法。由图3 可以看出，该算法在SDN 下对高速攻击较敏感，而在OpenStack 下则对低速攻击更敏感。

图3 Rate-Limiting 对Flood 的检测

总的来说，流量异常检测算法在SDN 和OpenStack这2 种环境下的表现各有优劣，没有太大的差距。

4.2 效率

表2 列出了SDN 特有的一些统计信息。整个检测过程中，通过控制器的数据包占到全部流量16%左右，即每秒约有130 个数据包通过控制器，相比OpenStack 传统网络下所有的流量都需要流经检测主机的方式更为高效。

表2 SDN 下2 种算法处理的效率

流量异常检测是面向连接的，控制器针对每台正常主机的已有连接和所有感染主机都在相应交换机上自动部署了流规则，平均会下发900 条规则，最大峰值达到1 200 条。这些规则都由控制器智能下发，无需人工干预，减少了人工成本。而在传统的网络下，则需要对每台虚拟机相关的交换机进行部署，才能将流量导入检测主机，是一项庞大的任务。

4.3 CPU 和内存

SDN 控制器和OpenStack 下检测主机的CPU 使用情况见表3。虽然控制器处理的数据量只有全部数据的16%左右，但消耗的CPU 时间片却稍微高出检测主机，除去对网络流量的分析外，控制器还要对OpenFlow 协议进行解析、对交换机进行定期查询获取统计和状态信息等，这些是控制器占用CPU 时间片较高的重要原因。

物理内存的使用上，控制器有绝对优势，平均使用了34 MB 物理内存，约为检测主机的8%左右，后者平均占用415 MB 物理内存。

表3 检测不同速率攻击所需CPU 时间片

5 结束语

本文在OpenStack 下构建了SDN，并对其在流量异常检测方面的性能进行了测试分析，结果表明，SDN 上的安全应用在对安全检测的准确率没有太大影响的情况下，能极大地减少人员配置的成本和失误，同时有效降低资源的消耗。

直接在SDN 控制器上部署安全应用，尤其是面向连接的安全检查，虽然能充分与软件定义的思想相融合，但这种结构对控制平面和数据平面都会产生一定影响:

1)使大约16%左右的网络流量经过控制器直接到达安全应用，而控制器要处理来自很多应用的数据，它的性能对整个网络有非常重要的影响。

2)在交换机上部署了数量庞大的规则，但正如文献［25-26］中描述的，SDN 交换机上存储规则的空间有限，因此，连接面向状态的安全检测会影响数据平面的性能。

在大型数据中心里，动态、复杂的大规模流量会为上述不足带来放大效应，对控制器和交换机产生巨大压力，影响正常业务的工作，甚至使整个网络完全崩溃。因此，必须采用新的安全架构，使得在充分利用SDN 优势的同时，能够有效减少SDN 控制器和交换机的压力，不影响普通业务的正常工作，这将是未来的主要工作。

［1］Kreutz D，Ramos F M V，Verissimo P.Towards secure and dependable software-defined networks［C］// Proceedings of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking.2013:55-60.

［2］Modi C，Patel D，Borisaniya B，et al.A survey on security issues and solutions at different layers of cloud computing［J］.The Journal of Supercomputing，2013，63(2):561-592.

［3］Deshpande P，Aggarwal A，Sharma S C，et al.Distributed port-scan attack in cloud environment［C］// Proceedings of the 5th International Conference on Computational Aspects of Social Networks (CASoN).2013:27-31.

［4］Wang Bing，Zheng Yao，Lou Wenjing，et al.DDoS attack protection in the era of cloud computing and software-defined networking［C］// Proceedings of the 22nd IEEE International Conference on Network Protocols (ICNP).2014:624-629.

［5］Modi C，Patel D，Borisaniya B，et al.A survey of intrusion detection techniques in cloud［J］.Journal of Network and Computer Applications，2013，36(1):42-57.

［6］Dotcenko S，Vladyko A，Letenko I.A fuzzy logic-based information security management for software-defined networks［C］// Proceedings of the 16th International Conference on Advanced Communication Technology (ICACT).2014:167-171.

［7］Lim S，Ha J，Kim H，et al.A SDN-oriented DDoS blocking scheme for botnet-based attacks［C］// Proceedings of the 6th International Conference on Ubiquitous and Future Networks (ICUFN).2014:63-68.

［8］Collings J，Liu Jun.An openFlow-based prototype of SDNoriented stateful hardware firewalls［C］// Proceedings of the 22nd IEEE International Conference on Network Protocols (ICNP).2014:525-528.

［9］Suh M，Park S H，Lee B，et al.Building firewall over the software-defined network controller［C］// Proceedings of the 16th International Conference on Advanced Communication Technology (ICACT).2014:744-748.

［10］Gelberger A，Yemini N，Giladi R.Performance analysis of software-defined networking (SDN)［C］// Proceedings of the 21st IEEE International Symposium on Modeling，Analysis ＆ Simulation of Computer and Telecommunication Systems (MASCOTS).2013:389-393.

［11］Tsugawa M，Matsunaga A，Fortes J A B.Cloud computing security:What changes with software-defined networking?［M］// Secure Cloud Computing.New York:Springer，2014:77-93.

［12］McKeown N，Anderson T，Balakrishnan H，et al.Open-Flow:Enabling innovation in campus networks［J］.Computer Communication Review，2008，38(2):69-74.

［13］Vaughan-Nichols S J.OpenFlow:The next generation of the network?［J］.Computer，2011，44(8):13-15.

［14］Chang R K C.Defending against flooding-based distributed denial-of-service attacks:A tutorial［J］.IEEE Communications Magazine，2002，40(10):42-51.

［15］Peng Tao，Leckie C，Ramamohanarao K.Survey of network-based defense mechanisms countering the DoS and DDoS problems［J］.ACM Computing Surveys，2007，39(1):Article 3.

［16］Darwish M，Ouda A，Capretz L F.Cloud-based DDoS attacks and defenses［C］// Proceedings of the 2013 International Conference on Information Society (i-Society).2013:67-71.

［17］Liu Huan.A new form of DOS attack in a cloud and its avoidance mechanism［C］// Proceedings of the 2nd ACM Workshop on Cloud Computing Security.2010:65-76.

［18］Bhuyan M H，Bhattacharyya D K，Kalita J K.Surveying port scans and their detection methodologies［J］.The Computer Journal，2011，54(10):1565-1581.

［19］Akbarabadi A，Zamani M，Farahmandian S，et al.An Overview on Methods to Detect Port Scanning Attacks in Cloud Computing［DB/OL］.http://www.wseas.us/e-library/conferences/2013/CambridgeUK/AISE/AISE-30.pdf，2013-12-22.

［20］Riquet D，Grimaud G，Hauspie M.Large-scale coordinated attacks:Impact on the cloud security［C］// Proceedings of the 6th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing(IMIS).2012:558-563.

［21］Schechter S E，Jung J，Berger A W.Fast detection of scanning worm infections［C］// Proceedings of the 7th International Symposium on Recent Advances in Intrusion Detection.2004:59-81.

［22］Twycross J，Williamson M M.Implementing and testing a virus throttle［C］// Proceedings of the 12th USENIX Security Symposium.2003:285-294.

［23］Mehdi S A，Khalid J，Khayam S A.Revisiting traffic anomaly detection using software defined networking［C］//Proceedings of the 14th International Symposium on Recent Advances in Intrusion Detection.2011:161-180.

［24］McHugh J.The 1998 Lincoln laboratory IDS evaluation［C］// Proceedings of the 3rd International Workshop on Recent Advances in Intrusion Detection.2000:145-161.

［25］Curtis A R，Mogul J C，Tourrilhes J，et al.DevoFlow:Scaling flow management for high-performance networks［C］// Proceedings of the 2011 ACM SIGCOMM Conference on Applications，Technologies，Architectures，and Protocols for Computer Communications.2011:254-265.

［26］Sekar V，Egi N，Ratnasamy S，et al.Design and implementation of a consolidated middlebox architecture［C］//Proceedings of the 9th USENIX Symposium on Networked Systems Design and Implementation.2012:323-336.