基于API调用管理的SDN应用层DDoS攻击防御机制

王洋，汤光明，王硕，楚江

（1.信息工程大学，河南 郑州 450001；2.中国西安卫星测控中心，陕西 西安 710043）

0 引言

软件定义网络（SDN，software defined network）及其相关技术已经成为未来网络发展的重要方向之一[1-3]。然而，随着软件定义网络的不断发展和实践应用，SDN面临诸多安全问题，极大地影响了其发展进程[4]。事实上，由于SDN架构的核心在于将网络控制任务交给控制器处理，控制器自然而然成为整个网络架构的大脑，但这同时导致控制器成为网络攻击的焦点。特别地，攻击者往往会发动针对控制器的分布式拒绝服务（DDoS，distributed denial-of-service）攻击，从而使控制器资源耗尽，最终导致整个网络瘫痪。因此，研究抵抗面向SDN的DDoS攻击及检测技术成为当前SDN安全问题的研究热点[5]。

分析现有研究可知，针对SDN的DDoS攻击及检测技术集中于数据层和控制层，其发动攻击的原理在于利用OpenFlow协议中的漏洞，通过持续发送特定数据包使交换机流表溢出或控制器资源耗尽。具体地，在数据层，攻击者通过增加僵尸节点个数等手段使交换机流表空间溢出而无法正常工作[6]。在控制层，攻击者通过向控制器持续发送packet-in数据包，导致控制器资源耗尽而拒绝服务[7]。针对该类型的DDoS检测方法可分为三类（基于规则的检测方法、基于统计信息的检测方法和基于机器学习的检测方法）[8]，其本质是对SDN中的流量进行约束和测量。近年来，随着深度学习技术的不断发展，其相关技术广泛应用于DDoS攻击检测[9-12]。而针对该种类型的防御机制，主要依托于限速和迁移。Kandoi等[13]提出利用一种通过限制数据传输速率来缓解数据层或控制层DDoS攻击的方法。乔思祎等[14]对OpenFlow交换机流表溢出问题的缓解机制进行了深入研究，提出流表共享（FTS，flow table sharing）方法，完善了流表溢出处理机制。武泽慧等[15]提出基于OpenFlow交换机洗牌的DDoS攻击动态防御方法，来缓解交换机遭遇的DDoS攻击。

事实上，SDN控制层北向接口（NBI，northbound interface）的安全性同样对SDN的正常运行起关键作用。北向接口，作为控制层与应用层的通道，随着SDN应用的广泛普及，必然会受到越来越多攻击者的关注。然而，针对北向接口的防御研究还比较少，主要集中在利用访问控制来隔离攻击者。Wen等[16]将控制器上的应用程序和控制器内核进行隔离，提出一个应用程序访问权限管理系统，实现对应用程序权限的细粒度访问控制。与之类似的，还有Klaedtke等[17]的工作。然而，一些攻击者会通过研究访问控制规则，设计相应的绕过机制，从而使该类型的防御机制失效。鉴于此，本文研究主要针对SDN应用层DDoS攻击的防御，结合北向接口发展特点[18-20]，提出一种基于应用程序接口（API，application programming interface）恶意调用的SDN应用层DDoS攻击场景。进一步地，为了防御该种类型攻击，提出基于API调用管理的SDN应用层DDoS防御机制，该机制通过在SDN应用层和控制层之间增加一层App管理层，进而通过对App的信誉管理、初始审查、映射分配、异常检测和识别迁移，来抵抗恶意App对SDN的攻击。

1 SDN架构及应用层DDoS攻击场景

SDN架构的核心思想是通过分离网络控制与数据处理，赋予网络可编程性，提高网络的智能化与灵活性，最终提高网络的整体运行效率。当前，SDN的经典架构分为应用层、控制层和数据层。

应用层主要指实现特定功能的SDN应用程序。从当前发展来看，SDN应用程序大多是为了实现网络的负载均衡、拓扑构建以及安全管理等功能。控制层作为SDN的核心，其主要依据SDN应用需求，通过生成能够用来控制细粒度网络流量编排的流表，进而实现对网络的控制。数据层主要负责基于控制层下发流表的数据转发。上述三层由两个接口连接，北向接口用于连接应用层与控制层，而南向接口（SBI，southbound interface）用于连接控制层与数据层。

