1、MNOS:拟态网络操作系统设计与实现 王禛鹏 扈红超 程国振 国家数字交换系统工程技术研究中心 摘 要： 控制层的漏洞利用攻击, 如恶意 APP、流表篡改等是软件定义网络 (software defined networking, SDN) 面临的主要威胁之一, 而传统基于漏洞修复技术的防御策略无法应对未知漏洞或后门.提出一种基于拟态防御思想的网络操作系统安全架构拟态网络操作系统 (mimic network operating system, MNOS) 保障 SDN 控制层安全.该架构采用异构冗余的网络操作系统 (network operating system, NOS) , 并在传统的
2、 SDN 数据层和控制层间增设了拟态层, 实现动态调度功能.首先拟态层动态选取若干 NOS 作为激活态并行提供服务, 然后根据各 NOS 的处理结果决定最终的有效响应返回底层交换机.实验评估表明:在增加有限的时延开销下, MNOS 可以有效降低 SDN 控制层被成功攻击的概率, 并具备良好的容错/容侵能力;在此基础上, 提出的选调策略和判决机制, 可以有效提升系统的异构度和判决的准确性, 进一步提升安全性能.关键词： 软件定义网络; 主动防御; 拟态安全防御; 动态异构冗余; 网络操作系统; 作者简介：扈红超 () 作者简介：王禛鹏, 作者简介：Cheng Guozhen, born in 1
3、986.PhD and research assistant. His main research interests include software defined networking and active defense.收稿日期：2017-06-11基金：国家自然科学基金项目 (61309020, 61602509) ;国家自然科学基金创新群体项目 (61521003) Design and Implementation of Mimic Network Operating SystemWang Zhenpeng Hu Hongchao Cheng Guozhen National
4、Digital Switching System Engineering Abstract： As a mission-critical network component in software defined networking (SDN) , SDN control plane is suffering from the vulnerabilities exploited to launch malicious attacks, such as malicious applications attack, modifying flow rule attack, and so on.In
5、 this paper, we design and implement mimic network operating system (MNOS) , an active defense architecture based on mimic security defense to deal with it.In addition to the SDN data plane and control plane, a mimic plane is introduced between them to manage and dynamically schedule heterogeneous S
6、DN controllers.First, MNOS dynamically selects mcontrollers to be active to provide network service in parallel according to a certain scheduling strategy, and then judges whether controllers are in benign conditions via comparing the m responses from the controllers, and decides a most trusted resp
7、onse to send to switches so that the minority of malicious controllers will be tolerated.Theoretical analysis and experimental results demonstrate that MNOS can reduce the successful attack probability and significantly improve network security, and these benefits come at only modest cost:the latenc
8、y is only about 9.47% lower.And simulation results prove that the scheduling strategy and decision fusion method proposed can increase system diversity and the accuracy of decisions respectively, which will enhance the security performance further.Keyword： software defined networking (SDN) ; active
9、defense; mimic security defense; dynamic heterogeneous redundancy; network operating system (NOS) ; Received： 2017-06-11软件定义网络 (software defined networking, SDN) 将传统数据平面和控制平面解耦, 在逻辑上实现了网络的集中控制, 使得网络配置、网络服务部署等都在网络操作系统 (network operating system, NOS, 也称 SDN 控制器) 之上实现, 有利于简化网络管理.然而, SDN 应用实际生产环境时仍面临严峻的
10、安全问题.首先, SDN 控制器集中管理着其覆盖网络的所有视图信息, 因此, 极易成为攻击的首选目标, 带来额外的安全风险.其次, SDN 的重要特性是开放性, 主要体现在可编程协议以及网络操作系统的开源社区, 而这种开放性极易导致未知的安全漏洞等问题, 例如已经曝出的 OpenDaylight 的 NetDump 漏洞、XML eXternal Entity (XXE) 漏洞、ONOS 的 DoS 漏洞, 以及 SDN 中的 Know Your Enemy (KYE) 攻击1等.最后, SDN 控制层呈现的单一、静态特性有利于攻击者对其进行探测和分析.作为 SDN 的核心组件, 控制器掌握着
11、整个网络的视图, 将上层策略转译为数据平面的转发规则, 一旦被攻击或劫持, 可导致信息泄漏, 甚至网络瘫痪.一般地, 针对 SDN 控制层的攻击主要出于 2 个目的:操纵网络流量或瘫痪网络.操纵网络流量的攻击, 一般利用控制器的漏洞, 如控制器缺少对上层 APP 权限管理的漏洞, 导致带毒 APP 下发恶意流表规则2-3, 以及控制器对 LLDP (link layer discovery protocol) 包缺少安全认证 (或者如 Floodlight, 虽然提供鉴别码认证, 但是鉴别码一直保持不变) 的漏洞造成的拓扑伪造攻击和中间人流表篡改攻击4等.瘫痪网络的攻击, 如存在恶意管理员5,
12、 使用一个简单的 exit 命令致使 Floodlight 宕机造成网络瘫痪, 或者通过发送探测报文推断控制器类型、消息处理逻辑和负载状态等信息和发动 DoS 攻击等6.总之, 利用控制器的漏洞发动攻击是控制器面临的主要威胁之一7.为应对上述安全问题, 已有大量研究给出了防御方法.有研究者提出了为控制器增设北向接口的分级调用8和南向接口的限制访问9以解决上述北向 APP 权限和南向探测等漏洞问题, 然而这类方法具有侵入性, 需修改控制器南北向接口 (甚至内核) , 并且这种“打补丁式”的防御手段无法根本上解决漏洞、后门等问题.因此, 有研究者从架构上提出了分布式控制器10-13和弹性控制平面1
13、4-15, 这些结构可以有效解决 SDN 控制层呈现的静态特性问题和单点失效造成的网络瘫痪等攻击问题, 然而目前主流的分布式架构中控制器仍是同构的, 同一漏洞16-17即可能导致所有实例陷入瘫痪, 另外, 同基于拜占庭容错 (Byzantine fault tolerance, BFT) 机制的控制平面一样18-19, 上述方法控制器间都不可避免地相互通信, 增大了攻击表面, 易导致攻击感染.本文将邬江兴院士提出的拟态安全防御思想20引入到 SDN 控制层, 提出了拟态网络操作系统 (mimic network operating system, MNOS) , 一种具有动态异构冗余特性21的
14、 SDN 安全架构, 该架构在数据层和控制层间增加拟态层, 动态调度若干异构控制器提供网络服务, 并对其并行输出进行一致性判决, 从中选取最可信的结果.本文的主要贡献有 3 个方面:1) 基于拟态防御思想, 设计了拟态网络操作系统架构, 并对 Floodlight, Ryu, ONOS 这 3 种主流开源 SDN 控制器进行开发, 实现了原型验证机 POC (proof of concept) .实验评估证明, 在增加一定的时延开销下, MNOS 可以有效保障 SDN控制层安全;2) 提出了一种基于异构度增益的选调策略, 通过增加选调前后系统的异构程度, 进一步提升 MNOS 的安全性能;3)
15、 优化 MNOS 的判决机制, 在考虑先验知识的情况下, 提升判决的准确性.1 相关工作SDN 在提供便于管理的控制层的同时, 也使其极易遭受攻击, 目前, 针对控制层安全防御的研究, 可以分为 2 个方向.1.1 改进型方案改进型安全控制器的防御思路是在现有开源控制器的基础上, 改进已有的安全服务或开发部署新的安全模块.目前, 已有诸多研究者对 NOX, Floodlight 等控制器进行了安全功能的拓展, 如 FortNOX22, SE-Floodlight23等.FortNOX 架构是 Porras 等人22针对 NOX 控制器设计的一种安全内核, 为其提供基于角色的数据源认证、状态表管
16、理、流表规则冲突分析、流表规则超时回调等安全功能, 提升 NOX 控制器在流规则冲突检测方面的安全性能.在 NOX 基础上, Porras 等人又对 Floodlight 进行了类似安全拓展, 设计了其安全增强版本 SE-Floodlight23, 增加了应用程序证书管理模块、权限管理等新的安全模块.通过附加安全机制或修补安全漏洞的方式, 使得研究者和开发人员比较被动, 很难在短时间内有效提升控制器的安全性, 并且这些“打补丁式”的改进型也无法从根本上解决控制层的安全漏洞问题.1.2 革新型方案针对 1.1 节的问题, 一些研究者提倡在 SDN 控制器的设计和开发之初, 便将安全性作为其核心问
17、题之一进行考虑, 从而突破已有控制器在系统架构、编程语言和预留接口等方面的限制, 开发出全新的、内嵌安全机制的 SDN 控制器.Shin 等人24提出了 Rosemary 架构, 为实现对上层 APP 的管理, 将其所有应用程序运行在一个封闭的应用程序区内, 实时监控各个应用程序的行为, 并通过检查各个应用程序的签名信息判定其是否为合法应用程序.然而, 由于Rosemary 系统对应用程序的签名方式是基于角色的签名机制, 并将整个应用程序作为一个整体对其进行签名, 因而无法较好地对应用程序各个模块的访问权限进行细粒度控制.Ferguson 等人25设计了内嵌安全机制 PANE 用于解决 SDN
18、中不可信用户访问请求之间的冲突问题.此外, 针对控制器的单点失效问题, 有研究者提出了分布式控制器, 如 HyperFlow10, 作为应用程序运行于安装 NOX的控制器之上, 采用物理分布但逻辑集中的设计, 因此可以在保证良好可拓展性的同时实现网络的集中管控, 并且被动同步网络状态视图, 赋予各个控制器决策权以降低数据层和控制层的时延.FlowVisor11则是在转发平面与控制平面之间引入了一个软件切片层实现控制消息切分.还有如文献18-19提出了基于拜占庭容错机制的控制层安全架构, 通过拜占庭的一致性协议, 检查点协议以及视图更换协议, 实现多控制器间网络状态视图的一致以及对控制层的容错/
19、容侵功能.在经典拜占庭模型下, 当系统 3f+1 个控制器时, 可以最多容忍 f 个错误;而改进的拜占庭, 可以只需 2f+1 个即可实现容忍26.除此之外, 在相关的防御手段上, 如由美国网络与信息技术研究与发展 (networking and information technology research and development, NITRD) 计划近年来提出的移动目标防御 (moving target defense, MTD) 模型27, 其主要通过构建动态冗余网络增加不确定性, 从而增加攻击难度.不同于拟态防御, MTD 每个周期只选取 1 个执行体提供服务.Fig.1 Th
20、e overview of MNOS 图 1 MNOS 整体架构 下载原图总的来说, 上述分布式架构虽然可以有效单点失效等问题, 但由于采用同构控制器, 且控制器间相互通信, 因此仍可能面临攻击感染等问题.2 MNOS 架构本文提出的拟态网络操作系统 (MNOS) 主要是将动态异构冗余模型引入 SDN 控制层中, 以实现控制层内生安全性.如图 1 所示为 MNOS 的整体框架, 其中虚线框内即为本文提出的拟态层部分, 下面对 MNOS 各模块分别进行介绍.2.1 拟态控制协议本文设计的拟态控制协议格式如图 2 所示:Fig.2 Mimic Protocol 图 2 拟态控制协议 下载原图拟态控
21、制协议运行在拟态层部分, 即图 1 中虚线框内 (虚线框内的虚线箭头表示拟态控制协议报文, 框外的实线箭头表示 OpenFlow 协议报文) .之所以设计自定义协议而不直接采用现有的 OpenFlow 协议, 是因为其不能满足本文的动态调度、判决 (需要对 NOS 进行标识) 等模块功能.拟态控制协议类型 (type) 目前主要分为 2 类:1) 控制报文, 主要是 NOS 与拟态层的交互, 如 NOS 注册消息和保活消息;2) 数据报文, 数据域 data 主要为 OpenFlow 等 SDN 南向协议报文.nos_id/app_id 字段主要是 NOS 及其上运行 APP 的标志, 在 N
22、OS 初始化注册时, 由拟态层分配, 便于拟态层管理.role 字段由拟态层标明 NOS 的角色, 主要为master 或 slave.xid 为会话标志, 便于判决时比对.2.2 南、北向代理层南、北向代理层主要都是拟态控制协议的封装、解封装, 即进入拟态层的报文封装为拟态控制协议, 反之则解封装出数据域 OpenFlow 报文.1) 南向代理层.之所以增加南向代理层 (实际上拟态核心层也可以完成其功能) , 主要是出于安全的考虑:拟态核心层功能复杂, 涉及状态信息等, 若直接对外呈现, 则易受攻击 (攻击面大) .而增加了功能实现较为简单的南向代理层后, 从底层交换机的角度上看, 南向代理
23、层即为 SDN 控制器, 从而实现拟态核心层对数据层的透明无感, 从而保障 MNOS 的系统安全.由上述分析, 南向代理层可以采用专用硬件如 NetFPGA 实现, 降低其遭受攻击的概率.2) 北向代理层.同南向代理层类似, 北向代理层主要面向 SDN 控制器及其上运行的 APP 应用, 因此从控制层的角度看, 北向代理层被视为底层交换机.由于本文采用异构的 SDN 控制器, 如 Floodlight, Ryu, ONOS, 具体实现不同, 但实现方法和逻辑类似.本文针对不同控制器类型开发 APP (模块) , 运行在SDN 控制器上实现北向代理功能, 其主要包含 2 个接口:与 SDN 控制
24、器 (以及APP) 间通信接口和与拟态核心层间通信接口.逻辑功能主要为 SDN 控制器消息的拦截、报文封装和虚假交换机实现.不同控制器“拦截”实现不同, 如 Ryu 控制器, 我们是通过重写 datapath 中的 send_msg 函数 (增加封装、解封装拟态控制协议部分) 实现的;而虚假交换机主要是为了完成底层交换机的“模拟”, 实现对控制器的透明无感.2.3 消息队列由于 MNOS 系统内部需要协调异构系统大量的通信, 目前主流的异构系统通信的方法有 2 种:1) RPC (远程协议调用) ;2) 消息队列.鉴于目前开源社区有较成熟的消息队列框架, 本文选择基于消息队列的异构子系统通信实
25、现.就目前而言, 主流的消息队列框架包括:RabbitMQ, ActiveMQ, ZeroMQ.RabbitMQ 是 AMQP 协议领先的一个实现, 它实现了代理 (Broker) 架构, 意味着消息在发送到客户端之前可以在中央节点上排队.此特性使得 RabbitMQ易于使用和部署, 适宜于很多场景如路由、负载均衡或消息持久化等.但是, 这使得它的可扩展性差, 速度较慢, 因为中央节点增加了延迟, 消息封装后也较大.ZeroMQ (ZMQ) 是一个非常轻量级的消息系统, 专门为高吞吐量/低延迟的场景开发, 在金融界应用广泛, 与 RabbitMQ 相比, ZMQ 支持许多高级消息场景.更重要的
26、是, 由于本文需要在多个控制器间进行调度, 同时涉及关闭某些控制器 (进行清洗) 后重新启动等操作, 而 ZMQ 对连续的断开连接、重连接等都很友好, 支持度高, 适合本文应用场景, 因此采用 ZMQ 实现.2.4 拟态核心层拟态核心层是 MNOS 功能核心部分, 主要负责 NOS 的管理、调度和判决等功能, 相应地, 其逻辑架构包含 NOS 管理器、选调器和判决器.2.4.1 NOS 管理器NOS 管理器主要负责 NOS 管理和 NOS 状态维护 2 个功能, 下面分别进行介绍:1) NOS 状态维护.NOS 管理器维护的控制器状态信息如图 3 中 NOS 类所示:Fig.3 Status
27、information of NOS 图 3 NOS 的状态信息 下载原图每个新加入的控制器都必须在初始化阶段向 NOS 管理器注册, 由管理器分配其唯一标识的 nos_id, 并确定控制器类型 nos_kind, 如 Floodlight, Ryu, ONOS等;app_id 和 app_kind 同控制器注册时类似, 这 2 个变量是为了维护该控制器上运行的 APP 信息;state 表示控制器的状态, 主要有激活态 (active) 、空闲态 (inactive) 、初始态 (initial) 和可疑态 (suspicious) , 状态 state 的变换过程如图 4 所示:Fig.4
28、 State transforming of NOS 图 4 NOS 的状态变换 下载原图其中变换 (1) 由 NOS 管理器负责, 主要工作是 NOS 初始化时的网络状态同步, 由 NOS 管理器负责;变换 (2) (3) 由选调器负责, 确定控制器的工作状态、角色, 这部分在 2.4.2 节介绍;变换 (4) (6) 由判决器负责, 主要发生在发现控制器可疑或者去可疑时, 这部分在 2.4.3 节介绍.2) NOS 管理.得益于 docker、NFV、云等虚拟化技术, 我们可以很方便地新增控制器 (镜像) 进行拓展, 如图 4 所示, 这里新增控制器也有可能是判决器发现可疑控制器, 最后决
29、定删除而重新初始化的控制器 (变换 (6) ) .但新增控制器不能立即投入使用, 因为涉及网络状态信息和 APP 状态等问题, 因此首先需要对其进行网络状态同步, 完成图 4 中变换 (1) .状态同步的步骤如图 5 所示:Fig.5 State synchronization 图 5 状态同步流程 下载原图其中 Floodlight 表示正常运行的控制器, ONOS 为新增待同步的控制器, switch 表示底层交换机 (实际应该分别为南、北向代理层, 这里是为描述简便) , core 表示拟态核心层.以路由 APP 为例, 具体步骤如下:(1) 时刻 t0拟态核心层收到 ONOS 的初始注
30、册消息, 新建该控制器的状态信息, 即 nos_id, nos_kind 等, 并将状态设置为“初始态”;(2) 拟态核心层向 Floodlight 发送获取状态的拟态控制协议报文, 同时将时刻t0以后收到的 switch 报文进行缓存而不再发往 Floodlight (如图 5 中圆柱体) ;(3) 收到 Floodlight 发送的时刻 t0的状态 (对于路由 APP, 状态信息即为路由表, Floodlight 的节点路由表状态信息存放于 TopologyInstance 中的pathcache 变量中) 后, 将其数据进行转换 (适用于 ONOS 的数据) 后发送给初始态的 ONOS
31、进行状态同步 (此时同步的是时刻 t0的状态) , 同时将缓存的报文发往 Floodlight 进行处理;(4) 在时刻 t2, Floodlight 正常处理报文, 并将缓存的报文和后续到达的报文依次发往 ONOS 进行处理;(5) 在 ONOS 完成状态同步 (处理完缓存报文后) 向拟态核心层确认后, 将其状态信息由“初始态”变换为“空闲态”, 等待选调模块的调用.需要说明的是, 若正常工作 (激活态或空闲态) 的控制器中有相同类型的控制器, 可直接用其进行同步, 无需进行数据转换的步骤.2.4.2 选调器选调器主要负责控制器的调度, 实现动态性, 即图 3 中的变换 (2) (3) .为
32、确保控制器的视图一致, 本文采用类似 OpenFlow 协议的 slave/master 方法实现选调, 不同的是 OpenFlow 协议中控制器集群只有一个 master, slave 只有在master 无法正常工作时才修改为 master (主要是应对单点失效等故障) , 而本文是将多个控制器同时设为 master.具体地, 若北向代理层收到的拟态控制协议报文中 role 字段为 master, 则将其交付控制器处理并正常下发消息;反之, 若为 slave, 则北向代理交付控制器处理后对其消息进行拦截而不下发.因此, 首先选调器根据选调策略选取出 m (m 一般为不小于 3 的奇数) 个
33、控制器后, 将其状态信息由空闲态设为激活态, 其余设为空闲态, 而后只需根据各控制器的状态, 在分发消息给各控制器时, 在 role 字段填入 slave/master (0/1) 即可:对于空闲态和初始态的控制器, 该字段设为 slave (初始化的控制器不具备正常工作的能力) ;激活态和可疑态的, 设为 master (由于可疑的控制器需要进一步考察, 因此需要其回复所有的消息请求, 便于判决器与其他控制器的响应进行比对, 确认其可信与否) .具体的选调策略将在第 3 节进行介绍.2.4.3 判决器判决器主要负责对多个控制器的响应报文进行判决, 判定最可靠的响应.判决机制在数据融合等领域有
34、很多研究, 以最简单的大数判决为例.当判决器收到 m 份响应中 (由 2.4.2 节可知, 只有 role 字段为 master 的控制器才会响应) 有大于或等于 (m+1) /2 份结果一致时, 则判定该结果为有效响应, 发往南向代理层 (最终到交换机) ;而对于其余和该结果不一致的控制器, 则判定为可疑, 将其状态由激活态改为可疑态 (图 3 中的变换 (4) ) , 然后着重对其进行考察, 若后期仍多次出现不一致的情况, 则向 NOS 管理器通告, 将其删除, 并重新初始化新的控制器实例 (图 3 中变换 (6) ) , 反之, 则重新设为空闲态 (去可疑, 图 3 中变换 (5) )
35、.上述判决机制是基于一个假设:多数控制器同时被攻击且攻击后输出一致的错误响应的概率极低.尤其是本文采用的异构控制器, 攻击者需要对多种控制器进行漏洞挖掘, 因此攻击者成功实施攻击的难度将会进一步增加16-17.具体的判决机制将在第 4 节进行介绍.3 选调策略第 2 节我们给出了选调器的工作原理, 在本节中, 我们详细介绍本文选调器的选调策略.多样性, 即异构配置, 是指对集合中冗余实例采用相同功能但软件或硬件不同的配置, 以增加系统的多样性16-17.通过引入多样性增强网络安全的方法已成为研究热点并广泛应用, 这种配置方法可以有效避免因同一种软件或硬件的漏洞、后门等造成共模故障, 使整个冗余
36、系统遭受毁灭性攻击16-17.因此, 本文提出一种基于异构度增益的选调策略, 即最大化 MNOS 系统中控制器异构度.用到的符号、变量如表 1 所示:Table 1 Definitions and Notations 表 1 变量及其含义 下载原表 我们的选调目标是最大化系统选调前后的异构度增益 DG (由于每次选调的控制器数量受限, 所以相当于激活态和空闲态控制器的动态迁移) , 异构度增益源于软硬件 2 个方面, 即 DG, DG 为最大化:DG, DG 的计算方法如式 (2) 所示, 且由于选调后切换的时延等因素, 所以需对迁移开销 (如迁移数量) 进行限制:显然, 若新选取的控制器软件
37、或硬件不同于当前激活态控制器集中的, 则其带来的异构度增益大于相同的情况, 因此, 式 (2) 中变量关系满足 1 2, 式 (2) 最优模型是典型的 NP 难问题:当前激活态控制器在选调后变为空闲态, 而空闲态被选取后变为激活态, 相当于是一种映射算法.因此, 本文给出如下启发式算法:每一轮选调都分为若干次迁移步骤, 每一步都先从当前激活态集中选取出最破坏系统异构度的控制器, 然后对其进行考察, 按照式 (1) (2) 的原则选取候选控制器.最破坏系统异构度的控制器即某类型控制器数量最多的控制器.例如, 某时刻激活态控制器集共有 4 种控制器, 分别是 3 台 Ryu, 一台 ONOS, 一
38、台 ODL 和 0 台 Floodlight, 那么在进行这一轮选调时, 我们优先选择其中的一台 Ryu 进行迁移 (移出激活态集) , 并且由式 (1) (2) 可知, 应当优先选择Floodlight 加入候选控制器集中, 以此类推.算法 1.选调算法.输入: , Ccur;输出:C nxt.假设控制器集共有|C|, 则找到 Cnxt的时间复杂度可近似为 , 所以复杂度最大为 O (|Ccur| (|C|-|Ccur|) ) O (|C|/4) .4 判决机制判决器的任务是从各激活态控制器的响应报文中比对, 抉择出最可信的响应回复给底层交换机, 并记录可疑控制器.主要涉及 2 个关键点:比
39、对内容和判决方法.在比对内容 (粒度) 方面, 显然, 若比对粒度为比特级, 则计算量过大, 因此, 本文根据 OpenFlow 消息的格式进行字段级比对, 着重考察 2 个关键字段:匹配 (match) 字段和行为 (action) 字段.如图 6 所示, 攻击者通过劫持 SDN控制器 (NOS 1) 篡改下发的流表规则, 将原合法的转发逻辑 match:in_port=2, actions:output=1, 篡改为 match:in_port=2, actions:output=3, 企图引导用户流量到攻击者事先部署的 Web 服务器上.此时, 判决器只需比对各控制器的match 字段和 action 字段, 从中选取较可靠的响应 (output=1) 下发给交换机.
