《软件定义安全》之四：什么是软件定义安全

第4章什么是软件定义安全

1.软件定义安全的含义

1.1 软件定义安全的提出

虚拟化、云计算、软件定义架构的出现，对安全体系提出了新的挑战。如果要跟上网络演进的步伐和业务快速创新的速度，安全体系应该朝以下方向演变。

𝟭 安全机制软件化

安全防护机制的部署应提升到软件层面的调度、下发和远程快速版本更新，更多地由软件完成自动分析、按需调度和动态部署。系统应该有能力根据多种因素，自适应地自动调度和部署安全防护机制，以提供快速响应能力和按需动态防护。

𝟮 接口开放，易扩展

提供开放接口，以支持快速的安全能力创新，便于扩展新的安全服务，对业务需求的变化作出快速响应。

𝟯 架构功能分离

安全功能不应被禁锢在一个个封闭的黑盒中，安全产品不应实现全功能栈。很多定制开发的功能可以独立于安全产品之外的组件形态，调用安全产品的应用接口，即可实现多种复杂的组合功能。

Gartner于2012年最先提出软件定义安全，通过分离安全数据平面与控制平面，将物理及虚拟的网络安全设备与其接入模式、部署方式、实现功能进行解耦，在底层将物理及虚拟的网络安全设备抽象为安全资源池，顶层统一通过软件编程的方式进行智能化、自动化的业务编排和管理，以完成相应的安全功能，从而实现灵活的安全防护机制，以应对软件定义数据中心和新型IT系统的安全防护需求。

1.2 软件定义安全的不同结构

➊ AMQ方案：SDN控制器上的安全应用

AMQ：Automated Malware Quarantine，恶意软件自动隔离

AMQ可在SDN控制器中增添相应的功能模块，并向用户接入端口或设备交换机端口动态、自动下发策略，实现恶意软件自动隔离。这种过程减少了对安全威胁的响应时间，极大地降低了网络接入管理难度。该方案只需要交换机支持控制器指令，可减少操作开销。AMQ主要是利用SDN架构控制平面的可编程性，通过应用开发对控制器的功能进行扩展。AMQ安全应用可在存在安全隐患的设备对网络造成影响前发现该设备的安全问题并进行隔离。AMQ一旦发现潜藏的安全威胁，就分析并自动下载补丁解决隐患，之后允许消除安全隐患的设备重新加入网络。
系统共包含两种安全防护，BotHunter用于实时检测发现网络中的Rootkit；威胁响应则用于在发现Rootkit攻击时利用控制器对感染主机进行隔离。
在实际应用时，用户单击了附带Rootkit的URL或附件，Rootkit嵌入用户系统后寻找网络中的其他主机，试图控制网络。BotHunter用端口扫描等手段监测被感染主机Rootkit产生的流，通过分析主机的通信对象可以让BotHunter确定主机中是否存在恶意软件。经过详细分析，BotHunter生成一个感染描述，给控制器下达隔离感染主机的命令。控制器将收到的命令转换成低层协议下发给数据平面，实现对感染主机的隔离。接着根据下发给数据平面的指令，所有的DNS和页面数据都重定向交付于Web Proxy Notifier，最后用户可以得到Web Proxy Notifier产生的一个URL来下载补丁，解决安全攻击问题。当主机安全问题得到解决时，就可以重新接入网络。

在这里插入图片描述

AMQ集中在控制器上实现，对于网络中其他设备几乎是透明的。这种设计不仅要实时监测流入的数据，而且只适用于静态数据流。AMQ可以只检测、隔离可疑数据流，这样可以增加灵活性，提高效率。

➋ FRESCO实现方案：SDN控制器上的安全内核

FRESCO系统的结构如下图所示。图中主要的扩展内容都部署在SDN的控制平面，维持了原有数据平面功能的单一性，避免给数据平面造成新的负担。图中的模块用于实现基本安全动作，利用FRESCO提供的脚本语言可以将这些基本模块进行自定义组织，形成一个完整的动作链，即为图中的实例。实例利用事件作为输入，触发相应模块的功能。事件可能由FRESCO系统中的模块产生，也可能由传统安全设备产生。当事件发生时，根据由脚本自定义的实例，几个模块组织在一起，形成一系列的安全动作，通过集成在网络控制器内的安全执行内核实现。FRESCO应用层的能力呈现都需要控制平面的功能扩展——安全执行内核提供支持。