事实上，OpenFlow已成为当前南向接口的标准，针对南向接口的研究相对成熟，其安全性也得到很多学者的关注。然而，学者对北向接口的研究较少，目前还没有形成得到广泛认可的标准，其安全威胁更令人担忧。随着SDN技术的不断发展，其应用必定会更加丰富多样，而北向接口作为开放给用户的端口，是用户通过可编程来实现自定义功能的重要通道。依据当前SDN技术的发展潮流，灵活性将是SDN技术的灵魂。因此，设计北向接口的关键在于接口的可编程性与调用管理的便捷性。表征状态转移（REST，representational state transfer）作为设计开放灵活接口的约束准则，受到研究者的普遍关注。越来越多的学者倾向于利用REST架构来定义SDN应用所需的各种API，进而使SDN应用层的应用程序能够直接调用API来实现应用程序的高效开发，最终推动SDN技术的快速普及。基于该种技术，SDN应用层可事先实现安全状态信息收集、链路流量信息收集、流量规则冲突分析、流规则超时回调、流规则修改、交换机配置信息获取、控制器配置信息获取、IP地址跳变等API，进一步以这些API为接口提供给SDN应用调用。软件定义网络中应用层工作时API调用时间序列示例如图1所示。

图1 软件定义网络中应用层工作时API调用时间序列示例 Figure 1 Example of API call time sequence when SDN application layer works

由以上分析可知，SDN北向接口的安全性直接关系到整个SDN正常运行。当前，针对SDN北向接口安全性的研究还比较少，缺乏严格的访问控制、身份认证及异常调用检测等机制，这可能导致一些攻击者故意开发恶意的应用程序，造成北向接口API的滥用，以此实现对SDN的攻击。鉴于此，本文研究主要针对SDN应用层DDoS攻击的防御。结合SDN网络架构，模拟两种攻击者利用恶意的API调用实现SDN应用层的DDoS攻击场景，如图2所示。

图2 软件定义网络中应用层DDoS攻击场景 Figure 2 DDoS attack scenario in SDN application layer

攻击场景1：在该攻击场景下，攻击者设计恶意App，绕过北向接口的安全审查，对某些API进行短时间大量调用，进而导致控制器崩溃，使整个网络瘫痪。

攻击场景2：在该攻击场景下，攻击者以某个合法SDN应用程序作为攻击目标，对该应用程序所需用的特定API进行短时间大量调用，使该合法App无法正常调用API，进而使该合法App无法正常工作。与场景1相比，该种攻击相对比较隐蔽。

2 API可信调用机制

由上文可知，为抵抗攻击者利用恶意的API调用实现SDN应用层的DDoS攻击，对北向接口的安全管理成为防御的关键。鉴于此，本文提出一种基于API调用管理的SDN应用层DDoS防御机制，该机制通过在SDN应用层和控制层之间增加一层App管理层，进而通过对App的信誉管理、初始审查、映射分配、异常检测和识别迁移，来抵抗恶意App对SDN的攻击，整个架构如图3所示。App管理层各个模块之间的协同关系如图4所示。

由图3和图4可知，为了实现对SDN北向接口的安全调用，提出的App管理层主要分为App运行前的合法审查、App与控制器映射分配、App运行时实时的异常检测、非法App的识别迁移以及App信誉度评分5个主要模块。其中，App运行前的合法审查、App与控制器映射分配、App运行时实时的异常检测与恶意App的识别迁移是按App能够正常运行在SDN中的逻辑先后顺序划分的：只有通过合法审查的App才能运行在SDN中；运行之前，需要App与控制器映射分配，以实现运行效率的最大化；运行过程中，需要对其进行实时的异常检测；一旦发现异常，则需要恶意App的识别迁移，以保证网络重新正常运行。App信誉度评分则能够为App运行前的合法审查以及App与控制器映射分配提供依据。

图3 软件定义网络中应用层DDoS防御架构 Figure 3 DDoS defense architecture of SDN application layer

图4 App管理层各个模块之间的协同关系 Figure 4 Synergy between modules of App management layer

