攻击感知型安全功能链重排序

 

摘要

攻击感知是指安全系统对发生的攻击具有自我意识。对云和网络基础设施的更频繁和更激烈的攻击正在将安全系统推向极限。随着Moore’s Law（摩尔定律）的终结，仅仅针对这些攻击的规模化已经没有经济上的合理性。之前的工作已经涉及到在安全系统中采用软件定义网络和网络功能虚拟化这两种方法，通过安全功能的智能布局来优化性能。然而，这些工作还没有考虑流量通过这些功能的顺序。在这项工作中，我们通过展示这种排序的影响，来提出需要考虑这种排序的理由。然后，我们提出了一个重排序的框架，并分析了安全服务功能链的建模和基于这些模型进行排序的决策需要哪些方面。我们展示了排序的影响，并在评估环境中验证了我们的框架。该效果可以扩展到多个数量级，而框架的评估证明了我们概念的可行性。

 

I.前言

如今的网络攻击依赖于大规模的僵尸网络。随着物联网(IoT)时代在线设备数量的快速增长，它们的攻击力也随之上升。摩尔定律（承诺每两年资源翻番）的终结限制了投入额外资源对抗攻击的机会。此外，按需预订额外资源的成本非常高，特别是考虑到僵尸网络的所有者不必为其攻击资源付费。

通过网络提供服务的IT系统提供了各种攻击载体。对于每种类型的网络攻击，都有专门的安全功能来防御系统。多个安全功能共同组成安全服务功能链（SSFCs），以保护系统免受一系列攻击类型的攻击。对于大多数系统来说，消耗的资源和处理包的数量之间有直接的关系。相比之下，安全功能（SSFCs）尤为突出，因为它们会丢弃被认为是恶意的数据包，从而降低后续安全功能的负载。

图1显示了具有三种不同安全功能的SSFC。在目前的大多数安全架构中，这些SSFC都是通过软件定义网络(SDN)使用固定的顺序进行硬接线或互连。

如果设置是在标准负载下，且未发生攻击，则SSFC指令不相关。所有数据包都是良性的，因此必须通过SSFC中的所有安全功能。重排序这类功能不会改变良性数据包所产生的资源需求。

当攻击发生时，这种情况会发生变化，这符合其中一个安全功能。在初始配置下，流量会通过SSFC中的所有安全功能。因此，它在每一步都会产生资源需求，直到最后一个安全功能截住它。当我们把蓝色的安全功能放在SSFC前面时，这个次序会致使第一个安全功能立即丢弃恶意流量。因此，流量不会传递给白色和红色安全功能，而只在蓝色安全功能处产生资源需求。表 I显示了一个示例方案，证明优化配置可以减少所需实例的总数。主要涉及网络功能虚拟化(NFV)的相关工作作为安全功能的启动程序，涵盖了SDN要么是安全风险要么是其特征。据我们所知，没有任何别的工作是去分析SSFC指令的性能影响，也没有提出SSFC重排序的解决方案和模型。

这项工作介绍了以下贡献：

1）分析了不同的单个安全功能和不同次序的SSFCs安全功能的性能影响。

2）一个关于概念验证(PoC)的实现，以及动态SSFC重排序框架评估的设计。

表 I: SSFC例子中关于不同SSF次序的资源需求的计算示例。每个实例的吞吐量：红色100 MBit/s，蓝色150 MBit/s，白色200 MBits/s。负荷曲线：950 MBit/s恶意流量匹配蓝色安全功能和50 MBit/s良性流量。

3）网络内部流量、单一安全功能和SSFC的建模形式。

本文剩余部分的结构如下：

首先，第二节和第三节介绍了所需的背景和相关工作。第四节我们分析了安全功能和SSFC性能，第五节介绍了我们的SSFC重排序框架。第六节介绍了各个安全功能和SSFC的建模方法，第七节提供了我们的结论和未来展望。

 

II. 基本原理

对于我们的方法，我们会使用各种安全功能。此外，SDN和NFV也是重要的底层技术。

A.安全设备

我们在这项工作中使用了多种安全功能，主要侧重于DPS、IDPSes和防火墙。

1）分布式拒绝服务（DDoS）防护系统：SYN Cookies是缓解DDoS攻击最常用的机制之一。它很容易被运行在主线Linux内核之上的服务所使用，因此被广泛采用。SYN泛洪攻击利用TCP缓冲区的有限大小，而TCP缓冲区是建立新连接的关键资源。SYN cookies是一种符合传输控制协议(TCP)标准的方式，可以消除与半开放连接相关的缓冲区条目。SYN cookies是一种符合传输控制协议(TCP)标准的，可以消除与半开放连接相关缓冲区条目需求的方法。一般来说，存储在缓冲区的数据是非常必要的，因为它可用于检查收到的ACK包是否属于以前的SYN和SYN+ACK数据包，以及客户端是否正确收到服务器的初始序列号。SYN cookie的方法并不是在本地存储这些信息，而是将其编码到发送的SYN+ACK包中，并从ACK响应中检索这些信息。

2）入侵检测和预防系统（IDPSes）：入侵检测和预防系统结合了入侵检测系统（IDSes）和入侵预防系统（IPSes）。 IDSes可以检测攻击并提供额外的防御机制，而IPSes则能够主动防御传入的攻击。 IDPS可以根据监控平台的类型、使用的攻击检测方法、监控方法和部署架构进行分类。在这项工作中，我们重点研究了基于网络的、基于误用的、实时的和非分布式的IDPSes。一个基于网络的IDPSes被战略性地放置在网络上，以检测任何来自网络外部的攻击。基于误用的IDPS主要针对单一的攻击，通常是通过单一步骤[1]来利用选定的漏洞进行攻击。此处，IDPSes使用包含漏洞特征的签名进行检测。实时IDPS在数据包到达目标系统之前进行拦截，并与流量同步运行。非分布式IDPS部署在网络内部的一个单一（中心）位置。