在这里插入图片描述

以检测网络恶意扫描为例，下图描述了利用3个模块实现该功能的流程。当有TCP连接成功建立时触发第一个模块，检测发起连接的源IP地址是否在黑名单上，其结果作为第一个模块的输出，同时也作为第二个模块的输入。如果源IP地址在黑名单上，则第二个模块直接进行丢包处理，不再调用第三个模块。如果不在黑名单上，则对其进行检测，检测结果作为第二个模块的输出，同时作为第三个模块的输入。如果检测为网络恶意扫描，则第三个模块对数据流重定向，并进行深入分析处理；否则下发路由信息，发送至目的地址。

在这里插入图片描述

FRESCO采用了安全应用与网络控制器紧耦合的方式，需要在网络控制器上增加安全执行内核。另外，安全能力作为SDN应用部署在控制器上，也使安全应用过于依赖控制层环境，较难实现迁移复用；并且上层应用产生的安全策略可能与控制层上其他应用下发的策略冲突。

➌ 应用感知的数据平面方案：数据平面上的安全功能实现

应用感知的数据平面方案结构如下图，主要针对数据平面进行扩展。原有的网络在数据包与当前流表不匹配时，直接将数据包交由控制器处理（见图中的步骤①~⑤）。当请求数量增多时，控制平面容易成为瓶颈。该方案在交换机中新加入了应用表app-table，它最初由控制平面根据配置策略进行初始化，表中存放匹配的数据流应经过哪些应用处理，通过软件在应用表中写入编排好的安全应用，则可实现软件定义的安全防护。

在这里插入图片描述

此方案改变了数据平面的处理流程。当流与当前交换机中的流表项都不匹配时，先交由应用表app-table进行处理（⑥），app-table利用控制平面下发的指令与流进行匹配。如果匹配成功，则触发相应的处理策略（⑦）；如果匹配仍失败，才将数据包上传至控制平面处理（⑧）。通过这种方式，数据平面承担了部分处理功能，减轻了控制平面的压力。
理想状态下，当流表项删除时，生成流表项的应用模块应该获得这一信息。在实际实现中，首先产生一个只包括该流removal flag的包交付给app-table，产生这个流表项的应用就会进行相应处理。如果要删除的流表项与app-table中的所有应用都不匹配，则将流表项删除信息交由控制平面处理。
app-table可以通过组合实现更为复杂的功能，触发顺序可以根据需要进行排列，所有的app-table生成的执行命令组合在一起，由最后的app-table通过API下发处理（⑧）。app-table根据配置的策略修改目的地址可以使流首先经过防火墙，防火墙决定是否允许数据包通过，允许通过的数据包再经过均衡器发送给相应的服务器。这种实现方案实现了数据平面内部的扩展；无须再部署专门的应用，提高了系统效率；多种应用可以部署在同一台交换机上，避免了应用间通信造成的消耗；更为重要的是，很多数据包不需要交付控制平面处理，可以减小处理造成的延时。
但该方案也存在一定问题。对于首包，除了要与原有流表项进行匹配外，还要与新增的app-table匹配，会增加延时。另外可能导致恶意代码在交换机上运行。它在对网络状态信息处理方面没有解决DDoS攻击防御问题，而IDS、IPS等安全服务由于对每个数据包都要与app-table进行匹配，因此显然不适合部署在这个系统中。

➍ Avant-guard：数据平面上的安全功能实现

