漫谈软件定义 络

在2015年9月9日-11日举办的“44 CON 伦敦”峰会中，David Jorm发表了名为“Software Defined Networking (SDN) Security”的演讲。44CON，现在称作44CON 伦敦，是英国最大的综合年度安全会议和培训活动，吸引了全球各地最优秀，最活跃的信息安全行业的精英到英国分享关于安全方面的研究心得。本届大会上David Jorm向大家分享了他在SDN安全方面的一些经验与见解，David已经从事 络安全研究15年了，目前主要研究SDN安全，负责带领OpenDaylight和ONOS的安全研究小组。

SDN迅速从研发阶段向生产部署阶段过渡，但却面临着一个棘手的问题——安全。David分享了他个人关于SDN技术的一些看法，主要围绕：SDN暴露的攻击面，流行SDN控制器中发现的漏洞，以及提高SDN控制器安全性的一些措施。

SDN简介

开源SDN是一项热门技术，在商业和非营利性组织的共同推动下迅速发展。2015年对SDN而言是至关重要的一年，SDN开始从实验阶段向生产部署阶段过渡。在这个期间SDN必须面对稳定性、可扩展性和安全性等问题。也就是说，SDN想要成功向生产部署过渡，首先就必须定位并解决SDN控制器和交换机中的安全隐患。

SDN攻击面

传统 络中物理设备包含了 络的控制层面和数据层面，通常是由专用硬件和软件组成。软件定义 络将控制层面剥离出来集中到一个控制器中，控制器可以通过OpenFlow等协议控制交换机，而交换机只需要负责处理数据层面即可。从安全角度来看，这种责任分配机制既有好处也有弊端。将控制层 络与数据转发 络分离明显是SDN的一项优势，但是控制权的集中化导致控制器成为攻击重点。

除了SDN控制器提供的控制器层的管理接口，控制器还有其他攻击面：交换机管理的数据层面。当交换机收到一个没有匹配项的数据包时，交换机就会把这个数据包发送给控制器征询意见。攻击者可以钻这个空子，向SDN交换机发送数据从而利用控制器中的漏洞。

近期发现的漏洞

随着SDN逐渐成为一项主流技术，得到越来越多安全研究人员的关注。前一段时间， 导了几个新的SDN控制器方面的漏洞，我们仔细观察一下其中的三个，它们分别展现了SDN不同的攻击面。

1、 OpenDaylight netconf接口中的XML eXternal Entity (XXE)漏洞。

2014年年末，OpenDaylight netconf接口中发现了一个XXE漏洞。netconf接口允许用户使用XML语言修改 络配置，在处理用户提供的XML文件时，netconf并不会禁用外部实体，于是就出现了一个漏洞。这是服务端进程处理XML文件时经常出现的一个问题，Java应用中也比较常见。如果一个远程攻击者可以使用OpenDaylight的netconf接口，那么就可以利用这个漏洞获取OpenDaylight控制器中的文件，可能是配置细节文件也可能是明文凭据。

想要利用这个漏洞首先要有权限使用netconf接口，对控制接口进行访问控制可以有效的减缓这个漏洞带来的影响，默认启动访问控制将会更有效果。

2、 ONOS中的Denial-of-service (DoS) 漏洞

2015年年初在ONOS项目中发现了一个有趣的DoS漏洞。正如之前所提到的，当交换机收到一个没有匹配项的数据包时，交换机就会把这个数据包发送给控制器。当处理不规则、不完整、恶意制定的数据包时ONOS的解串器会引发异常，如果不及时发现并处理这个异常，那么相关交换机就会与ONOS断开连接。

远程攻击者可以利用这个漏洞实施DoS攻击造成ONOS与交换机断开连接。攻击者只需要发送恶意数据包就可以利用这个漏洞，这是一个通过数据层面利用控制器漏洞的典型案例。

3、拓扑欺骗

2015年2月中旬， 导出另一个可以通过数据层面利用的漏洞。大多数SDN控制器具有主机跟踪功能，允许主机在不同地理位置间移动。主机跟踪功能依赖packet_in消息，并且不需要任何校验、认证和授权。攻击者可以冒充主机，让控制器相信该主机已经转移到由攻击者控制的物理位置上了。

利用这个漏洞，攻击者只需向交换机发送恶意消息，唯一的前提就是攻击者需要知道目标主机的MAC地址。

值得注意的是以上三个漏洞虽然都是新发现的，但都不是新问题。XXE是Java项目中经常出现的问题。引发未处理异常的DoS攻击也很常见。拓扑欺骗漏洞乍一听似乎很新奇，事实上与MAC欺骗大同小异，而MAC欺骗已经是一个众所周知的问题了。虽然SDN是一项新兴技术，但依旧是软件。SDN领域出现的少数基础问题其实代表了大多数软件的安全漏洞，因此可以通过应用尝试和对抗策略去处理这些漏洞。

采取的安全措施

安全响应流程

适用于任何软件的安全策略就是安全响应流程。安全响应流程应该由一个专业的队伍负责，一个安全响应流程最起码应该具备以下功能：

目前ONOS已经建立了一个安全响应流程，迈出了至关重要的第一步。想要了解更多情况请参见：
https://wiki.onosproject.org/display/ONOS/Security

防御技术

安全响应是反应式的：发现漏洞，修补漏洞，提供相应的咨询服务。当然，以一种主动的方式处理安全漏洞更为恰当。目前几个开源项目都在努力提高SDN控制器的安全性，下面就了解其中两个。

1、ONOS安全模式

安全模式是针对ONOS Cardinal版本推出的新功能，对ONOS应用进行有效的访问控制。这就意味着，想要利用ONOS的漏洞首先要通过安全模式ONOS的验证，有效地缓解了ONOS漏洞的影响。

2、Topoguard

发现拓扑欺骗漏洞的研发小组开发了一款名为Topoguard的工具处理这个漏洞。Topoguard会核实主机迁移的情况，正常的迁移在主机迁移结束前会有一个Port Down信 ，表明迁移后原物理 络位置不可到达了。Topoguard会逐一验证这些情况，尽可能地核实主机迁移的真实性。

目前Topoguard已经和Floodlight控制器紧耦合了，但是也可以移植到其他控制器中。

展望

SDNLAB语

或许现在很多SDN方面的安全问题大都是软件工程领域遇到的类似常见问题或变种，但相信随着SDN技术的商业应用不断增多，会有更多的具有SDN特色的漏洞出现，在SDN安全领域的研究还是很有意义的。