3）防火墙：防火墙可以定义为一个插在网络与互联网之间建立受控链接，并在外部竖起一道安全墙或周界的中间系统。这种周界的目的是保护网络免受基于网络的威胁和攻击，并提供一个可以实施安全和审计的单一扼制点。大多数常见的防火墙运行于OSI-Stack的第三层，也就是网络层。这些防火墙根据预先定义的系列规则过滤传入的数据包，并检查数据包是否符合这些规则。这些规则依赖于数据包标头可用的信息，如协议号、源和目的IP地址。另一种类型的防火墙是所谓的代理服务器（如SYNPROXY）。这些服务器在访问单个服务之前需要进行身份验证。如果验证成功，代理就会在服务器和客户端之间转发数据包。

B.软件定义网络(SDN)

SDN承接了网络中不断增加的参与者所带来的挑战，以及直接相关的资源需求增长所带来的成本指数上升。SDN的目标是实现更大的可扩展性、灵活性、自动化和独立于硬件制造商，以降低采购和运营成本。 SDN依赖于四个基本原则：

控制平面和数据平面的分离，将交换过程分为控制平面，利用路由算法决定数据包转发，用数据平面，从技术上处理数据包。SDN允许从外部影响转发过程与交换机通信，允许交换机在运行时改变其行为，而无需更换硬件组件。

中央控制实例称为控制器，可以实现网络的配置和管理。出于可用性或负载分布的原因，可以将其部署为物理或虚拟副本。交换机的行为可以通过软件来改变，可以从不同制造商的算法或其他应用程序中进行安装，而不依赖于硬件生产商。此功能还允许应用程序在网络层之上操作，即在应用程序级别操作，而不用考虑交换机型号或操作系统。

SDN通过四个基本的API将传统上单独处理的领域整合在一起。南行API连接了控制层和数据层。OpenFlow（OF）是SDN中最流行的南向API开放协议。OpenFlow可以用来配置和评估网络设备（通常是交换机）的统计数据。西行API用于沟通不同域的不同控制层。北向API在应用层和控制层之间交换信息。东行API为非SDN组件提供了一个接触面。

C.网络功能虚拟化(NFV)

NFV是一种新的网络模式。在过去，这些功能通常部署在专有的专用硬件上，现在可以用运行在商品硬件上的软件解决方案来替代[3][4]。这类功能的典型例子是交换、路由、负载均衡和防火墙。功能的实现通常被称为虚拟化网络功能(VNF)，因为它通常部署在虚拟机(VM)内，以实现更高的灵活性和可扩展性。并非每个功能都适合转换为VNF。使用具有优化处理器或FPGA的多种资源仍然是有利于实时需求。VNF在一些方面取决于性能。首先，网络适配器限制了可用端口的数量和速度。其次，网卡与应用之间的I/O子系统会影响性能。另外，为应用提供的资源（如内存和中央处理单元（CPU））也会成为瓶颈。许多NFV解决方案通常与专门的操作系统(OS)或驱动程序一起执行，以尽量减少瓶颈。在软件中映射网络功能，将数据层和控制层分开，这是SDN的核心目标之一。

 

III.相关工作

我们提供了有关防护措施的SDN和SDN的安全工作的精简概述。我们进一步介绍了NFV部署、应用方面的工作，以及激励我们进行研究的白皮书。SDN创造了 “一个非常吸引人的两难局面”[5]–它既为安全执行提供了广泛的好处，同时也带来了新的安全挑战。研究表明，不同的攻击不仅会影响目标组件的功能，还会影响SDN协议栈各层和接口的可用性和保密性。Scott-Hayward等人[6]对这些安全挑战进行了详细的分析，并按照受影响的SDN层/接口进行了分类。

除了传统的拒绝服务(DoS)攻击外，情报集中化和垂直化分裂为三大主要功能层，扩大了攻击面，并激发了各层的新技术。应用层DoS攻击直接针对应用程序，消耗所有分配给它的资源，并造成DoS。控制层DoS攻击可以通过针对其任何一个组件而产生，（例如，强迫不同的应用程序产生许多冲突的流转规则可能会导致控制器进入不可预测的状态）。在基础设施层DoS攻击中，利用了OF交换机和南向应用编程接口（API）的瓶颈。此外，生成的假流量会填满流量表，并防止了正常网络流量的规则被存储[7]。SDN提供了重新审视旧的安全概念和引入新技术作为SDN特性的机会[5]，用以增强网络弹性。全网知识有利于安全策略的验证，并能快速识别和解决任何冲突[8]。因此，可以建立和维护一致的安全政策。此外，SDN支持基于软件的流量分析，这为创新思路打开了大门，Chi等人[9]就如何将Snort IDS集成到基于SDN的网络中提出了不同的概念。

Barbette等[10]以及Gallemnueller等[11]对各种NFV开发套件和框架进行了详细的比较，包括最近提出的XDP框架[12]。在软件实现的网络功能的性能评估背景下，[3]提供了大量的最佳实践和注意事项。Lorenz等人[13]的调查中提出了与SDN和NFV用例相关的详细网络安全调查，Farris等人对物联网背景下新兴的SDN和NFV安全机制进行了广泛的概述[14]。