（1）App运行前的合法审查

对于SDN应用层中的每一个App，在其运行之前，均需要对其的API调用序列进行合法性检测，检测结果判定为合法或不合法。经判定不合法的App无法在应用层运行。

（2）App与控制器映射分配

随着SDN的不断发展，SDN应用不断丰富，单一的控制器网络架构往往无法满足网络实际需求，而多个控制器协同工作是SDN控制层发展的必然趋势。在此情况下，SDN的应用层存在App与控制器映射分配的问题，即通过将当前网络所有运行的App合理分配给不同的控制器，实现控制器资源的最大化利用。

（3）App运行时实时的异常检测

尽管每一个App在SDN应用层运行之前均需进行合法性审查，然而事实上，任何审查均存在一定的漏报率和误报率。此外，由上文描述的攻击场景2可知，一些攻击者会精心设计恶意App，使它们能够通过合法性审查而依然可对SDN实施攻击。鉴于此，SDN需要实时对App运行状况进行异常检测。进一步分析可知，SDN的应用层DDoS攻击最终均会导致控制器资源耗尽，从而使合法用户无法正常调用API。因此，通过对控制器运行状态的监视，能够及时发现当前SDN状态的异常。

（4）恶意App的识别迁移

由合法审查和异常检测模型可知，当恶意App绕过审查而运行在SDN应用层时，最终会导致控制器运行异常。本文仅考虑SDN应用层的攻击，即假定SND的控制层以及数据层不再遭遇其他类型的攻击。由映射分配模块可知，运行在同一个控制器上的App可能有多个，当该控制器异常时，反映出连接在该控制器上的App存在恶意App，则非法App的识别迁移模块对这些App进行识别，即判断出哪些App是合法的而哪些App是恶意的，在此基础上，进一步暂停恶意App运行而保证合法App的正常运行。

（5）App信誉度评分

通过对上述模块分析可知，增加App管理层的目的是对恶意App的识别封禁，以保证合法App在SDN应用层的正常运行。在此过程中，防御者可对所有App进行统一的信誉度评分，对恶意App的来源进行标记，通过信誉度评分来提高对恶意App的检测效率。

通过以上分析可知，App运行时的异常检测可通过对控制器运行状态的监视来实现，而当前针对SDN控制器异常检测的研究很多，本文不做重点研究。此外，针对App信誉度评分的研究，可参考类似的信誉度评价相关模型[21-23]，与SDN特性关联性不强。本文将App信誉度评分设定为0到10分，且将小于5分的App设为恶意App，在此基础上，分别提出基于滑动时间窗口的API调用合法性审查、基于信誉度排序的SDN应用映射分配和恶意App清洗分离，以此实现完整的App管理层模块。针对多控制器之间的管理与通信研究较多[3,24]，这里不做深入探讨。

需要注意的是，软件定义网络应用层DDoS攻击与软件定义网络中SDN控制器是否是分布式的没有任何关系。即无论软件定义网络中SDN控制器是单个还是多个，攻击者均可对其发动应用层DDoS攻击。而本文强调的多控制器的目的是防御该种DDoS攻击的需要：当软件定义网络中的控制器仅有一个时，一旦攻击者对其发动应用层DDoS攻击，整个网络便会瘫痪；而当软件定义网络中的控制器有多个时，防御者可通过对恶意App清洗分离来保证整个网络的正常运行。

2.1 基于滑动时间窗口的API调用合法性审查

由上文可知，SDN应用通过北向接口调用丰富的API以实现不同特定的功能。而针对SDN应用层的DDoS攻击，往往会开发恶意的App，进而对某些API进行短时间大量调用，以此耗尽控制器资源，使整个网络崩溃。通过深入分析攻击过程可知，为了避免API被恶意调用而导致SDN的崩溃，需要使所有App在调用API时满足以下两个约束条件。

（1）同一个API之间的调用周期约束Tapix≥不妨假设北向接口中共有n个可供调用的API，API={api1,api2,api3,…,apin}。为了使SDN正常运行，每个API设定一个最小调用周期限制，以保证应用的正常运行，即apix的最小调用周期为，如对于“IP地址跳变”API来说，当过于频繁调用该API时，SDN中的节点地址跳变过于频繁，不能保证正常业务的运行。

