SDN攻击途径与安全提升

SDN攻击途径与安全提升

如今越来越多的企业开始考虑部署软件定义网络[注](SDN)，但是安全问题成为了他们的最大顾虑。企业希望了解SDN产品是如何确保他们的应用、数据和基础设施免受攻击的。在引入SDN时必须要制定出能够确保控制层流量安全的新策略。本文将评估对SDN系统的攻击途径，分享一些能够确保具有SDN功能的虚拟网络基础设施安全的方法。此外，本文还将就一些被认为能够保证SDN部署安全的方法进行探讨。

SDN 攻击途径多多

SDN是一种连网方式，为了支持虚拟化其将控制层从转发层中分离出来。SDN是网络虚拟化的一个新范式。大部分SDN架构模型都有三个层：底层是具有SDN功能的网络设备，中间层是SDN控制器，上层包括请求或配置SDN的应用与服务。虽然许多SDN系统相对较新，并且仍然没有走出早期部署者的小圈子，但是可能肯定的是，随着技术的不断成熟，SDN将会被广泛部署，并将成为攻击者的目标。

我们预测了几种对SDN系统的攻击途径。SDN的安全顾虑主要集中在对不同SDN架构层的攻击。让我们看一下每一层可能会发生的攻击。下图展示了一个典型的SDN架构和攻击者可能的方向。

对数据层(平面)的攻击

攻击者可能会将攻击目标锁定为网络中的网元。理论上，攻击者能够非法获取对网络的物理或虚拟访问权，或是威胁到已与SDN连接的主机，然后发动攻击破坏网元的稳定性。这种攻击类似于拒绝服务(DoS)攻击，或是一种企图攻击网元的模糊攻击。

目前控制器与网元之间的通信使用了大量的南向API(应用程序编程接口)和通信协议。SDN南向通信可能会用到OpenFlow (OF)、Open vSwitch 数据库管理协议 (OVSDB)、路径计算单元通信协议 (PCEP)、路由系统接口(I2RS)、 BGP-LS、OpenStack Neutron、开放管理基础设施(OMI)、Puppet、Chef、Diameter、Radius、NETCONF、可扩展消息处理现场协议(XMPP)、定位/标识分离协议(LISP)、简单网络管理协议(SNMP)、CLI、嵌入式事件管理器(EEM)、 思科onePK、应用中心基础设施(ACI)、Opflex等协议。这些协议各自都有着一些确保与网络单元通信安全的方法法。尽管如此，许多协议都非常新，部署者们可能并没有以最安全的方式设置它们。

攻击者可以利用这些协议尝试着将一些新流实例化至设备的流表中。攻击者会企图伪造一些新流，以让不应当通过网络的流量被允许通过。尽管流量定向负责指导流量通过防火墙，但如果攻击者能够创建一个可绕开流量定向的流，那么攻击者无疑将获胜。如果攻击者能够控制流量转向自己设定的方向，那么他们可能会尝试利用这一功能对流量进行嗅探，然后发动“中间人(MITM)”攻击。

此外，攻击者还可以对流进行窃听，查找到哪些流正在被使用，哪些流量被允许通过网络。同时他们会尝试窃听网元与控制器之间的南向通信。这些信息对于重播攻击或是侦察都非常有用。

许多SDN系统被部署在数据中心内，而数据中心则通常使用数据中心互联协议(DCI)。这些协议包括使用基本路由封装的网络虚拟化(NVGRE)、无状态传输通道(STT)、虚拟可扩展局域网(VXLAN)、思科OTV、二层多路径(L2MP)、基于TRILL的协议(如思科FabricPath、瞻博QFabric、博科VCS Fabric)、最短路径桥接(SPB)等协议。这些协议有的缺乏身份认证，有的没有采用加密技术，因而无法保证数据包内容的安全。此外一些新协议由于协议设计或是厂商和客户在部署协议时的方式不当等问题导致存在弱点。攻击者可以自己伪造流量，并让它们通过DCI连接或是对DCI连接发动DoS攻击。

对控制器层的攻击

SDN控制器肯定是攻击的目标。攻击者会出于多种目的对SDN控制器进行攻击。他们可能会通过伪造发往网络设备的北向API信息或是南向信息从而实例化新的流。如果攻击者能够成功伪造来自合法控制器的流，那么将能够随心所欲地让流量通过SDN，并可能绕开为确保安全所制定的策略。

攻击者可能会尝试对控制器发动DoS攻击，或是使用其他方法使控制器发生故障。此外，攻击者还会尝试对控制器发动一些资源消耗型攻击，以瘫痪控制器，让控制器对反应迟钝并降低它们发送和接收数据包的速度。

很多时候，SDN控制器是运行在在某种Linux操作系统上的。如果SDN控制器是在通用操作系统上运行，那么该操作系统的弱点就是控制器的弱点。通常控制器使用的都是默认密码，且没有对安全设置进行配置，SDN工程师往往只让这些控制器能工作就行，由于担心搞坏它们，SDN工程师往往不愿意去碰它们，这会导致最终产品很脆弱。

最后，如果攻击者创建了自己的控制器，并让单元信任那些来自“流氓”控制器的流，那么情况将非常糟糕。攻击者随后可以在网元的流表中创建条目，如此一来SDN工程师将无法在控制器中发现这些流。如此一来，攻击者将会彻底控制网络。

