在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与交换机断开连接。攻击者只需要发送恶意数据包就可以利用这个漏洞，这是一个通过数据层面利用控制器漏洞的典型案例。
更详细的情况参见：https://jira.onosproject.org/browse/ONOS-605
3、拓扑欺骗
2015年2月中旬，报导出另一个可以通过数据层面利用的漏洞。大多数SDN控制器具有主机跟踪功能，允许主机在不同地理位置间移动。主机跟踪功能依赖packet_in消息，并且不需要任何校验、认证和授权。攻击者可以冒充主机，让控制器相信该主机已经转移到由攻击者控制的物理位置上了。
利用这个漏洞，攻击者只需向交换机发送恶意消息，唯一的前提就是攻击者需要知道目标主机的MAC地址。
详细情况参见：http://www.internetsociety.org/sites/default/files/10_4_2.pdf
值得注意的是以上三个漏洞虽然都是新发现的，但都不是新问题。XXE是Java项目中经常出现的问题。引发未处理异常的DoS攻击也很常见。拓扑欺骗漏洞乍一听似乎很新奇，事实上与MAC欺骗大同小异，而MAC欺骗已经是一个众所周知的问题了。虽然SDN是一项新兴技术，但依旧是软件。SDN领域出现的少数基础问题其实代表了大多数软件的安全漏洞，因此可以通过应用尝试和对抗策略去处理这些漏洞。
采取的安全措施
安全响应流程
适用于任何软件的安全策略就是安全响应流程。安全响应流程应该由一个专业的队伍负责，一个安全响应流程最起码应该具备以下功能：
- 提供汇报安全漏洞的渠道。
- 有能力做好修补漏洞的前期准备工作，确保任何漏洞细节不会曝光。
- 有能力迅速修补漏洞。
- 能够简洁、明了地向用户说明漏洞，并且协助用户修补漏洞。
目前ONOS已经建立了一个安全响应流程，迈出了至关重要的第一步。想要了解更多情况请参见：https://wiki.onosproject.org/display/ONOS/Security
防御技术
安全响应是反应式的：发现漏洞，修补漏洞，提供相应的咨询服务。当然，以一种主动的方式处理安全漏洞更为恰当。目前几个开源项目都在努力提高SDN控制器的安全性，下面就了解其中两个。
1、ONOS安全模式
安全模式是针对ONOS Cardinal版本推出的新功能，对ONOS应用进行有效的访问控制。这就意味着，想要利用ONOS的漏洞首先要通过安全模式ONOS的验证，有效地缓解了ONOS漏洞的影响。
更多情况请参见：https://wiki.onosproject.org/display/ONOS/ONOS+Security%3A+Security-mode+ONOS
2、Topoguard
发现拓扑欺骗漏洞的研发小组开发了一款名为Topoguard的工具处理这个漏洞。Topoguard会核实主机迁移的情况，正常的迁移在主机迁移结束前会有一个Port Down信号，表明迁移后原物理网络位置不可到达了。Topoguard会逐一验证这些情况，尽可能地核实主机迁移的真实性。
目前Topoguard已经和Floodlight控制器紧耦合了，但是也可以移植到其他控制器中。
更多详情请参见：https://github.com/xuraylei/floodlight_with_topoguard
展望
2014年笔者刚刚加入开源SDN社区时，SDN安全还很薄弱。从那时起，社区开始审核控制器，报导漏洞，成立安全响应小组，记录安全响应过程，并且开发安全防御技术。这是一个令人印象深刻的发展过程，而我有幸见证了这个历程，因此在我看来开源SDN控制器有能力提供生产部署所需的安全性。
SDNLAB语
或许现在很多SDN方面的安全问题大都是软件工程领域遇到的类似常见问题或变种，但相信随着SDN技术的商业应用不断增多，会有更多的具有SDN特色的漏洞出现，在SDN安全领域的研究还是很有意义的。