（2）不同API之间的调用资源约束R(T)≤Rmax(T)

在SDN中，由于控制器的高度集中性，特别对于单控制器SDN，控制器具有一定的资源上限，若时间间隔T内，调用的API所需资源高于控制器资源上限，则控制器将无法正常运行，即R(T)≥Rmax(T)。不妨对每个API调用时所需资源进行量化，设调用apix时所需资源为。进一步假设SDN正常运行时，某一T时间内调用的API序列为API(T)={api1,api2,api3,…,apim}，则易知

以上两个约束条件从API本身特性及其对资源需求角度对其正常调用进行了规定。显然，符合两个约束条件的App为合法App，不符合的则为恶意App。

进一步，本文以上述两个约束条件为依据，提出了基于滑动时间窗口的API调用合法性审查算法，如算法1所示。

算法1基于滑动时间窗口的API调用合法性审查算法

输入某个Appm的API调用时间序列，各个API的最小调用周期，控制器调用资源约束Rmax(T)

输出 Result=Yes or No—Appm是否合法

2.2 基于信誉度排序的SDN应用映射分配

为满足日益增长的SDN应用层需要，SDN控制平面往往会采取多个控制器协同工作的方式，且多个控制器实现负载均衡[25-26]。在此情况下，需要将所有SDN应用映射分配到不同的控制器，使整个SDN负载均衡，最终实现网络资源利用的最优化，SDN应用映射分配示例如图5所示。

由图5可知，同一个控制器上往往分配有多个App，显然，这些App同时运行时需要满足算法1的两个约束条件，才能保证控制器的正常运行。事实上，对App的合法性审查本质上是对其调用的API时间序列进行审查。由图1可知，将多个App的API调用时间序列进行合并，并依据API调用时间由小到大排列，可形成多个App共同运行时的API调用时间序列。由此可知，利用算法1能够实现对多个App能否共同运行做出判断。此外，为了使整个控制平面实现负载均衡，从资源利用的角度，各个控制器映射分配过程需要考虑控制器负载。鉴于此，本文提出基于信誉度排序的SDN应用层映射分配算法。

图5 SDN应用映射分配示例 Figure 5 Example of SDN application mapping allocation

算法2基于信誉度排序的SDN应用层映射分配算法

输入目前待映射分配的SDN应用集合APP={app1,app2,app3,… ,appm}，控 制 器 集 合C= {c1, c2,c3,…, cn}，控制器调用资源约束Rmax(T)。

输出SDN应用集合与控制器集合间的映射分配关系App →C

1) 将待映射分配的SDN应用集合中的app按信誉度排序

2) for每一个appl∈ APP //令Seq(appl)表示应用appl的API调用时间序列

3) for每一个ci∈C//假定将appl映射分配至控制器ci，此时控制器ci运行的app集合记为 ci(app)，则其 API调用时间序列记为 Seq(ci)

在算法2中，整个SDN中的负载均衡用diff表示，其可从两个方面进行量化：一是同一个控制器中运行的App构成的API序列调用相对平滑；二是不同控制器间资源利用相对均衡。具体量化方法如下。

（1）设Rk为时间序列，用于表示控制器在不同时间间隔T所占用的资源，用 diff1(Rk)来量化该时间序列的平稳度，其值越小，说明控制器运行越平稳，负载均衡越好。通过实际SDN运行分析可知， diff1(Rk)的确定方法如下。

（2）用 diff2(C)表示不同控制器中负载均衡程度。为简单起见，本文采用不同控制器的时间序列Rk中的元素均值之间方差来进行量 化，即

（3）依据不同SDN实际需求，分别为上述两个要素设定不同的权重，进而利用权重和得到diff。

其中，α和β分别为上述两要素的权重，满足α+β=1。

2.3 恶意App清洗分离

当一个SDN控制器上运行有恶意App时，该SDN控制器由于资源耗尽而无法正常服务，该SDN控制器被称为受攻击控制器。在该种情况下，由于该控制器上运行着多个App，防御者无法分辨哪些App是恶意的，哪些App是合法的。鉴于此，如何对受攻击控制器上运行的App进行快速清洗以分离出恶意App，并进一步对合法App重新分配控制器以保证其正常运行，是一个值得研究的问题。SDN应用层恶意App清洗分离过程示例如图6所示。