除了引入动态SSFC的可能性之外，SDN还允许用流量和应用感知来增强它们[15]。在DDoS弹性方面，许多解决方案都依赖于SDN和NFV。多位作者讨论了多个开放课题，包括：1.规则异常[16]；2.智能定位[17]；3.有效供给[18]。

安全功能链（SFCing）是这项工作的重要组成部分，对复杂的NFV安全框架至关重要。这项工作的第一个灵感来自于云安全联盟（CSA）的由Milenkoski等人[19]撰写的论文“安全立场文件：网络功能虚拟化”，其提出了六个NFV安全挑战。1.管理程序依赖性；2.弹性网络边界；3.动态工作负载；4.服务插入；5.有状态与无状态检查；6.可用资源的可扩展性。作者详细介绍了一个NFV安全框架的企业级架构，它可以减少部署和管理资源，以及根据传入的攻击调整其安全设备的SSFC指令。这项工作激励了我们的努力。

 

IV.安全功能链排序的影响

我们认为，SSFC的安全功能次序会影响SSFC的性能。在本节中，我们将评估安全功能和不同次序的SSFC，以证实我们的主张。首先，我们介绍了所使用的评估环境。然后，我们对独立部署中的三种不同安全功能的性能进行了测量。测量的安全功能是防火墙、DPS和IDPS。然后，我们将这些安全功能放在具有两个服务功能的SSFC中，并改变其顺序。最后，我们讨论了结果和结论，即我们必须在以下几节中考虑重新排序框架和决策。

A.评价环境

为了评估安全功能的性能，我们设计了一个试验台（见图2），它可以使用单一功能和复合SSFC(具有可修改的功能顺序和不同的服务器应用程序)来合并良性和恶意工作负载。

1）硬件组件。我们共使用6台物理服务器。这些服务器扮演的角色有：1.客户端和攻击者；2.应用服务器（被保护的应用程序）；3.DDoS防护系统（DPS）；4.防火墙；5.入侵检测和预防系统（IDPS）；6.SDN、实验和功能链控制器。对于所有的服务器，我们都使用四核（8线程）Intel Xeon E3-1230 V2 CPU，主频为3.30 GHz，配备16 GB内存。客户机与攻击机是为两个角色服务的，因此，也为每个角色使用一个链接。两台标准的非可编程1 GBit/s HPE交换机为后台和控制器网络提供连接，HPE 5130 24G 4SFP+ EI SDN交换机贯穿网络以提供实验数据。交换机提供了足够的背板交换容量，以确保这种设置不会成为瓶颈。

2）软件组件：

1.流量生成器（良性）：在客户端和攻击者服务器的第一个10gbit/s接口上，我们生成良性的超文本传输协议（HTTP）流量。为此，我们使用HTTP负载生成器[20]。

2.流量生成器（恶意）：我们使用客户端和攻击者服务器的第二个10 GBit/s接口来创建恶意数据包。我们使用Cisco的Trex生成器创建SYN、用户数据报协议（UDP）和IDS泛洪。对于选定的攻击，我们只使用无状态模式。为了生成HTTP泛洪，我们使用了BoNeSi—一个僵尸网络模拟器。

3.IDPS：IDPS主机运行的是2.9.7版本的Snort IDPS。Snort是Cisco开发的一个流行的开源IDPS，也是Cisco商业IDPS解决方案的基础。

4.防火墙：和IDPS一样，防火墙使用一个接口来处理传入流量，一个接口来处理传出流量。我们使用Linux网桥将两个接口互连，而Netfilter/iptables规则完成数据包过滤。

5.DPS：作为DPS，我们使用的是修改版的TCP握手远程建立，和使用SDN的动态重路由（THREADS）[21]。THREADS是一个针对SYN泛洪攻击的DPS VNF。它处理SYN请求，只有成功的请求才会与服务器建立连接，并触发SDN重新配置。因此，它抵消了SYNPROXY和SYN cookies的许多缺点。

6.受保护的服务：目标服务器运行TeaStore，一个模拟基本在线商店的微服务参考和测试应用程序[22]。

7.SDN控制器：我们使用Ryu作为SDN控制器。ryu.app.ofctl_rest模块为部署流量提供了一个基于REST的接口。

3）监控和指标收集：试验台测量并记录来自不同来源的以下指标：

1.每个服务器在各种状态下的CPU使用情况：用户，iowait，softirq，系统。

2.已发送并成功的良性HTTP请求的总数。

互联网控制信息协议(ICMP)和TCP SYN的平均延迟以及发送方和接收方之间的数据包损失。Telegraf收集CPU使用情况的统计数据，并将其发送到实验控制器上运行的InfluxDB。我们使用Grafana将收集的数据可视化。HTTP流量生成器报告运行期间的总请求数和成功请求数。ping命令允许测量发送方和接收方之间的延迟和丢包的情况。我们使用hping3来测量SYN延迟和丢包。对于ICMP和SYN延迟和丢包，我们在时间t内运行强度x的攻击，并在这段时间内ping和建立TCP连接。

B.单一安全功能性能

