哪个软件可以做明星视频网站,wordpress编辑器支持代码,给大家黄页推广网站,东莞做网站 9353第2章 SDN/NFV环境中的安全问题
1.架构安全
SDN强调了控制平面的集中化#xff0c;从架构上颠覆了原有的网络管理#xff0c;所以SDN的架构安全就是首先要解决的问题。例如#xff0c;SDN实现中网络控制器相关的安全问题。
1.1 SDN架构的安全综述
从网络安全的角度…第2章 SDN/NFV环境中的安全问题
1.架构安全
SDN强调了控制平面的集中化从架构上颠覆了原有的网络管理所以SDN的架构安全就是首先要解决的问题。例如SDN实现中网络控制器相关的安全问题。
1.1 SDN架构的安全综述
从网络安全的角度SDN带来了网络架构的革新也引入了新的安全威胁和挑战。从架构层面来看新引入的SDN控制器由于逻辑集中的特点自然易成为攻击的对象开放的API接口也使应用层的安全威胁将扩散到控制层进一步威胁到基础设施层承载的用户业务SDN控制层和基础设施层之间新引入的协议如OpenFlow协议及其实现需要经过长期的安全评测在基础设施层SDN交换机在控制器的控制下完成流转发SDN数据流也可能面临由南向协议、控制层相关的安全问题导致的威胁。
1.2 集中控制平面SDN引入的新问题
控制器承载着网络环境中的所有控制功能其安全性直接关系着网络服务的可用性、可靠性和数据安全性。攻击者一旦成功实施了对控制器的攻击将造成网络服务的大面积瘫痪影响控制器覆盖的整个网络范围。同时控制器具有全局视野它从各交换机收集了全局拓扑甚至全局流信息。 脆弱的SDN控制器的具体安全风险如下。
可通过流的重定向使流绕过安全策略所要求的安全机制从而使安全机制失效。如DNS查询被破坏使业务流无法建立只通过SDN控制器就可改变流转发路径将大量的数据流发往被攻击节点中间人攻击非安全的控制通道容易受到中间人攻击。流的完整性被破坏如插入恶意代码。
因此控制平面的安全是SDN安全首先要解决的问题。下面从针对控制器的主要威胁入手分析它们的威胁方式、影响及相应的解决对策。
攻击者利用控制器安全漏洞或南向协议如OpenFlow实施拒绝服务攻击
当数据包到达SDN交换机时交换机对包的处理流程如下图所示。当包不匹配所有流表中的所有流表项时交换机将包通过与控制器间的安全信道转发给控制器处理当匹配了任一条流表项时则检测流表项中的actions字段根据该字段中指定的操作动作对此包进行相应处理。这个处理流程使得通过数据平面对控制平面的控制器进行攻击成为可能。 #mermaid-svg-yhdguMdbasuagUDg {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-yhdguMdbasuagUDg .error-icon{fill:#552222;}#mermaid-svg-yhdguMdbasuagUDg .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-yhdguMdbasuagUDg .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-yhdguMdbasuagUDg .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-yhdguMdbasuagUDg .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-yhdguMdbasuagUDg .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-yhdguMdbasuagUDg .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-yhdguMdbasuagUDg .marker{fill:#333333;stroke:#333333;}#mermaid-svg-yhdguMdbasuagUDg .marker.cross{stroke:#333333;}#mermaid-svg-yhdguMdbasuagUDg svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-yhdguMdbasuagUDg .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-yhdguMdbasuagUDg .cluster-label text{fill:#333;}#mermaid-svg-yhdguMdbasuagUDg .cluster-label span{color:#333;}#mermaid-svg-yhdguMdbasuagUDg .label text,#mermaid-svg-yhdguMdbasuagUDg span{fill:#333;color:#333;}#mermaid-svg-yhdguMdbasuagUDg .node rect,#mermaid-svg-yhdguMdbasuagUDg .node circle,#mermaid-svg-yhdguMdbasuagUDg .node ellipse,#mermaid-svg-yhdguMdbasuagUDg .node polygon,#mermaid-svg-yhdguMdbasuagUDg .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-yhdguMdbasuagUDg .node .label{text-align:center;}#mermaid-svg-yhdguMdbasuagUDg .node.clickable{cursor:pointer;}#mermaid-svg-yhdguMdbasuagUDg .arrowheadPath{fill:#333333;}#mermaid-svg-yhdguMdbasuagUDg .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-yhdguMdbasuagUDg .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-yhdguMdbasuagUDg .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-yhdguMdbasuagUDg .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-yhdguMdbasuagUDg .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-yhdguMdbasuagUDg .cluster text{fill:#333;}#mermaid-svg-yhdguMdbasuagUDg .cluster span{color:#333;}#mermaid-svg-yhdguMdbasuagUDg div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-yhdguMdbasuagUDg :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 是 否 是 否 受到网络数据包 可选802.1d STP处理流程 解析片头域字段 匹配表0 应用操作 匹配表n 发送到控制器 至少有如下两种攻击方式。
攻击方式一攻击者通过攻击交换机让其将所有包转发给控制器处理从而使控制器受到拒绝服务攻击如下图 #mermaid-svg-i7O5756lFZw14uaD {font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}#mermaid-svg-i7O5756lFZw14uaD .error-icon{fill:#552222;}#mermaid-svg-i7O5756lFZw14uaD .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-i7O5756lFZw14uaD .edge-thickness-normal{stroke-width:2px;}#mermaid-svg-i7O5756lFZw14uaD .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-i7O5756lFZw14uaD .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-i7O5756lFZw14uaD .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-i7O5756lFZw14uaD .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-i7O5756lFZw14uaD .marker{fill:#333333;stroke:#333333;}#mermaid-svg-i7O5756lFZw14uaD .marker.cross{stroke:#333333;}#mermaid-svg-i7O5756lFZw14uaD svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-i7O5756lFZw14uaD .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-i7O5756lFZw14uaD .cluster-label text{fill:#333;}#mermaid-svg-i7O5756lFZw14uaD .cluster-label span{color:#333;}#mermaid-svg-i7O5756lFZw14uaD .label text,#mermaid-svg-i7O5756lFZw14uaD span{fill:#333;color:#333;}#mermaid-svg-i7O5756lFZw14uaD .node rect,#mermaid-svg-i7O5756lFZw14uaD .node circle,#mermaid-svg-i7O5756lFZw14uaD .node ellipse,#mermaid-svg-i7O5756lFZw14uaD .node polygon,#mermaid-svg-i7O5756lFZw14uaD .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-i7O5756lFZw14uaD .node .label{text-align:center;}#mermaid-svg-i7O5756lFZw14uaD .node.clickable{cursor:pointer;}#mermaid-svg-i7O5756lFZw14uaD .arrowheadPath{fill:#333333;}#mermaid-svg-i7O5756lFZw14uaD .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-i7O5756lFZw14uaD .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-i7O5756lFZw14uaD .edgeLabel{background-color:#e8e8e8;text-align:center;}#mermaid-svg-i7O5756lFZw14uaD .edgeLabel rect{opacity:0.5;background-color:#e8e8e8;fill:#e8e8e8;}#mermaid-svg-i7O5756lFZw14uaD .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-i7O5756lFZw14uaD .cluster text{fill:#333;}#mermaid-svg-i7O5756lFZw14uaD .cluster span{color:#333;}#mermaid-svg-i7O5756lFZw14uaD div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-i7O5756lFZw14uaD :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 向控制器发送大量PACKET_IN 新建流触发交换机发送PACKET_IN 流表项的Actions字段只是交换机将包封装成PACKET_IN 攻击者发送源目的地址随机的长数据包 设置交换机流表:actionsCONTROLLER 攻击控制器,下发错误的配置消息 攻击交换机,修改流表项 SDN交换机的OpenFlow协议的流表中每个表项包括3个域头域、计数器和操作。当操作域值为CONTROLLER时交换机需将数据包封装后通过类型为OFPT_PACKET_IN的消息转发给控制器。 根据这一工作机制攻击者可通过修改交换机流表中各表项的actions字段使交换机将所有数据包都转发给控制器从而导致控制器需处理大量的PACKET_IN消息。具体的攻击方法可以是攻击交换机直接修改流表项也可以是攻击控制器或伪造控制器身份向交换机下发配置指令修改actions字段。
攻击方式二根据OpenFlow协议当交换机接收到一个数据包时如果无法在流表中找到相应的转发端口交换机将通过PACKET_IN消息向控制器转发此包请求控制器下发相应转发流规则。因此攻击者可以伪造大量在交换机流表中不存在或无法处理的数据报文由交换机提交这些报文给控制器进行处理从而占用控制器资源造成拒绝服务攻击。从终端发起传统的TCP/SYN、UDP、ICMP洪泛攻击就可以完成这种攻击。
PACKET_IN消息消耗的控制器资源包括控制器查找、计算流路径所需的计算资源以及控制器南向接口的带宽资源。 本质上这类攻击方式是一种OpenFlow洪泛攻击因此传统的防御思路仍可采用。 防御的第一步是流或包信息的收集。SDN是面向流的网络因此较易实现基于流的检测和防御。通常采用的方法是通过控制器周期性地读取交换机的流表信息。根据OpenFlow协议控制器可通过OFPST_FLOW或OFPST_AGGREGATE消息向交换机询问一条、多条或全部流表项的流信息。从流表中直接可读取的流信息包括流的头域和计数器头域包括流的源和目的地址、协议等计数器可提供整个流表、一条流、一个端口和一个队列的较简单的统计信息。 流统计信息的收集常由控制器定期向交换机查询异常检测也常由控制器上的应用完成。传统的异常检测方法也被应用于SDN控制器的抗DDoS攻击检测。 主要的防护机制包括两种思路流量控制提供主动遏制手段。多控制器结构中可采用L7应用层负载均衡提高控制器在DDoS攻击下的生存性。
非法接入控制器
攻击者可以通过传统的网络监听、蠕虫、注入恶意程序等方式窃取SDN网络管理员的账号和密码伪造合法身份登录控制器并进行非法操作也可以利用SDN控制器自身的软硬件漏洞通过恶意应用进行渗透攻击提升操作权限获取对控制器的非授权操作。 以下措施有助于应对上述安全威胁。 1建立安全通道执行严格的身份认证。强制通过加密信道访问控制器有助于防止窃听控制器管理员的账号和口令。 2应用软件的安全测试、应用隔离和权限管理。
1.3 开放API不安全的应用接口
不安全的南/北向接口可能使得整个网络的安全受到威胁
网络行为被修改。如果恶意攻击者通过注入等手段使某应用发送的请求的参数与业务逻辑期望不符可使该应用的网络行为被篡改从而下发恶意指令。网络通信被非法监听。如果接口是未加密的攻击者就能监听整个调用过程从而使敏感信息被窃取。截获并修改数据包。攻击者可以采用中间人攻击重放或修改后重发请求达到伪造请求的目的。引发DDoS攻击。如果应用接口没有检查机制容易被攻击者反复调用向网络设备下发大量无用的流表可能影响数据平面效率或者攻击者将大量流量引到某些性能较弱的节点造成该节点被拒绝服务。
可能的解决方法如下。
设置API权限。控制层可对不同应用的API调用设置不同的权限以防一般权限的应用程序调用高级别的接口命令。策略检查。控制器可对通过API接口下发的应用层策略进行规则检查检测下发的规则是否有冲突是否符合安全策略、业务逻辑和行为特征检测规则下发后是否可能导致网络发生异常。信任评级。对应用进行信任评级根据应用层参数及应用的历史行为计算应用的信任度每个应用对每个控制器的信任级别可以不同各个控制器可以为不同级别的应用设置一个信任阈值当应用的平均信任值大于该值时就执行相应权限的命令否则不执行。中间层检查。在控制层和基础设施层间定义一个中间层用来检查来自控制层的信息并下发给网络设备。
1.4 数据平面传统数据流的安全问题
数据平面的主要攻击对象是数据平面的关键节点-SDN交换机可通过消耗流表资源对SDN交换机实施拒绝服务攻击。具体方式包括直接入侵交换机用虚假信息填满流表或通过向控制器发送大量数据包致使控制器为每个数据包建立一条转发流规则从而导致流表溢出。 应对这种拒绝服务攻击的方法如下
采用流控、事件过滤、拥塞丢包和超时调整等方法限制流量。流聚合。在控制器上将多条具有相同动作的流聚合成一条流从而通过降低流操作的粒度降低控制器的负载减小流表溢出的概率。在交换机和控制器上实施攻击监测。在控制器上实施严格的访问控制策略。
与传统网络相比SDN交换机有更多的控制层交互控制接口的功能更强大。因此除直接渗透有脆弱性的交换机外攻击者通过部署非法应用、入侵控制器都可实现对交换机流表的非法操作完成以下对用户数据流的攻击。 改变流转发路径实施中间人攻击进行信息窃取和篡改。 修改对数据包的操作动作改变交换机在转发流时对数据包的操作动作。例如丢弃数据包实施拒绝服务攻击非法复制数据包并通过另外的路径转发给攻击者窃取信息或实施中间人攻击。 设定非法信息的转发路径从而占用某用户的转发端口等网络资源实施拒绝服务攻击或通过注入精心设计的数据包进行会话劫持攻击。
SDN可对网络基础设施层的软件定义能力实现MTDMoving Target Defense从而变换数据平面的攻击面增加攻击成本和难度利用SDN可实现从物理层到应用层的全协议栈的MTD通过SDN提供数据的多路径传送可提供L4负载均衡在网络不同路径间分割数据包从而提高网络在DDoS攻击下的生存能力并提高窃听难度也可利用多路径提供不同等级的安全信道。 SDN还可为数据平面提供类似于传统面向连接网络的信令功能。以下展示了可信通道应用提供的安全策略是如何控制敏感数据在SDN网络中安全传送的。 要发送敏感数据的一方M1首先发送一个信令包到网络中这个包中包含了敏感数据在网络中传输时的安全策略如哪条链路或交换机是恶意的尽量避开。 这条消息会通过PACKET_IN消息被控制器获取并且这个包中有关于M1和控制器之间的认证信息使得双方互相建立信任关系。 控制器把策略发送给TPATrusted Path Application。 TPA会根据这个安全策略来指定合适的可信通道并且TPA会下发OpenFlow命令给底层交换机如生成流表项来建立敏感数据的可信通道。 M1会收到来自控制器发来的确认信息告诉M1敏感数据的可信通道已经建好。 至此M1就可以传送敏感数据给M2了。 利用类似思想还可以设计更多的“信令包”在数据通信前提交给控制层以完成其他功能。例如在“信令包”中提交用户信息从而为流提供认证功能网络只为经过授权的用户建立流。
2.协议安全
2.1 南向协议介绍
南向协议主要侧重于南向接口上的数据转发、网络配置、数据平面信息收集等功能。
OpenFlow协议
OpenFlow是SDN的标志性技术他体现了SDN的核心思想控制与转发分离。它通过流表控制技术支持用户对数据流行为进行控制。OpenFlow交换机根据流表来转发数据包代表数据转发平面控制器通过全网络视图来实现管控功能其控制逻辑表示控制平面。 OpenFlow协议的发展演进一直都围绕着两个方面一方面是控制平面的增强让系统功能更丰富、更灵活另一方面是转发层面的增强可以匹配更多的关键字执行更多的动作 OpenFlow协议支持3类消息类型由控制器发起的Controller-to-Switch消息、用于交换机向控制器通知状态变化等事件的Asynchronous消息和主要用于维护连接的Symmetric消息。控制器和交换机之间通过这3类消息进行连接建立、流表下发和信息交换实现对网络中所有OpenFlow交换机的控制。 OpenFlow的流表由很多流表项组成每个流表项就是一个转发规则。每一个流表项有3部分内容 头域是一个十元组除了传统的七元组之外增加了交换端口、以太网类型、VLAN ID并且还可以进行扩展 计数器主要用来记录流、端口相关的统计数据 操作则是转发、丢弃等对流的操作。
ForCES - Forwarding and Control Element Separation
ForCES即转发与控制单元分离是IETF路由领域的ForCES工作组的内容致力于开放可编程的IP路由器体系结构和协议其基本思想是把IP路由器分成转发组件FEForwarding Element和控制组件CEControl Element。 ForCES将路由器的控制单元从路由器体系结构中分离出去成为控制平面路由器原来的体系结构只保留转发单元的功能从而将转发和控制功能在物理上分离开来。ForCES协议则用于路由器控制单元和转发单元之间的通信与交互CE通过ForCES协议来完成对FE的控制和管理操作。 如下图所示一个ForCES的网络单元NE可以包含多个CE和多个FE的实例一个CE可以控制多个FE同时一个FE也可以由多个CE控制。FE包含一个或多个物理介质接口Fi/f该接口用来接收从该网络单元外部发来的报文或将报文传输到其他的网络单元这些FE接口的集合就是NE的外部接口。除了这些外部接口网络单元内部还有一些内部互联用于CE和FE之间通信及FE之间转发报文的接口。在网络单元外部还有两个辅助实体CE管理者和FE管理者它们用来在前关联阶段对相应的CE和FE进行配置。为了方便起见在ForCES体系结构的组成成分之间使用参考点来标记其逻辑交互参考点分别为Fc、Ff、Fr、Fi、Fl、Fi/f和Fp。完成CE与FE之间交互的ForCES协议是在Fp参考点上定义的。 PCEP - Path Computation Element Protocol
PCEP是由IETF的PCE工作组于2006年为MPLS网络域间流量工程即显式路由等应用提出的以支持集中化的路径计算。PCE工作组的体系结构基于两个核心功能模块PCCPath Computation Client部署在路由器等数据平面节点上在控制平面上则部署PCE服务器实现路径计算单元PCEPath Computation Element负责计算来自PCC的路径计算请求。PCEP则是为PCE和PCC之间通信而提出的相关通信协议。 为了支持集中的路径计算控制平面上还需要有TEDTrafficEngineering Database功能模块主要负责收集网络拓扑和当前的带宽、资源利用率等链路信息但PCEP中并不包括这些信息的交互而是由TED通过路由协议或由网管的其他机制获取。PCE从TED获取链路和网络参数计算出一条满足约束条件的最佳路径。 PCEP协议描述的一次会话主要分为以下4个阶段。 ① 会话的初始阶段在PCE和PCC间建立TCP连接。在此初始阶段包括的消息类型为用于PCE和PCC或者PCE和PCE之间的消息开启的Open消息以及用于保持维护该次会话的Keepalive消息。 ② 路径计算的请求阶段发送PCE和PCC之间或PCE和PCE之间进行路由计算的请求消息即发送包括请求路由的详细信息、路由的约束条件以及其他特殊的约束条件等信息的请求PCReq。 ③ 路径计算的响应阶段PCE根据TED链路信息结合约束条件进行路径计算并发送包括详细路由、节点信息、带宽等信息的响应消息。 ④ 会话的关闭阶段用于处理Close结束消息、异常和错误等信息。
可将PCEP粗粒度的域间路径计算和OpenFlow细粒度的流表操作相结合在SDN控制器上部署PCE服务器来完成域间的路径计算并在SDN控制器与路由器之间运行PCEP协议。但PCEP协议本身并不涉及数据平面的信息收集因此仍需SDN控制器通过BGP-LS等协议来获得路由器利用路由协议收集的拓扑信息。
OF-Config - OpenFlow Configuration and Management Protocol
OF-Config是网络配置管理节点与交换机的接口以完成对OpenFlow交换机的远程配置和管理如配置控制器IP地址如何对交换机的各个端口进行enable/disable操作。 OF-Config在OpenFlow架构上增加了一个被称作OpenFlow配置点的节点它可以是控制器上的一个软件进程也可以是传统的网管设备。OpenFlow配置点通过OF-Config协议对SDN中的网络资源进行管理包括OpenFlow交换机上所有参与数据转发的软硬件如端口、队列等因此OF-Config协议也是一种南向接口。它与OpenFlow之间存在着密切的关系随着OpenFlow标准的演进OF-Config的版本也与其保持同步。
NETCONF
NETCON是基于XML的新一代网络管理配置协议以替代CLI、SNMP。 NETCONF协议通过一组可选特性来适应任何设备架构同时开发人员还可以创建其他的“特性”。因此NETCONF设备可以包含任何专有功能。为了保证对不同网络配置需求的适应性NETCONF协议自上而下分为内容层、操作层、RPC层和传输层 I2RS - Interface to the Routing System
I2RS的核心思想是在传统网络设备的路由及转发系统上定义开放接口使外部应用或控制实体可读取路由器中的信息从而可基于拓扑变化、流量统计等信息动态下发路由状态、策略到转发设备上以支持网络的可编程能力。I2RS沿用了传统网络设备中的路由、转发等结构与功能并在此基础上进行功能的扩展与丰富。 通过I2RS控制器或网络管理应用用户应用可以完成对路由系统的实时或事件驱动的交互这使得信息、策略和操作参数能被注入路由系统中也可以从路由系统中读取这些信息从而在现有的网络配置管理功能之外提供更强大的实时可编程的网络配置能力。
协议对比
协议组织提出时间设计目标技术特点OpenFlowONF2007年数据转发SDN交换机流表操作SDN控制器与交换机见的细粒度流表操作侧重于转发功能追求商用设备的高性能和低价格ForCESIETF2014年控制欲转发分离的IP路由体系结构定义了框架和相关协议用于规范控制平面和转发平面之间的信息交换PCEPIETF2006年MPLS网络中集中的零计算域间流量工程PCEP协议定义了PCC和PCE交互过程中消息报文格式与其相关作用其中包括会话初始化、请求恢复、安全管理、状态通知、出错反馈等NETCONFIETF2006年基于XML的网络配置设计了一种网络协议框架以适应不同网络的配置管理需求包括采用OpenFlow协议的网络I2RSIETF2015年为访问路由系统信息设计的接口以实现可编程的路由重定向支持流量工程、DDoS流量清晰、静态组播树、动态VPN部署等应用为支持网络可编程能力而设计的路由系统标准接口以访问路由器内的路由信息表RIB、拓扑、接口、策略等信息。与原有的网络管理和配置功能相比它强调快速、异步和双向的接口通信OF-ConfigIETF2013年OpenFlow节点的管理配置无实时性要求不影响流表操作功能简单如配置控制IP地址、设备的队列、端口等资源支持远程修改设备的端口状态
2.2 OpenFlow协议安全
信息泄露
信息泄露攻击的目的是嗅探出控制器和交换机的信息特别是流表信息。例如侦测一条流表规则是否存在于交换机或控制器中甚至流表项对应的操作动作和转发策略这些信息可能会被攻击者用来判断网络服务的状态也可能被用于后续的网络攻击。 要获取流表信息通过攻击获得权限提升从而读取流表规则是一种方法。当无法获取直接的访问权限时还可以通过边信道攻击设法得到流表信息。 交换机收到一个包后有以下3种可能的处理方式。 1当数据包完全由交换机的数据平面通过硬件转发时转发速度最快。 2数据包也可能被交由交换机的控制功能处理如交换机的数据平面不支持的转发操作时。这样会花费更多的时间。 3交换机可能把数据包或包头发到控制器这时的速度是最慢的。 通过大量的发包观察对不同数据包的转发时间分布进行分析从而得到合适的门限值就可以根据数据包的转发延时来判断数据包是以何种方式发送的哪些包直接由交换机处理哪些数据包被发往控制层继而便可以判断流表规则是否存在以及一条新的流表规则在何时创建。 当交换机支持流聚合时通过这种信息泄露攻击有较大的概率可以探测到交换机中是否存在某台主机相关的流规则从而得到网络中活动主机的地址信息即使这些主机都禁止了ping操作。采用类似的方法通过更精确的时间测量还可得到部分流表操作动作例如是否有一些数据流由流表设定为强制转发给控制器处理转发端口是虚拟端口还是硬件端口。 同样分析不同数据包的响应延时若发现后序数据包的转发延时明显小于前面的数据包就可以确定以某一速率发送数据包时流表规则何时能建立这个信息有助于提高对控制器的拒绝服务攻击的效率。根据以上分析这类攻击方法主要是通过边信道攻击来实现的。因此可以采用应对边信道攻击的方法来对抗SDN网络中的上述信息泄露攻击。
采用主动安全策略。例如设计流规则建立机制消除延时与网络拓扑间的关联关系。随机化。例如在数据平面加入随机延时从而增加响应时间变化的随机性增加测量的难度。这种方法之前也被用于应对针对RSA和AES的边信道攻击但对于SDN网络数据平面加入额外的延时势必会影响一些实时业务的服务质量。攻击检测。在控制层设计攻击检测应用检测相关攻击流量这些流量有较明显的特征在控制层并不难检测。
非法接入与协议传输安全
OpenFlow交换机和控制器通过监听TCP端口6634/6633建立TCP连接后双方只需通过Hello消息的交互就可建立通道。其中Hello消息只带有OF头即其主要作用基本是保证双方协议版本的一致性并无任何身份和验证信息因此很容易实现节点的非法接入。 另外OpenFlow协议包交互时也没有设计任何机密性和完整性保障机制控制指令容易被窃听和篡改。 OpenFlow协议的认证和通信安全可以通过建立SSL/TLS安全通道来提高由认证中心为交换机和控制器发放证书同时为指令的传输提供一个安全通道。OpenFlow协议并不强制要求实现SSL/TLS。
连接建立的安全
OpenFlow协议要求在建立连接的过程中双方必须先发送OF_HELLO消息给对方如果连接失败那么会发送OF_ERROR消息。攻击者可以通过中途拦截OF_HELLO消息或者伪造OF_ERROR消息从而阻止连接的正常建立。 如果OpenFlow连接在中途中断则交换机会尝试与其他备用控制器建立连接。如果也无法建立连接则交换机会进入紧急模式将正常流表项从流表中删除所有数据包将按照紧急模式流表项转发正常的数据转发完全失效。
actions动作处理的安全
OpenFlow协议要求下列行为列表中的11种类型的行为不能出现重复。
copy TTL inwards应用对数据包向内复制TTL的动作。pop应用对数据包的标签tag弹出pop动作。push-MPLS应用对数据包压入pushMPLS标签的动作。push-PBB应用对数据包压入PBB标签的动作。push-VLAN应用对数据包压入VLAN标签的动作。copy TTL outwards应用对数据包向外复制TTL的动作。decrement TTL应用对数据包的TTL减一的操作。set应用对数据包所有set字段的动作。qos应用所有QoS的动作。例如对数据包设置队列。group如果指定了组行动则按照这个序列中的顺序执行组行动存储段中的行动。output如果没有指定组行动则报文就会按照output行动中指定的端口转发。
但是许多底层交换机在执行时不检查控制器下发的Apply-Actions行为列表那么攻击者可以利用这一漏洞随意额外标记数据包在Apply-Actions行为列表中增加某些重复行为从而达到恶意目的并且该行为对上层来说是完全透明的。例如额外增加output行为旁路出另外一条流达到窃听的目的或者恶意增加decrement TTL行为使数据包在网络中因TTL耗尽而被丢弃。
3.资源安全
3.1 NFV和Hypervisor兼容性
将物理安全设备移植到虚拟化系统变成一个NFV中间设备是一个很大的挑战。其原因有两点第一很多设备如防火墙和入侵防护系统IPS需要使用定制化的网卡驱动和内核以达到更好的性能然而在计算节点的通用Hypervisor上部署则需要解决兼容性问题如DPDK驱动集成等第二一些虚拟化系统提供了自有的用于流量牵引的Hypervisor应用接口这虽然是未部署SDN控制器时的一种解决办法但是往往会耗费安全人员大量的精力去适配这些非标准的接口甚至有主流虚拟化系统并未对外开放此接口造成虚拟化环境中无法部署工作在L2网络的安全机制。
3.2 系统可用性
在虚拟化条件下网络本身并不可靠所以心跳机制不能保证整个安全机制的可用性。 另外虚拟安全设备本身存在性能瓶颈所以当Web网站出现大量的并发连接时中间的虚拟安全设备可能出现拒绝服务的情况。
4.应用安全
4.4 网络虚拟化对网络安全的挑战
私有云系统利用现有的网络技术和虚拟化技术可以保证用户空间隔离和基础的访问控制。然而网络安全还包含其他很多方面如深度包检测、恶意行为检测和防护、安全审计和数据防泄露等。这些安全功能目前还依赖于独立的物理或虚拟网络中间设备实现。 作为网络安全设备正常工作的前提是对流经的数据可见可控然而在虚拟化环境中这些设备的部署和工作模式都受到了挑战。 首先是流量的可见性。IPS与计算节点一样直接连在物理交换机上。假设两个虚拟机VM1和VM3分别在不同的节点Host1和Host2中且节点间通过隧道相连此时VM1→VM3的数据包首先到节点Host1的虚拟交换机上然后经过隧道封装到物理网络中。此时IPS设备可以看到数据包但是封装后的数据包所以设备无法理解该数据流真正的含义。再退一步假设节点间没有用隧道而只是用普通网络相连并通过VLAN区分不同的虚拟网络IPS看到的是带着VLAN的数据包虽然理解数据包本身没问题但处理引擎将面临不同租户有同样虚拟网络造成的地址重叠问题同样会出问题。 其次是流量的可控性。假设两个虚拟机VM1、VM2在同一个节点Host1中那么VM1→VM2的数据包如上图的虚线所示直接通过虚拟交换机传输到目的虚拟机根本没有经过物理IPS设备。此时该设备就无法对数据流进行阻断或做其他控制操作。 因此防护虚拟化设施就需要调整对策改造安全设备本身使其兼容多租户环境改变数据流向使安全设备对流量可见可控。 兼容虚拟化多租户安全设备的部署
有四种方案 1修改处理引擎。现有设备不做大改动仅在数据包处理时增加解隧道和封装隧道的功能并在处理引擎中增加租户等标识。 2安全设备虚拟机服务链。交付硬件设备但实现的是完整的虚拟机管理和流量牵引功能可根据安全策略启动相应的安全设备实例并引导流量形成内部服务链。 3硬件虚拟化。交付硬件设备内部可在虚拟网络设备上启动多个虚拟安全设备。 4安全设备虚拟机。交付安全虚拟机镜像安装在计算节点中。这些虚拟安全设备所在的计算节点和物理安全设备都可通过隧道技术相连并能解析和处理流经的虚拟网络流量。
再谈改变数据流向的3种方法
1通过实现虚拟化系统API来改变数据流向。
下图所示展示了东西向和南北向流量的牵引。如果要监控同属一个虚拟网络的两个虚拟机的东西向流量如左边节点中的虚拟机VM1和VM2则可利用虚拟化系统提供的Hypervisor API将东西向流量导入同主机内的安全设备虚拟机如果要监控虚拟机与外部网络通信的南北向流量则需要利用虚拟化系统提供的路由API。 受限于虚拟化系统API的开放程度。对于东西向流量而言vSphere vShield和NSX目前没有公开而且即便开放了也仅支持安全设备虚拟机部署模式。
2通过SDN牵引来改变数据流向。
当虚拟化系统与SDN结合之后可使用SDN控制器指引底层实体或虚拟交换机的网络流量即可将原本需要使用虚拟化系统API实现的功能利用南向协议来完成。 由于它不需要考虑安全设备的位置 因此所有的部署模式都支持。 下图展示了SDN牵引的原理。当确定要监控VM1→VM2的流量时安全中心会从计算节点或安全节点找到一个IPS设备然后向VM1所在交换机到IPS所在交换机的路径P上的所有交换机下发重定向的流指令。如果选择计算节点的IPS则路径为P1如果选择安全节点上的IPS则路径为P2。这样所有源为VM1且目的为VM2的数据包沿着路径P到达IPS设备经过检查后数据包从IPS输出端口输出此时SDN控制器根据拓扑计算从IPS到VM2的路径并下发流指令沿途交换机将数据包传输到VM2。 3通过人工配置来改变数据流向。
凡是可以通过SDN实现服务链流量牵引的方法都可以通过人工配置底层网络设备来实现。
4.5 SDN带来的安全隐患
网络虚拟化关注的是网络资源管理而SDN关注的是网络流量调度如果仅将两者简单叠加则必然会出现一些问题。例如SDN对底层流量的操控可能会破坏虚拟化的流量隔离而虚拟化对交换机的配置又可能破坏SDN网络的控制平面最终破坏系统的安全性和可用性。
租户隔离
以OpenStack Neutron为例使用Open vSwitch PluginSDN控制器使用Floodlight。 Neutron使用全局隧道与局部VLAN技术结合的方式实现了租户间流量的隔离这种映射关系体现Neutron OpenvSwitch Agent在节点的br-int上设置VLAN并在br-tun中设置Tunnel ID与VLAN之间的转换。因为原生Neutron中存在租户隔离所以租户之间的流量是不能通信的。 但是引入Floodlight后它会接管底层网络设备的通信。它首先将虚拟交换机中的原有流表全部删除然后在收到PACKET_IN后仅根据源目的地址计算路由后下发流表。虽然br-int上的端口有VLAN tag但br-int的actionsNORMAL流被删除后就没有工作在传统模式所以隔离并没有起作用。
访问控制
虚拟化系统可以使用IPTABLES等在Linux网桥和命名空间中实现访问控制而SDN控制器可以在虚拟交换机上实现L2~L4的访问控制。引入SDN后计算节点和网络节点的交换机br-int可做访问控制 此时要实现VM5对外的访问控制到底是在SDN控制器上应用配置ACL还是在虚拟化环境中设置安全组或FWaaS对于安全管理员来说是一个挑战。这是因为冲突、过时或不恰当的配置会给安全管理带来巨大的麻烦。 例如在安全组中允许VM5到VM2的ICMP访问但SDN控制器中的防火墙模块禁止VM5对外的ICMP请求那么在虚拟化系统中排查VM5不能ping通VM2显然是没有结果的。 网络虚拟化模块通常在逻辑资产间关系的层面考虑访问控制关系而SDN控制器根据上层应用策略在数据流层面考虑访问控制关系所以两者的知识、决策逻辑都不一致。如果不能很好地整合起来则会给整个系统带来巨大的风险。 所以在设计SDN控制器与虚拟化系统集成时需要将数据流的两端主机与虚拟化系统中的资产信息关联起来SDN控制器在决定两点间是否可达时需要考虑源目的虚拟机所在网络是否是隔离的以及这两点是否遵从所有SDN应用的访问控制策略同时也遵从虚拟化系统的访问控制策略。当虚拟机启动时除了将虚拟化系统的访问控制策略生效外还需要通知SDN控制器更新其知识库和相应的访问控制策略。
5.系统实现安全
SDN架构包括应用、控制器、交换机以及管理系统虚拟化系统包括控制节点、管理节点、存储节点和计算节点这些组件背后运行的都是软件而软件就可能含有脆弱性从而被攻击者利用并获得非授权的访问权限从而阻断或恶意操纵流量。例如目前大部分白牌交换机都运行基于Linux的开放操作系统那么这些交换机就需要面对Linux操作系统的所有风险。 在一些云计算系统中数据网络可能与管理或控制网络共享。也就是说租户可以访问SDN或虚拟化系统的控制节点在获得控制平面的权限后即可操纵底层的路由器绕过部署在某处的安全设备。 开发一个软件系统的过程中在架构、协议和应用等方面可以做大量的安全性设计但是在系统实现的过程中离不开人的因素所以当系统越大、涉及的组件越多、第三方应用越不可控时就应假定该系统是不安全的。这就需要人们使用脆弱性评估、渗透测试和安全检测等方式不断发现系统的问题并及时修复。