Avant-guard同样描述了一种利用数据平面扩展实现安全功能的方法，用户制定的安全策略通过软件注册到数据平面上，从而实现软件定义的安全能力。
Avant-guard主要是针对TCP连接。数据平面增加新的模块用于收集记录TCP连接的数据包速率、比特率、失败连接次数等信息，当上层指定了安全策略时，相应的策略注册到数据平面。当数据平面的数据包满足策略条件时，触发策略的指定动作进行处理，如上报至控制平面，或者直接按策略插入路由信息进行处理。Avant-guard虽然主要的扩展是在数据平面，但为了配合数据平面的功能，在控制平面也做了一定的扩展。例如，支持数据平面向控制平面报告连接失败、控制平面向数据平面注册所要检测数据包的条件等。
对于DDoS攻击，Avant-guard通过统计TCP连接数量能够丢弃那些恶意连接，在不增加硬件设备的条件下实现流清洗功能，避免大量的数据包进入交换机在检索不到相应流表项时上报给控制平面，造成控制平面拥塞瘫痪。除此之外，系统还利用从数据平面收集的统计信息实现了防止网络恶意扫描和抵抗网络非法入侵。实验结果显示，该系统对此能作出准确判断。
这种扩展方式的处理过程主要集中在数据平面，减少了控制平面和数据平面之间的数据交互，避免了控制平面和数据平面之间的接口成为限制系统能力的瓶颈。同时，处理过程集中在数据平面还节省了时间，加快了反应速率，应对DDoS这类攻击的反应也就更为敏捷有效。另外，在数据平面收集统计信息会对非恶意的数据包传送造成一定的延时开销。

1.3 软件定义安全的相关概念

安全自动化是指安全控制处理过程中没有人为参与。它主要应用于网络协议和网络配置，也应用于智能电网部署、机械制造等方面。
安全信息智能化是指通过对历史数据的整理分析，在系统中建立判断、识别等功能，形成立体化的识别保护模式。
移动目标防御(MTD)不仅依赖于安全系统自身的复杂性来保护目标，而且充分利用时间、空间及物理环境的复杂性，从而极大地增加了攻击难度。

软件定义安全利用架构的可编程性不仅能够实现安全策略的自动配置下发，还能够实现安全资源的自动化调度管理。另外，软件定义安全架构集中化的控制管理平台能够收集大量数据信息，这些信息可以用于对用户历史数据进行分析，继而进行安全防护，如建立安全知识库等。但与这些概念相比，软件定义安全更加侧重于以下方面。
➊ 提出新的安全架构。对于软件定义的安全架构，大多数理解都强调数据平面和控制平面解耦。
➋ 抽象底层安全设备。将独立的、存在差异的安全设备抽象成统一的安全资源，形成透明、统一的接入模式并提供给用户，有助于后期进行系统扩展，快速开发新的安全应用。
➌ 集中调度和重新编排传统安全功能。对各种安全功能进行逻辑编排，能实现安全运维的自动化、简捷化。

2.软件定义安全的特点

2.1 开放的生态环境

2.2 数据平面和控制平面分离

数据平面和控制平面分离，即所有对安全设备的控制指令和功能调用，都通过一个控制平台来完成，并由这个平台提供北向API，相应的厂商只需要在控制平面上开发应用即可。应用通过控制平台可将多个产品的功能集成，或组成服务链。
应用开发较为独立，也较轻量级，所以所需时间较短。数据平面与控制平面分离，安全设备专注于数据平面的处理，实现高效、稳定的处理引擎；而涉及协同和决策的安全机制，则放在控制平面。结合前述开放的应用接口，就能实现更为开放的生态系统。

2.3 可编程的安全能力

当安全控制集中在安全控制平台后，该平台就成为了安全操作系统，提供了各种基础应用接口，以实现不同的安全或网络功能。也就是说，整个安全解决方案是可编程的。
安全厂商和有二次开发能力的客户，可以利用这些北向接口，根据特定场景，开发能解决安全需求的应用。用户的运营能力将获得极大提高，可根据企业自身需求，快速对安全业务进行调整，提高自身的安全运营水平。

2.4 与网络环境松耦合

松，即网络控制和安全控制是独立的两个服务，从技术上简化了实现复杂度，从架构上分开了网络运维团队和安全运维团队的责权；
耦合，即安全控制平台可借助网络控制器的应用接口实现调度，且网络业务调整会及时通告安全应用。
与网络环境松耦合可使整体安全架构和决策逻辑保持稳定高效。当资产迁移时，只需要通过网络控制器调度流量，即可维持流量还是依次经过原先的安全设备；当业务变更时，也只需要通过网络控制，将流量通过新插入的安全设备，或跳过弃用的旧设备，就能组成新的服务链。