在评估SSFC指令对性能的影响之前，有必要建立一个基线，确定服务主机可以达到的实际的最高性能。图3可以直观地看到，服务是线性扩展的，从每秒16000个请求开始，成功的请求数就会停滞。之后吞吐量甚至会略有下降，这可能是由于队列、交换和背景切换的影响。此时，对于Direct Chain（两台服务器直接连接到同一个交换机上），目标服务已经达到了极限。表IIa中的第一行数据显示了非常低的延迟和无丢包。这些结果可作为评估设备如何影响延迟和数据丢失的基线。

我们对现有的每个安全功能重复了相同的实验，图3显示了这些安全功能的表现是不同的。防火墙严格遵循Direct Chain的结果。DPS和IDPS都只能跟随直接连接，最高可达3000个请求/秒，然后停滞不前甚至失去性能。

当断言表IIa的进一步指标时，我们意识到，防火墙和IDPS增加了ICMP响应。这些结果和进一步的实验使我们得出这样的假设：这种效应根源在于数据包必须经过的必要交换机的数量。 在这里，DPS通过一个额外的交换机进行连接，而防火墙和IDPS则连接到链中更高层的交换机，从而产生额外的跳数。对于SYN响应，唯一的异常值是防火墙，从而减少这个时间。无论是ICMP还是SYN数据包，没有任何配置会造成丢包。

C.安全服务功能链性能

在评估了单一的安全功能之后，我们现在继续进行安全功能的组合。我们创建了模拟攻击，并将每个攻击的安全功能组合起来，并切换它们的次序以进行比较。

1）HTTP泛洪：第一个基准是HTTP泛洪攻击。这种攻击的目的是通过高频率地发出HTTP请求或通过有针对性的请求造成高计算负荷来消耗服务资源。防火墙是防御安全功能，阻止来自恶意源的HTTP请求。我们以每秒1000个请求到每秒14000个请求的步骤来扩展HTTP洪水攻击，并在一分钟内每秒执行2000个良性HTTP请求，以保证良性工作负载的性能。我们在每秒5000请求的泛洪强度衡量指标–除了吞吐量外。我们比较以下两个SSFC指令。

IDPS→防火墙和防火墙→IDPS。

图4为吞吐量的结果。两个系统都能很好地处理良性工作负载和每秒1000请求的小攻击负载。在较高的攻击负载水平下，IDPS→防火墙SSFC的成功良性请求数会下降，从10000次请求开始，成功请求数仅略高于20000次。同时，防火墙→IDPS SSFC几乎不受攻击负载的影响，并保持在可达到的最大水平附近，并始终显著高于其他SSFC等级。表IIb显示了两个SSFC指令的进一步指标。考虑到这些数值，两个SSFC指令的执行情况相似。当考虑CPU负载测量值（未显示）时，我们看到IDP在两个SSFC命令下处于最大负载。但是，当防火墙不在前面时，一开始时，可以看到明显的过载。防火墙停留在很低的负载水平，并显示出有大量的储量。

2）SYN泛洪：作为第二个基准，我们执行了SYN 泛洪攻击。这种攻击的目的是为了耗尽服务器的缓冲区来进行半开放的TCP连接。DPS是防御安全功能。每次运行时，我们将SYN 泛洪强度提高500 Mbit/s，最高达到6500 Mbit/s。我们在一分钟内生成每秒2000个良性HTTP请求的负载，以评估SYN 泛洪期间的成功请求。我们在5000 MBit/s的攻击负载下，测量成功请求以外的其他指标。对于这次攻击，我们又对两个SSFC命令进行了基准测试：DPS→防火墙和防火墙→DPS。图5给出了两个SSFC命令的成功请求数，在2000 MBit/s之前保持最佳成功率。之后，以防火墙为首的SSFC命令慢慢下降。在3500 MBit/s时有一个非常急剧的下降，在6000 MBit/s时，它进一步下降到3688，然后保持在类似的水平。DPS→防火墙SSFC将以最高性能持续到3000 MBit/s。然后，它会持续下降，但仍明显高于反向链的性能。

表IIc显示了两个SSFC指令的进一步指标。与之前的攻击和组合相比，结果稍微有点不同。防火墙→DPS SSFC提供更快的ICMP响应，而DPS→防火墙SSFC产生更快的SYN响应。SYN响应的相对差异大于ICMP响应的相对差异。这两种配置都不会导致丢包。

防火墙→DPS SSFC在攻击过程中影响负载。用户和系统状态下的后台负载（例如，操作系统操作或文件系统日志记录）是由防火墙应用程序的实际负载强制执行的。 这个应用程序负载出现在softirq级别，CPU将100%的时间都花在了这里。当反转SSFC指令时，softirq状态下没有明显的负载显示，后台负载仍保持在用户和系统状态。因此，这个SSFC命令消除了防火墙上的所有负载。

3）入侵泛洪：入侵泛洪攻击旨在滥用服务内部的漏洞。我们使用包含与IDPS规则相匹配的明显特征的UDP数据包来创建泛洪，并以500 MBit/s的步长来执行高达5000 MBit/s的入侵泛洪。此外，我们还在1000 MBit/s的攻击负载下测量进一步的指标，并比较了与HTTP泛洪相同的SSFC命令。

图6显示了两个SSFC指令的成功请求数。在500MBit/s的泛洪强度下，防火墙→IDPS链下降到31732个成功请求。在1000MBit/s的泛洪强度下，这条链子进一步下降到7238个成功请求，并从此保持在类似或更低的水平。反向链的性能后面也会下降，从1000Mbit/s开始下降到43442Mbit/s。然后，它继续缓慢下降，最后与以防火墙为首的链的吞吐量一致，达到4000MBit/s。在500MBit/s攻击的开端到校准之间，IDPS→防火墙SSFC的性能优于其他链。