图6 SDN应用层恶意App清洗分离过程示例 Figure 6 Example of cleaning and separating malicious App in SDN application layer

图6中共有9个SDN应用，其中包含两个恶意的App，即app5和app7，控制平面有3个控制器。经过初始的映射分配，app1、app2和app3分配到控制器c1，app4、app5和app6分配到控制器c2，app7、app8和app9分配到控制器c3。当SDN运行时，由于恶意App的存在，控制器c2和c3无法正常工作。而防御者无法识别连接到这两个App上的应用程序哪些是合法的，哪些是恶意的，如图6(a)所示。在此情况下，防御者实施恶意App清洗分离过程，如图6(b)所示，随机将app5分配到控制器c3，而将app8分配到控制器c2。在此情况下，控制器c2将恢复正常运行，而控制器c3将依然无法正常运行。由此可知，在SDN遭遇攻击时，恶意App清洗分离能有效分离出合法App和恶意App。为了最大化清洗分离效率，本文对此过程进行如下建模。

设需要清洗分离的App集合为A，可供清洗分离的SDN控制器集合为C，控制器编号为1到|C|，其中|C|为控制器数量。每一轮的清洗分离可看作一个映射f。对于任一个控制器ci∈C，分配给该控制器的App集合记为Ai=f(ci)，显然Ai∈A。由于每一个App只能分配给一个控制器，则

进一步，设恶意App数量为Nv，设经过一轮清洗分离操作后，仍有Na个合法的App无法正常运行（被攻击），而有Nu个合法App可以正常运行，显然，|A|=Na+Nu+Nv，其中|A|为所有待分配App数量。本文的目标是设计最优的清洗分离方法f，以使在各种条件下Nu的E(Nu)期望最大。如前文所述，对于任一个控制器ci∈C，分配给该控制器的App集合记为Ai=f(ci)，进一步，不妨设。由于只有当一个控制器上分配的所有App均为合法App时，该控制器才能正常工作。相反，只要一个控制器上分配有一个恶意App，该控制器便无法正常工作，则控制器ci能正常工作的概率记为

经过Ai=f(ci)操作后，能够分离出来的合法App数量的期望为pi⋅|Ai|。进一步，易知

由于控制器资源的限制，当将App集合Ai分配给该控制器ci时，存在即使所有Ai中的App均为合法App而控制器也无法正常工作的情况，即控制器ci无法满足App集合Ai中所有App同时正常运行。鉴于此，在清洗分离过程中，需要保证分配给控制器的App集合不能超出该控制器的资源限制。该条件可由算法1来判断，即可表示为

综上所述可知，对恶意App清洗分离问题可视为一个最优化问题，其目标函数为方程(8)，变量为分配方案f，约束条件为式(9)。直观上，可供清洗分离的SDN控制器数量越多，则经过每一轮清洗分离后合法App被分离出来的数量越多。若|C|≥|A|，则每一个App都能被分配到一个专有的 SDN 控制器上，在该种情况下，E(Nu)=|A| −Nv，它意味着所有合法的App均能正常运行，而所有恶意的App均被一轮清洗分离而分离出来。然而，在实际的SDN中，控制器的数量一般较少，甚至是一个控制器的情况，而App的个数一般远远多于控制器的个数。考虑到此，如何设计清洗分离算法使尽快识别出恶意App是十分重要的。对于|C|≥1时，目标函数是非线性的，且该类问题是NP难问题。对于该问题，本文利用贪心思想计算得出该方案的接近最优解，其具有多项式时间。该恶意App清洗分离算法如下。

算法3恶意App清洗分离算法

输入目前待清洗分离的SDN应用集合A，可用的控制器集合C

输出各个控制器上分配的SDN应用集合，用f表示，即f(ci)表示控制器上分配的App集合

1) 将待映射分配的SDN应用集合A中的所有app按信誉度排序形成Applist

2) if length(AppList)≤|C|

3) 为每一个App分配一个控制器