3.相关支撑技术

3.1 流信息收集和控制

在SDN环境中，安全控制平台可借助网络控制器，对全局范围内的网络流量进行收集。如OpenFlow SDN中，可向SDN控制器发送流量查询请求，SDN控制器收到请求后，将向相应交换机发送ofp_flow_stats_request请求，接着后者会将其所有流表上传，最后安全控制平台可收集若干或所有交换机的所有流表。

3.2 标准化应用接口

随着Web应用的不断发展，面向资源的应用接口逐渐在替代面向方法的Web服务接口，最典型的面向资源的应用接口是RESTful API。本质上说，RESTful是一种HTTP访问，RESTful请求中的URL是一个资源主体或资源集合，请求中的方法GET、POST、PUT和DELETE分别对应这些资源的获取、新建、更新和删除操作。

3.3 分布式消息通信

分布式计算分为实时的流式在线处理和非实时的批处理，它们都离不开节点间的通信，即分布式消息通信。
分布式消息通信机制支持多种业务模型。例如，面向消息的中间件AMQP（Advanced Message Queuing Protocol）统一了消息规范，支持发布/订阅、队列、事务及流数据，可实现基于内容的路由和远程过程调用，具有很大的灵活性，已成为消息中间件交互的标准协议。业界比较成熟的实现有RabbitMQ。此外，也有一些简化的分布式消息队列实现，如ZeroMQ。
利用分布式的消息通信机制，调用者无须关心调用模块的数量和位置，消息中间件可完成可靠路由、RPC调用和推送等功能。因此，它极大地简化了分布式系统的设计。

3.4 策略管理系统

❁ 策略表示

网络策略通常表现为一组规则的集合。其中，每条规则指定了一组匹配条件，以及满足该组匹配条件后所要执行的一系列操作。匹配条件和操作两者之中，较为复杂的部分是前者。匹配条件定义在一组不可分且类型不同的原子操作数上，每类操作数能够支持算术比较；比较结果之间可以进行逻辑操作，从而精确地定义匹配条件。
为了更好地支持对异构设备策略的管理，业界需要设计一套合适的机制对策略进行一致的描述。Datalog是一种基于逻辑的编程语言。该语言以往会在数据库领域中作为学术研究使用；相比于大家所知的SQL，Datalog具有更强的逻辑表达能力，且能更有效地表示递归运算。VMware NSX产品中的Nlog，以及OpenStack的Congress项目均基于Datalog构建策略描述语言。

❁ 策略分析

策略分析工具

策略分析的主要工作侧重于结合规则操作域的取值，对规则网包包头域所代表的多维正交空间之间的集合关系进行分析。分析工具所用的树状结构本身就反映了策略对多维正交空间某种特定的分割方式。
在交换设备策略分析领域，近年来突出的研究成果是包头空间分析工具HSA。该工具为了对交换设备的配置进行静态调试，用数学形式化的分析手段挖掘配置中难以发现的故障。例如，判断网络拓扑环路，检查网流分片隔离，以及调试新的网络协议等。HSA将网络工程领域的研究提升到数学形式化分析层面，是该领域的工作朝着引入科学研究手段方向的一个重要成果。HSA将网包包头中L比特长的多个域视为一个无差别的比特序列，每个比特序列可以视为一个L维正交空间，每个维度的取值范围为[0，1]。单个网包对应L维正交空间中的一个点，而单条规则对应L维正交空间中的一个超长方体。HSA抽象出两种数据类型（Wildcard和Headerspace）来分别表示单个L维正交空间和多个L维正交空间的集合；同时，HSA还设计了Headerspace的4种集合操作（交、并、差、补），并以此为基础实现规则所代表的L维正交空间上的分析。此外，HSA将交换设备的转发功能以转换函数的形式进行了建模，请求和响应方向上的网流经过交换设备时，等价于转换函数的原函数和反函数对网流所对应的Headerspace进行了一次在L维正交空间上的某种特定变换，如下图：

在这里插入图片描述

策略间的详细对比