IDPS→Firewall SSFC的响应时间大约是其同类产品的两倍（见表IId）。它还引入了约三分之一的丢包率。这个结果令人惊讶，因为IDPS头链的较高吞吐量并没有提示这种行为。然而，获得更高的吞吐量的方法可能在于接受丢包。把防火墙放在第一位，会给两个系统造成用户和系统的负载。虽然防火墙没有处于极高负载的情况，但IDPS却处于超负载状态。改变SSFC指令的结果是带走了防火墙的负载和IDPS的系统负载，但却使IDPS严重超载。防火墙是链中的首位时，它大部分时间都处于softirq状态下。然而，当IDPS领先链时，只有在开始时出现一个小的峰值。

D.讨论

第IV章B节显示，即使在良性工作负载下，不同的安全功能的表现也有很大差异。虽然防火墙可以在不降低吞吐量的情况下保护一个服务，但DPS和IDPS在被保护的服务之前就已经达到了极限。另外，这两个系统（IDPS比DPS更多）显示，当负载进一步增加时，它们的性能会进一步下降。

第IV章C节证实了我们的假设，即SSFC指令对SSFC性能有着显著影响。当考虑吞吐量时，我们看到比较不同攻击时的不同行为。这些行为都有一个共同点–将防御攻击的安全功能放在第一位，会产生最成功的良性请求。在某些情况下，正确的SSFC指令会显著延长性能下降的负载水平，并减缓下降速度。不过，在某些时候，两种SSFC命令还是会趋于相似的结果。

我们证明了，SSFC指令对吞吐量、其他指标和CPU负载有着显著影响。对于选定的攻击组合，我们还发现，所有的攻击都不存在最佳的SSFC指令。而对于HTTP泛洪，防火墙在IDPS之前的表现是最好的，而在入侵泛洪中，反向链的表现则更胜一筹。一般来说，把专门用于防范当前攻击的安全功能放在首位，会产生最佳效果。因此，根据系统当前的攻击状态，我们需要不同的SSFC命令。这一发现证实了我们的想法，即动态SSFC重排序可以提高SSFC的性能。我们将在下面的章节中跟进这一概念的实现。

 

V.基于攻击感知的安全功能链重排序框架

在本节中，我们将提出一个攻击感知动态SSFC重排序框架的架构，并提供一个PoC实现。然后，我们将评估这个实现及其能力，并讨论其结果和进一步的挑战。

A.架构

攻击感知型SSFC重排序框架由多个组件组成，如图7所示。一个支持SDN的连接外部网络的通用网络和我们安全系统保护的服务。所有相关的安全功能也都连接到该网络。我们将所谓的安全功能包装器与安全功能一起部署，以收集有关它们及其攻击的指标，并将其报告给功能链接控制器（FCC）。FCC从包装物和其他来源收集数据。它决定是否有必要重排序SSFC，并在这种情况下将新的SSFC命令发送给SDN控制器，SDN控制器在支持SDN的网络中执行新的命令。

安全功能封装器是运行在安全功能主机上并与FCC通信的程序。它负责在FCC注册安全功能，在正常关机时删除安全功能，保持与FCC的连接，以便通过FCC对安全功能进行管理，最后，为安全功能提供接口，通过封装器向FCC报告检测到的攻击。首先，安全功能封装器会验证并加载其配置。如果一切加载正确，它就会向FCC注册，并接收一个用于进一步通信的令牌。在一个keep-alive循环中，安全功能封装器定期向FCC发送keep-alive消息，并接收更新的令牌。在其主循环中，它在执行验证后向FCC报告被监控的安全功能所注册的攻击（例如，1GBit/s接口上的机器无法报告强度为5GBit/s的有效攻击）。一旦关闭，它就会取消对FCC的注册。

功能链控制器运行在一个所有安全功能都可以到达的集中位置。一个显示攻击统计数据以及当前和标准配置的网页是FCC的一部分。此外，网页中还包含一个表格，可以根据可用的安全功能组手动更改路由配置。控制器需要处理来自封装器实例的请求，即注册、删除请求、攻击警报和保持活动状态请求，如前所示。FCC必须保存一份安全功能组及其各自攻击率的清单，以便反应性地计算新的最优路由配置。计算出新的路由配置后，FCC将其发送给SDN控制器，SDN控制器将其应用于交换机，进而应用于网络。在本节中，我们将使用一种简化的方法，将攻击最多的安全功能组放在前面。成功更改路由配置后，FCC将存储的当前配置更改为新的路由配置，并重置报告的攻击。

B.评价

1）实施与评价环境：完整的框架使用Python 3与四个非标准的Python库： Flask、 PyJWT,、requests和netifaces。一般来说，这个框架支持每一个提供具像状态传输(REST)API的SDN控制器来进行流量修改。为了确保SDN控制器没有副作用，我们自己完成了一个最小的SDN控制器。对于这个PoC评估和下面的评估，我们把我们的框架限制为只使用Open vSwitch。这个SDN控制器由两个Flask应用组成：实际的控制器和一个运行在Open vSwitch机器上的交换机封装器。我们使用类似于之前介绍的SSFC指令评估的试验台环境。但是，我们用Open vSwitch实例替换物理交换机。

2）人工重排序：首先，我们评估我们的系统是否能够正确地应用重排序决策。