4) else

5) fori=1:|C|do //|C|表示集合C中的元素总个数

6)f(ci)=Appassign(ci, Applist)

7) AppList=AppListf(ci)//将当前已分配完成的App从列表中删除

8) end

1) Function Appassign(ControlID, AppList)//ControlID表示需要分配App的控制器，AppList表示当前所有待清洗分离的App列表，该列表以App信誉度评分从高到低排列

由此，可依据每一轮分配后的控制器能否正常工作，来清洗分离出恶意App。经过多轮的清洗分离操作，最终将会使所有恶意App均被分离识别。

此外，SDN中的恶意App数量越多，越要保证清洗分离尽快完成，则需要越多可供分配的控制器。因此，清洗之前，对SDN中的恶意App数量进行评估，能够为设定合适的控制器数量提供依据。需要注意的是，若一个控制器上所有的App均为合法App，则该控制器正常运行，不参加恶意App的清理分离任务；若一个控制器上至少存在一个恶意App，则该控制器上的其他合法App也无法正常工作，而通过不断的清洗分离，这些合法的App将被分配至其他的控制器，最终得以正常工作。由此可见，恶意App清洗分离过程可能会导致无法正常工作的合法App频繁切换控制器，但不会对本身正常运行的合法App造成影响。

不妨设appl的信誉度评分为 creditappl，则一个App为恶意的概率可记为

一个App为正常的概率为

于是

进一步，利用最大似然估计原理，可得

其中，X*表示控制器ci上恶意App数量的估计值。

3 实验与验证

针对SDN应用层的研究比较少，基于REST API调用的SDN应用较缺乏。本文借鉴已被学者认可的大规模网络端地址跳变实现机理[27]，通过仿真实现了一个使目标SDN所有终端地址跳变的API。具体地，借助Mininet创建SDN拓扑，RYU作为控制器，如图7所示。

图7 实验网络的拓扑结构 Figure 7 Topology of experimental network

图7所示实验网络中的终端数量可动态调整，正常情况下，各终端之间能够维持通信，从而保证正常的业务活动。当SDN应用程序调用跳变API时，该网络中所有终端的IP地址会发生跳变，而后该SDN仍能正常工作。然而事实上，若攻击者制作一个恶意App，该App短时间大量调用跳变API，显然会造成网络崩溃，这种情况相当于攻击者从SDN应用层发起了DDoS攻击。本文实验部分所配置的控制器个数是动态变化的，而图7为了便于画图需要，又为体现多个物理控制器的逻辑集中，故用一个控制器代替。为了进一步验证SDN应用层攻击会为网络正常运行造成影响，首先对网络正常运行的条件进行定量表示：模拟SDN业务需求，设定两台主机维持运行服务4 h，每隔10 min服务一次，每次服务需要维持一定的服务时间（ST，service time）。若网络达到该要求，即可认为网络正常运行。进一步，通过仿真得到，不同条件下SDN服务正常运行率与跳变API调用频率(次数/小时)之间的关系如图8所示。

图8 不同条件下SDN服务正常运行率与 跳变API调用频率之间的关系 Figure 8 Relationship between normal operation rate of SDN service and call frequency of hopping API under different conditions

由图8可知，对于不同的服务时间要求，SDN服务正常运行率均随跳变API调用频率的增大而减小，且当跳变API调用频率达到一定值后，SDN服务正常运行率会变得很小，即不能正常工作。由此可见，当SDN应用通过短时间内高频率的调用API能够使SDN运行的正常服务瘫痪，即造成SDN应用层DDoS攻击。由此，可通过对具体的SDN进行实际运行测试，以此来准确设定参数和Rmax(T)的值。