策略拓扑结构分析。策略的拓扑结构显式地描绘出该策略所涉及的网络地址的层级结构，以及该策略所检测的网络流量的方向。利用基于区间长度优先的分层算法，策略中的所有网络地址被组织成树状结构。
策略拓扑分布统计。策略的拓扑结构给网络运维人员提供了一个较为粗粒度的全局概览，以便对策略进行定性的感知。策略的拓扑分布统计量化地显示了该策略所涉及的网络地址在源和目的地址段的二维正交空间中包含的规则数目。

❁ 策略部署

策略部署

部署在网络交换设备上的策略包括两类：转发策略和监控策略。根据功能需求的不同，交换设备的策略分配方式可以分为两类：
（1）转发策略与监控策略联合分配。交换设备上需要部署的策略不仅有转发策略，还有访问控制、策略路由及网络测量等，考虑到策略所面向的终端节点数量，最终部署策略的规模之大对交换设备有限的转发表项带来了严峻的挑战，使得控制器无法采用主动部署的方式预先配置最终规则。而被动部署的方式又会给控制器带来更大的处理压力，并且导致首包转发延时的增加。这类方式在部署策略时，会综合考虑上述因素，变更设备原有的转发行为。
（2）基于转发策略的监控策略分配。转发策略和监控策略的制定会由不同的运维人员来完成，而两类策略也往往会有不同的设计目标，难以实现联合方式的分配。这类方式都是在转发策略给定的情况下，寻找监控策略在全网范围内部署的一个优化解。因此，设备原有的转发行为在策略分配过程中会保持不变，这样就避免了转发策略与监控策略联合分配方式可能引发的流量绕行所带来的带宽开销。

3.5 服务编排与服务链

服务编排主要谈的是控制平面上的应用协同，其功能在底层实现就是将多个设备进行串接，形成服务链。至于同一个租户的多个设备的连接顺序，则需要考虑流量指令的一致性，即安全应用编排和网络服务链的对应关系。
在NFV场景中，流量编排的难度比虚拟化编排的更大。一个服务链通常都有入口节点和出口节点，服务链的组织顺序和服务节点的实际拓扑（即节点与网络设备端口相连的关系）无关。数据报文进入服务链后，就会按照服务链既定的顺序穿过各个服务节点。服务链的每一个节点都知道当前服务链的下一个服务节点在哪里，并将数据报文送达下一个服务节点处理。服务链的最后一个节点会将数据报文发送到最终目的地址。

3.6 数据平面加速

收包模型

在当前网包处理条件下，频繁的上下文切换所引入的开销已变得相当可观。因此，不少网络处理平台都转而采用轮询的收包方式以提升性能。

处理器与进程/线程

目前的处理器都是多核心NUMA结构。为了充分提高并行性，网络处理程序大都采用了多线程的处理模型。多线程程序之间的数据共享和交互更便利，且性能较高。但是多线程程序要特别注意内存分配和使用问题，推荐的做法是根据业务需求，将内存划分为线程独享和线程间共享两部分，并预先分配好。除此之外，不同于传统操作系统调度进程，网络处理程序调度的对象是网包。因此，处理线程最好和特定的CPU核心进行绑定，并且屏蔽操作系统的时钟中断，从而保证CPU处理资源的最大化利用。最后，在NUMA体系结构下，不同核心访问内存的延时并不相同。为了在有限的时钟周期内完成对网包的处理，系统设计应当将逻辑流程划分为流水的方式，使处理器对网包的操作能够在离其最近的内存上完成。

内存

内存访问是拉长网包处理延时的主要原因，因此编程时应尽量一次性将所需的内容读取到缓存中进行处理。对于系统频繁申请/释放的数据结构，如会话表项等，可充分利用硬件单元或引入固定大小的内存池进行管理。此外，在实际应用中应使用大页表，减少缺页中断。

缓存

由于系统对缓存的读写是按行操作的，不同核心对共享数据不同部分的操作可能并非主观上的并行操作。如果这些数据存储在同一个缓存行中，则CPU实际上仍然是串行执行的，这就引入了False Sharing。此外，频繁访问的数据结构还需要考虑根据缓存行的大小进行对齐。否则，即使读写的大小是一个缓存行大小，但数据实际分布在两个缓存行上，CPU在执行时也会产生两次读写缓存的操作。