1.实验说明。我们测试三种安全功能的所有六种可能的SSFC命令。因此，我们根据标准配置，自动测试网络中这些路由配置的过程。启动系统并注册安全功能后，客户端向服务器发送ICMP响应请求。接下来，我们开始在每个安全功能上使用tcpdump来记录流量。根据这些日志，我们构建了路径，数据包通过网络。

2.结果：结果表明，我们的框架正确地应用了默认配置的每一个排列组合。在重新排序时，可能会遍历比网络中更多的安全功能。这个问题是由于在流量通过系统时改变路由配置造成的。以下数据包经过所需的功能链。虽然理论上有丢包的可能，但新的路由配置被立即应用为重新传输。而且，虽然理论上是可能的，但没有任何攻击会完全跳过安全功能。

3）对模拟攻击的反应：接下来，我们分析一下系统如何对模拟攻击做出反应。

1.实验描述：本实验验证FCC是否根据安全功能报告的攻击正确改变路由配置。导致该框架开发的主要思想是动态地改变路由配置。如前所述，安全功能通过协同安全功能包装器实例向FCC报告检测到的攻击。我们模拟了对每个虚拟存贮器的攻击，来展示攻击报告的作用，以及根据攻击报告而改变的路由配置。模拟的安全功能发送攻击报告的概率是不断变化的。我们在FCC中配置了100次攻击的阈值。只有当攻击次数超过这个阈值时，FCC才会计算并在必要时应用新的路由配置。此外，我们还定义了一个比常规阈值大三倍的临界值，每十秒检查一次。

2.实验结果：图8展示了即将发生的攻击功能。路由配置的第一次修改发生在实验开始将近三分钟的时候。SSFC命令从DPS-Firewall-IDPS改为Firewall-IDPS-DPS。这一变化不可能源于常规检查，因为它发生在5分钟标志之前。进一步的改变证明了FCC的常规功能。路由配置在实验开始后约12分钟后生效。SSFC指令从防火墙-IDPS-DPS变为IDPS-防火墙DPS。在这里，可以看到，对于一个ping，数据包并没有遍历每一个安全功能，从而带来了潜在的安全风险。进一步的重新排序工作如愿以偿。如果报告的所有安全功能的攻击低于配置的阈值，FCC会将配置重置为标准配置。这种默认重置的方式允许用户选择最适合系统平均攻击的默认配置。

4）讨论。

1.功能性：总而言之，所开发的框架正在按预期运作。在应用新的路由配置时，可能会出现一些如数据包丢失这样的小问题。路由的生成及其应用按预期进行。我们还证明了，该框架确实具有攻击感知能力，并根据安全功能报告的攻击成功改变网络的路由配置。在攻击消退后，框架再切换回默认配置。

2.重新配置期间的安全问题：在重新配置过程中，可能会出现三种不希望出现的情况：a.由于框架尚未安装所需的流量，数据包丢失；b.数据包不止一次遍历一个或多个安全功能；c.数据包没有遍历所有所需的安全功能。

3.第一个和第二个问题只涉及服务质量和体验质量。但是，第三个问题与安全有关。如果数据包可以跳过安全功能，单个恶意数据包就可以到达接收器。这个问题与泛洪攻击没有多大关系，但对于入侵来说，一个数据包可能就足以触发一个漏洞，和造成严重的安全漏洞。

为了避免这个问题，我们提出了几个解决方案:①第二组安全功能。然后，重新配置将使用这第二组SSFC。 一旦所有的数据包都清除了首链中的安全功能，这些功能就成为下一次重新配置的备用功能。②通过添加具有人工延迟的短期流，确保在执行重排序时，没有数据包在功能内停留，来模拟数据包在安全功能内的停留过程。但是，这需要详细了解链内的所有安全功能，特别是它们的排列行为。③强制安全功能在执行重排序之前删除所有数据包。此解决方案修复了第二个和第三个问题，但会将受影响的数据包和其他数据包转移到第一个问题。④要使用互联网协议（IP）头中的选项字段。我们在选项中创建一个计数器字段，并在每次重新配置时将其递增。入站交换机有一个规则，修改传入数据包头，使其包含当前的计数器值，所有创建的流量都与当前的计数器相匹配。旧的流量在一段时间后失效。

根据不同的使用情况，安全系统架构有不同的最佳解决方案。我们还没有实施这些解决方案，但将来会这样做。对于PoC来说，所提出的实施方案已经足够了。

 

VI.安全功能链建模

在这里，我们将建立一个精确的模型。首先，我们来看看如何根据传入的流量来建立单一的安全功能模型。然后，我们利用这些知识，将多个安全功能模型组合成一个SSFC模型。

A.单一安全功能建模

1）流量模型：不同的安全功能在不同类型的流量下表现出不同的行为。因此，我们我们需要一个既考虑到良性流量又考虑到各种攻击类型的模型。为此，我们的到达率模型必须考虑流量的内容和构成。因此，我们将流量建模为不同的工作负载类。对于每个工作负载类别，我们记录数据包的速率和使用的带宽。我们对从外部网络到第一个安全功能的链路、安全功能之间的每个连接以及从最后一个安全功能到受保护系统的链路的流量构成进行建模。

2）安全功能建模：有了流量的模型，就可以对单个安全功能的行为进行建模。我们提出将架构性能模型应用于安全功能建模。与低级随机形式化相比，架构模型捕捉了语义，允许对安全功能进行简单的查看。我们将每个安全功能建模为一个软件组件。不过，我们也提供了简化的安全功能建模方法。需要从以下三个方面进行建模：①安全功能对通信量构成的影响;②安全功能的性能行为;③丢包等衍生效应。