对SDN 层的攻击

对北向协议进行攻击可能也是一条途径。目前SDN控制器也在使用许多北向API。北向API通常使用Python、Java、C、REST、XML、JSON等语言。如果攻击者能够利用北向API的弱点，那么他们将可通过控制器的控制整个SDN网络。如果控制器对北向API缺乏安全防护措施，那么攻击者则可创建他们自己的SDN策略，并从而获得SDN环境的控制权。

很多时候，REST API使用的都是默认密码，这个细节至关重要。如果SDN部署没有修改默认密码，那么攻击者则能够创建针对控制器管理接口的数据包，随后可以查询到SDN环境的配置并修改成自己的配置。

如何提升SDN 系统的安全性?

随着SDN的部署，确保控制平面流量的安全性需要新的做法。在传统的IP网络中(+本站微信networkworldweixin)，控制平面的安全是以路由协议安全措施的形式得以保证的，这包括使用针对EIGRP、IS-IS或OSPFv2的 MD5(信息摘要算法5)加密技术，或针对OSPFv3的IPsec AH，或针对MP-BGP的GTSM/ACL/密码。然而一些人甚至DPI没有使用这些针对传统IP网络的简单技术。如果他们在部署SDN时依然以同样的态度漠视安全，那么无疑会让机构暴露在攻击危险之中。下面让我们来看下如何通过强化上述三个层面的安全来确保整个SDN系统的安全。

确保数据平面安全

典型的SDN系统通常使用的是x86处理器和TLS(前身为SSL)保护控制平面安全。这些使用已久的HTTP会话易于遭受危及数据平面安全的攻击。机构应当使用TLS来认证和加密网络设备端与控制器之间的流量。使用TLS可帮助验证控制器和网络设备/ SDN端，防止窃听和伪造南向通信。

根据所使用南向协议的不同类型，确保南向通信的安全有许多种选择。一些协议可像之前所说的那样应用到TLS对话。一些协议可使用共享密钥和/或随机密码阻止重播攻击。SNMPv3协议远胜SNMPv2c， SSH远胜于Telnet。一些专有南向协议可能有着自己的方法阻止攻击者的窃听和伪造行为。

同样，根据所使用的数据中心互联(DCI)协议，认证隧道端点和保护隧道流量安全方面也有着不同的配置选项。密码/共享密钥同样是一种选择。尽管如此，部分DCI协议可能没有任何安全选项。

有的机构可能会认为专用网络具有一些与生俱来的安全特性。但是随着机构将虚拟网络和SDN扩展至云服务和远程数据中心上，对物理路径进行验证可能并非易事。当机构用户控制着物理访问权时，阻止未经授权的访问更为容易，但是随着网络的虚拟化，实际的物理路径正变得越来越模糊，使得保护自己无法看见的东西的安全变得非常困难。

确保控制器层安全

控制器是一个关键的攻击目标，因此必须要强化其安全。提升控制器和网元的安全通常需要强化主机操作系统的安全性。所有关于提升面向公公共Linux服务器安全性的最佳实践都非常适用。此外，机构仍然需要严密监视其控制器，防范任何可疑行为。

机构还需要阻止对SDN控制网络的非授权访问。SDN系统应当考虑到安全配置，并验证访问控制器的管理员。对于控制器管理员来说，基于角色的访问控制(RBAC)策略可能是必须的。记录和检查跟踪对于查找由管理员或攻击者所做出的非授权修改非常有用。

如果出现了针对控制器的DoS攻击，高可用性(HA)控制器架构可有效应对这类攻击。使用冗余控制器的SDN可承受一个控制器的损失并继续工作。这相当于提升了攻击者对系统中所有控制器发动DoS攻击的门槛。虽然这种攻击是无法隐藏的，但是我们无法察觉攻击者的下一个目标。

确保SDN层安全

另一个保护措施是使用针对控制流量的带外(OOB)网络。在数据中心内创建一个OOB网络比在整个企业广域网中创建一个OOB网络要容易且成本较低。使用北向和南向通信专用OOB网络可帮助确保控制器管理协议的安全。

使用TLS或SSH等方式确保北向通信和控制器管理的安全被认为是最佳实践。来自应用的通信以及由控制器发起的请求服务或数据服务应当通过认证和加密方式确保安全。

针对所有请求SDN资源的北向应用的安全代码也应当是一个最佳实践。安全代码实践不仅有利用确保面向公众的互联网应用安全，而且还适用于北向SDN连接。

部分SDN系统能够检验网络设备表单中的流是否违反控制器策略。这类检查(类似FlowChecker)能够帮助识别出正常流与攻击流之间的差别。

结语

我们仅能够预测哪些攻击者可能会将SDN变为攻击目标。部署、协议、控制器软件都是新的，以往对SDN发动的攻击也还不为人知。根据SDN架构，我们能够预测出攻击者可能会发动进攻的地方。如果我们站在攻击者的角度考虑问题，我们应该能够找到SDN网络的弱点，并可提前提升其安全性。

在SDN部署项目之前，用户应当在早期设计阶段就考虑如何确保系统安全。不要将安全问题留到最后收尾阶段再着手解决，否则可能会追悔莫及。