通过对现有文献进行分析，针对SDN北向接口安全性的研究比较少，Oktian等[28]提出了一种针对SDN北向接口API身份认证的方法。但其存在两方面缺陷：一是认证方法仅是理论上的且设计相对简单，实际的应用效果并不明确；二是对于前文提出的攻击场景2中攻击方法无效，一些攻击者会采用分布式的攻击方法，通过构造多个看似合法的App（每个App都能通过身份认证），并利用这些App同时调用同一个API，以实现对SDN应用层的攻击。事实上，本文提出的基于API调用管理的SDN应用层DDoS攻击防御机制，侧重于在攻击发生前对恶意App进行事先审查，以避免攻击的发生。其次，若攻击发生，需要对合法App和恶意App进行快速清洗分离。本文算法对上文提出的两个攻击场景均有较好的防御效果。此外，算法的运行效率是验证该防御机制有效性的关键。鉴于此，对上一节所示3个算法运行效率进行了仿真测试。API序列长度对API调用合法性检查所用时间的影响如图9所示。

图9 API序列长度对API调用合法性检查所用时间的影响 Figure 9 The influence of API sequence length on the time for checking the validity of API calls

在本文实验中，App序列长度指的是SDN应用程序所调用的API数量，如某一App的调用API序列为API={api1,api2,api3,…,apim}，则称该App序列长度为m，即App序列长度可认为是该App调用的API序列长度。显然，App序列长度对算法运行效率有较大的影响。由图9实验结果知，当API序列长度小于600时，API调用合法性检查算法所需时间在100 s以内。事实上，该审查算法一般在App运行之前进行，对实时性要求不高；其次，通过分析已有的SDN应用，其API调用长度一般在100以内。综上可知，本文所提算法能够满足实用要求。

进一步，当设定App数量为100、SDN控制器数量为4时，API序列长度对映射分配所用时间的影响如图10所示；当设定App数量为100、App序列长度为10时，SDN控制器个数对映射分配所用时间的影响如图11所示；当设定App序列长度10、SDN控制器数量为4时，App个数对映射分配所用时间的影响如图12所示。

图10 API序列长度对映射分配所用时间的影响 Figure 10 Influence of API sequence length on mapping allocation time

图11 SDN控制器个数对映射分配所用时间的影响 Figure 11 Influence of SDN controller number on mapping allocation time

图12 App个数对映射分配所用时间的影响 Figure 12 Influence of the number of Apps on the time of mapping and allocation

图10～图12中所示的API序列长度指的是所有App序列长度均保持一致。由图10可知，当API序列长度维持在300以内时，映射分配所用时间维持在1 000 s以内，而当API序列长度继续增长时，映射分配所用时间呈指数增加；由图11可知，当API序列长度、App数量一定时，映射分配所用时间随SDN控制器数量近似呈线性增加；同样地，由图12可知，当API序列长度、SDN控制器数量一定时，映射分配所用时间随App数量近似呈线性增加。由上述3个图可知，App序列长度对映射分配所用时间的影响最大。事实上，对于SDN来说，正常运行时，App数量一般不会超过200，API序列长度不会超过100。在该种情况下，无论SDN控制器数量多少，映射分配所用时间均在可接受时间内，能够满足实际网络需求。

最后，本文对恶意App清洗分离算法进行了仿真测试，设定正常App数量为100，恶意App数量为10，App序列长度为10，则得出SDN控制器个数对清洗分离次数的影响如图13所示，SDN控制器个数对清洗分离所需时间的影响如图14所示。

图13 SDN控制器个数对清洗分离次数的影响 Figure 13 Influence of the number of SDN controllers on cleaning and separation times

由图13和图14可知，当SDN中正常App数量、恶意App数量以及App序列长度一定时，清洗分离次数以及清洗分离所需时间均随SDN控制器个数的增加而降低，且清洗分离所需时间低于1 000 s。由此可知，在SDN中，通过部署多个SDN控制器，能够加快清洗分离所需时间，降低DDoS攻击对目标网络的影响。

图14 SDN控制器个数对清洗分离所需时间的影响 Figure 14 Influence of the number of SDN controllers on the time required for cleaning and separation

4 结束语

针对DDoS攻击对北向接口造成的威胁日益扩大的问题，本文模拟了对其可能的DDoS攻击样态，并据此建立了基于API调用管理的SDN应用层DDoS防御机制。该机制通过在SDN应用层和控制层之间增加一层App管理层，进而通过对App的信誉管理、初始审查、映射分配、异常检测和识别迁移，来抵抗恶意App对SDN的攻击。实验结果表明，本文提出的安全防御方案能够有效地对SDN应用层的DDoS攻击进行防御。