根据安全设备的输入流量分布，可以推导出相应的输出流量。我们将输入/输出流量的分布定义为Pin/out(ti)，i∈[1，n]，为n种不同类型的流量。例如，对于一个丢弃所有流量类型k的数据包的安全功能，输出流量看起来如下：

目前的模型假设一个功能可以消除一个或多个流量类型的所有恶意流量。

对于性能建模，最精确的建模方案是使用软件组件的完整模型来模拟功能的性能行为。这类模型通常基于功能的源代码，或者通过大量的黑盒测试来提取。然而，往往既没有源代码，也没有资源来进行广泛的黑盒测试。尽管如此，即使在这种模型不可能实现的情况下，对于我们的安全功能，我们已经发现了两种资源需求生成的一般类型。第一种类型是每个单元(如帧、包、段、请求)产生的恒定需求。第二种类型使用不同的相关类型创建与单元规模相关的需求。在某些情况下，有些第三因素可以提高模型的准确性。这些因素并不直接与单个数据包或流量分布相关，而是与安全状态相关。例如排列行为、假阳性和假阴性、丢失率、过载行为和短期CPU频率伸缩。

B.安全服务功能链建模

在单个安全功能模型的基础上，可以对整个安全功能链进行建模。因此，我们通过把功能一个接一个，并把前一个功能的输出输入到下一个功能中，来建立这个链条的模型。当从输入流量开始时，流量是通过一个接一个的功能来产生的。图9显示了上述功能的流量发展。因此，我们使用一个没有第三因素的简化的模型。流量开始在所有流量类型上进行分布。在每个安全功能中，该功能都会删除一个或多个流量类别。因此，其他类别的份额增加了。这个过程在每个安全功能上都会重复，直到只剩下良性流量为止。这种组合可以在启动时知道链的构成，就可以建立一个完整的模型。然而，大多数时候，这种构成是未知的。不过，利用框架中的安全功能包装器和交换器的报告，还是可以对这种构成进行逆向工程（还原）。

 

VII.结论

在本文中，我们引入了攻击感知动态安全服务功能链重排序的概念。这个概念包含了改变SSFCs的顺序来优化它们，从而最有效地反击。起初，我们介绍了大意。主要组件是功能链控制器（FCC）。它收集信息来模拟安全系统的状态，使用这些信息来计算所需的配置，并执行SSFC命令。接下来，我们开发了一个针对单个安全功能和SSFC的评估环境。当对单个安全功能进行基准测试时，我们发现了不同类型的行为。对于每一个测试的组合，SSFC顺序对系统的性能有很大的影响。一般来说，把防御攻击功能放在第一位，会产生更好的性能。这种差别可以构成两个或更多的SSFC数量级。对于不同的攻击，我们发现SSFC指令是相互矛盾的。因此，不存在哪种SSFC顺序对每一次攻击都是最优的。

接下来，我们设计了一个框架，来执行攻击感知的动态SSFC重排序。所有的安全功能都驻留在一个支持SDN的网络中。一个与每个安全功能同处一地的安全功能封装器通过一个单独的管理网络向FCC报告这些功能受到的攻击。FCC为安全功能计算出所需的SSFC命令，并将其提交给SDN控制器，控制器通过在SDN交换机上创建必要的供应来执行该命令。我们开发了一个PoC实现，并表明该框架可以执行所有可能的SSFC命令。该框架成功地适应了所有的攻击，并且在攻击停止后，成功地恢复到默认配置。因此，这证明了预期的功能。在重新排序时出现了一个问题，数据包可能会丢失或通过一个功能两次。我们针对不同的用例提出了四种方案来解决这个问题。

我们对流量进行建模，将其分为流量类，其中良性流量和每一种攻击类型各自形成一个类。每一个安全功能都会根据流量构成以功能的形式影响流量。一个SSFC的模型由多个安全功能模型组成。从一个功能退出的流量会继续到下一个功能。因此，可以计算出总的资源需求。

动态SSFC重排序的工作远未完成。未来，我们计划对我们的建模进行评估，并用各种决策方法进行测试。我们还计划扩展该框架，允许对不同的流量类型进行不同的排序，并评估其对能源消耗的影响。

 

参考文献

[1] G. Vigna, W. Robertson, and D. Balzarotti, “Testing network-based intrusion detection signatures using mutant exploits,” in Proceedings of the 11th ACM conference on Computer and communications security – CCS 04, ACM. ACM Press, 2004, pp. 21–30.

[2] R. Oppliger, “Internet security: Firewalls and beyond,” Communications of the ACM, vol. 40, no. 5, pp. 92–102, May 1997.

[3] M. Chiosi, D. Clarke, P. Willis, A. Reid, J. Feger, M. Bugenhagen, W. Khan, M. Fargano, D. C. Cui, D. H. Deng, J. Benitez, U. Micheel, H. Damker, K. Ogaki, T. Matsuzaki, M. Fukui, K. Shimano, D. Delisle, Q. Loudier, C. Kolias, I. Guardini, E. Demaria, R. Minerva, A. Manzalini, D. Lopez, F. J. R. Salguero, F. Ruhl, and P. Sen, “Network functions virtualization (nfv), an introduction, benefifits, enablers, challenges & call for action,” SDN and OpenFlow World Congress, Darmstadt, Germany, 2012. [Online]. Available: http://portal.etsi.org/NFV/NFV White Paper.pdf

[4] P. Rygielski, “Flexible modeling of data center networks for capacity management,” Ph.D. dissertation, University of Wurzburg, Germany, ¨ Mar. 2017. [Online]. Available: https://opus.bibliothek.uni-wuerzburg. de/frontdoor/index/index/docId/14623

[5] Q. Yan and F. R. Yu, “Distributed denial of service attacks in softwaredefifined networking with cloud computing,” IEEE Communications Magazine, vol. 53, no. 4, pp. 52–59, Apr. 2015.

[6] S. Scott-Hayward, S. Natarajan, and S. Sezer, “A survey of security in software defifined networks,” IEEE Communications Surveys & Tutorials, vol. 18, no. 1, pp. 623–654, 2016.

[7] S. Sezer, S. Scott-Hayward, P. Chouhan, B. Fraser, D. Lake, J. Finnegan, N. Viljoen, M. Miller, and N. Rao, “Are we ready for SDN? implementation challenges for software-defifined networks,” IEEE Communications Magazine, vol. 51, no. 7, pp. 36–43, Jul. 2013.

[8] M. McBride, M. Cohn, S. Deshpande, M. Kaushik, M. Mathews, and S. Nathan, “Sdn security considerations in the data center,” Open Networking Foundation-ONF SOLUTION BRIEF, pp. 15–16, 2013.

[9] P.-W. Chi, C.-T. Kuo, H.-M. Ruan, S.-J. Chen, and C.-L. Lei, “An ami threat detection mechanism based on sdn networks,” in Eighth International Conference on Emerging Security Information, Systems and Technologies (SECUWARE 2014). IARIA, Nov. 2014. [Online]. Available: https://www.thinkmind.org/download.php?articleid= securware 2014 9 30 30142

[10] T. Barbette, C. Soldani, and L. Mathy, “Fast userspace packet processing,” in 2015 ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS), IEEE. IEEE, May 2015, pp. 5–16.

[11] S. Gallenmuller, P. Emmerich, F. Wohlfart, D. Raumer, and G. Carle, “Comparison of frameworks for high-performance packet IO,” in 2015 ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS), IEEE Computer Society. IEEE, May 2015, pp. 29–38.

[12] T. Høiland-Jørgensen, J. D. Brouer, D. Borkmann, J. Fastabend, T. Herbert, D. Ahern, and D. Miller, “The express data path: Fast pro grammable packet processing in the operating system kernel,” in Proceedings of the 14th International Conference on emerging Networking EXperiments and Technologies – CoNEXT ’18, ACM. ACM Press, 2018, pp. 54–66.

[13] C. Lorenz, D. Hock, J. Scherer, R. Durner, W. Kellerer, S. Gebert, N. Gray, T. Zinner, and P. Tran-Gia, “An SDN/NFV-enabled enterprise network architecture offering fifine-grained security policy enforcement,” IEEE Communications Magazine, vol. 55, no. 3, pp. 217–223, Mar. 2017.

[14] I. Farris, T. Taleb, Y. Khettab, and J. Song, “A survey on emerging SDN and NFV security mechanisms for IoT systems,” IEEE Communications Surveys & Tutorials, vol. 21, no. 1, pp. 812–837, 2019.

[15] G. Li, H. Zhou, G. Li, and B. Feng, “Application-aware and dynamic security function chaining for mobile networks,” J. Internet Serv. Inf. Secur., vol. 7, pp. 21–34, 2017.

[16] G. Li, H. Zhou, B. Feng, G. Li, H. Zhang, and T. Hu, “Rule anomaly-free mechanism of security function chaining in 5g,” IEEE Access, vol. 6, pp. 13 653–13 662, 2018.

[17] M. C. Luizelli, L. R. Bays, L. S. Buriol, M. P. Barcellos, and L. P. Gaspary, “Piecing together the NFV provisioning puzzle: Effificient placement and chaining of virtual network functions,” in 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM). IEEE, May 2015.

[18] A. Shameli-Sendi, Y. Jarraya, M. Pourzandi, and M. Cheriet, “Effificient provisioning of security service function chaining using network security defense patterns,” IEEE Transactions on Services Computing, vol. 12, no. 4, pp. 534–549, Jul. 2019.

[19] A. Milenkoski, B. Jaeger, K. Raina, M. Harris, S. Chaudhry, S. Chasiri, V. David, and W. Liu, “Security Position Paper: Network Function Virtualization,” Mar. 2016, published by Cloud Security Alliance (CSA) – Virtualization Working Group. [Online]. Available: https://cloudsecurityalliance.org/download/ security-position-paper-network-function-virtualization/

[20] J. von Kistowski, M. Deffner, and S. Kounev, “Run-time prediction of power consumption for component deployments,” in 2018 IEEE International Conference on Autonomic Computing (ICAC). IEEE, Sep. 2018.

[21] L. Ifflflander, S. Geißler, J. Walter, L. Beierlieb, and S. Kounev, “Ad- ¨ dressing Shortcomings of Existing DDoS Protection Software Using Software-Defifined Networking,” in Proceedings of the 9th Symposium on Software Performance 2018 (SSP’18), 11 2018.

[22] J. von Kistowski, S. Eismann, N. Schmitt, A. Bauer, J. Grohmann, and S. Kounev, “TeaStore: A Micro-Service Reference Application for Benchmarking, Modeling and Resource Management Research,” in Proceedings of the 26th IEEE International Symposium on the Modelling, Analysis, and Simulation of Computer and Telecommunication Systems, ser. MASCOTS ’18, Sep. 2018.