基于SDN 的接入网安全解决方案设计

彭大芹，谷 勇，万里燕，陈 勇

(重庆邮电大学 电子信息与网络工程研究院，重庆400065)

接入网作为网络的“最后一公里”，其性能直接影响到整个网络的性能。随着接入网朝着高带宽、全业务、易运行维护的方向发展［1］，给人们带来了便捷，也带来了因其网络自身的脆弱性而引发的安全威胁。因此，如何有效地解决接入网中存在的安全问题已成为近年来关注和研究的热点。L.Wenjing［2］提出了一种改进的加密认证方法来保护用户的隐私，但其方法复杂度较大;李频［3］采用虚拟专用网与防火墙集成的方法来保证接入网安全，但遗憾的是该方法增加了网络部署和维护成本。针对传统解决方法的不足，在本方案中，采用入侵防御系统和防火墙相结合的二重安全机制来提高防护效果，同时利用SDN 控制器灵活调配网络资源，降低防护成本，提高安全设备间的协同性和利用率，并通过实验测试验证了该方案的可行性和有效性。

1 接入网的安全解决方案现状

1.1 传统的安全解决方案

接入网传统安全解决方案主要有加密认证的解决方案和虚拟专用网(Virtual Private Network，VPN)与网络安全设备(Network Security Equipment，NSE)结合的解决方案。

加密认证的解决方案主要是对需要接入网络的用户采用“用户名+密码”的方式进行身份认证，只允许通过认证的用户接入网络，并对用户与网络之间所传输的数据进行加密［2］。从而可以防止接入网免遭伪装攻击和恶意用户对系统的主动攻击。

VPN 与NSE 结合的解决方案主要是在每个分支网络的进出口部署NSE 来防护路由和监测网络中的网络行为。在各分支网络的边界处部署VPN 网关来建立相应的虚拟安全通道，从而实现数据在网络中的安全传输。在此方案中，采用如防火墙、入侵防御系统等网络安全设备不但可以防护来自外网的入侵，还可以监视网内的恶意行为，增强内网的安全性。

1.2 存在的主要问题

1) 防护效果不理想

目前，由于一些加密机制已被恶意用户破解，这使得加密认证的防护效果大大降低。防火墙的防御手段采用静态被动方式，从而使其无法灵活应对各种变化的攻击行为。而且传统安全解决方案很难应对恶意用户发起的拒绝服务攻击，特别是其中的分布式拒绝服务攻击。

2) 防护成本高

传统的安全解决方案中，为了保证网络的安全，需要在每个分支网络进出口处部署网络安全设备，从而增加了部署成本。并且随着网络规模的扩大，管理和维护成本也大大增加。

3) 协同性和灵活性差

网络中所部署的安全设备相互独立，无法协同工作。若某一安全设备本身出现故障，其他安全设备无法及时顶替其工作。当繁忙网络进出口处的安全设备负载过重时，其他空闲网络的安全设备却处于空闲状态，这将造成设备利用率不高和资源的浪费。

2 基于SDN 的安全解决方案设计

软件定义网络(Software Defined Network，SDN)是一种新型网络架构，是网络虚拟化的一种实现方式。其核心技术OpenFlow 将网络设备控制面与数据转发面分离开来，并使控制面可编程化，从而实现控制功能的集中化、智能化［4］。针对传统接入网中安全解决方案所存在的防护成本高、安全设备的利用率低和协同性差的问题，结合SDN 的优点和相关技术［5］，利用现有的安全机制，提出一种新的接入网安全解决方案。

2.1 主要设计思想

SDN 将控制功能分离出来，这使将传统网络中各个网络节点的自主式控制管理转变为整个网络的集中式控制管理成为可能。本方案通过使用一个SDN 控制器来对整个网络进行全局控制管理。控制器通过下发合适的控制指令来合理灵活调配网络资源，从而可去除空闲节点处的安全设备部署。在繁忙的网络节点进出口处，利用防火墙和入侵防御系统相结合的二重安全机制来提高防护效果，同时保留访问时的认证机制和保证数据传输安全的VPN 技术。

2.2 总体架构设计

根据设计思想，搭建了基于SDN 的接入网安全解决方案的总体架构，如图1 所示。

图1 方案总体架构图

在该方案中，若用户与服务器之间、服务器与服务器之间互联的公共网络是Internet，考虑因其特有的开放性而无法保证网络环境安全的特点，采用VPN 技术建立对应的VPN 隧道来保证通信数据在Internet 中的安全传输。若互联的公共网络是SDN 网络，则不需要使用VPN 技术，这是因为在SDN网络架构中已经使用了虚拟化技术来实现虚拟链路间的隔离。

SDN 控制器是本方案中的重要设备，其主要功能有网络管理、资源分配、负载均衡、路由选择、流表控制、QoS 保证、节能计算以及其他应用。网络管理是指对整个网络的集中式控制和管理，资源分配主要指带宽的动态分配，负载均衡是调整各OFS 的负载载重，路由选择是提供路由选择策略来选择最佳传输路径，流表控制是对流表进行控制管理，QoS 保证指实现网络的质量保证，节能计算是实现接入网中的能源节省。对于无线接入，方案中使用了移动VPN 网关(Mobile VPN Gataway，MVG)来保证移动用户安全接入网络。由于SDN 控制器的灵活调度，只需在繁忙的节点处部署NSE，这样不仅降低了部署成本，而且便于管理维护。

2.3 整体通信流程

在本方案中，当用户想要访问网络服务器中的资源时，首先需要选择一种确定的接入方式并提出访问请求，然后访问请求经过接入交换机转发后利用虚拟化技术在公共网络安全传输到资源所在的分支网络，分支网络的OpenFlow 交换机(OpenFlow Switch，OFS)查询本地流表并进行流表匹配。若流表匹配成功，该访问请求就直接通过对应路由并经过防火墙和IPS 安全设备检测无异常后到达服务器，在服务器接受访问请求后，用户便可以访问资源了;若OFS 的流表中无相应的流表项，OFS 就会将该请求转发给SDN 服务器。

SDN 服务器接收该请求后，查询整个网络中的安全设备部署情况，判断用户将访问的服务器所在的分支网络有无部署安全设备。若部署了安全设备，SDN 控制器就向该分支网络中的OFS 下发流表项，建立路由;若没有部署安全设备，SDN 控制器就会立即寻找距离该分支网络最近的空闲可用安全设备，并向其安全设备和服务器所在的网络中的OFS 下发流表项，从而建立路由。访问请求根据所建立的路由先后通过防火墙和IPS 检测。若检测后发现数据流中存在异常，安全设备将阻止并丢掉此异常数据包，并将此异常上报给SDN 控制器，SDN 控制器接收该异常报告后，将向对应的OFS发送控制指令来删除异常流表项;若数据流无异常，访问请求数据就会到达服务器，在服务器接受该请求后，用户便可以访问相应资源了。

整个通信的具体流程如图2 所示。

3 方案的测试

本方案是在自主搭建的实验环境中进行测试验证的，实验环境主要由OpenFlow 交换机、IPS、服务器和SDN 控制器构建而成。其中，服务器由装有LAMP 软件的PC 机充当，控制器由装有NOX 系统的PC 机充当。

为降低防护成本，本方案中采取的策略是不在访问量小的网络分支边界处部署IPS，当有用户请求访问该分支中的服务器时，控制器将为此访问请求选择最近的IPS 设备。在验证该策略时，构建了两个网络分支:一个分支由server A 和OFS A1 构成;另一个分支由server B、IPS1 和OFS B1 构成。由图3 中的流表项所示，当用户访问server A 时，访问请求在控制器的控制下先由OFS A1 转发给OFS B1，通过IPS 检测后转发给OFS A1。

为验证安全设备间的协同性和利用率，在该实验网络中添加一台与IPS1 相同的IPS2 设备，再添加一台OpenFlow 交换机OFS C 来使IPS1、IPS2 距离server A 的距离相等，IPS1、IPS2 的负载量分别设置为30%和10%。由实验结果图4 可知，当用户访问server A 时，控制器将为该请求选择负载量小的IPS2 作为检查设备。通过实验测试发现，测试输出结果与方案中的预测结果基本吻合，从而验证了本方案的可行性和有效性。

图2 用户访问通信流程图

图3 一台IPS 情况下OFS 的流表(截图)

图4 不同负载量的IPS 选择后的OFS 的流表(截图)

4 小结

接入网的安全性一直是人们关注的焦点，随着接入网的发展，也带来了相应的安全问题。本文针对接入网传统安全解决方案所存在的防护成本高、安全设备利用率低和协同性差的问题，提出了一种基于SDN 的接入网安全解决方案。在本方案中，将SDN 的相关技术与现有安全机制结合，从而使接入网的控制和管理变得更加灵活，在降低接入网防护成本的同时提高防护效果，并提高了各个安全设备的利用率和彼此之间的协同性，最后通过实验验证了方案的可行性和有效性。此方案为解决接入网安全问题提供了一些新思路，这对将来提出更好的安全解决方案起到一定的促进作用。

［1］张延培. 论接入网技术现状与发展趋势［J］.信息通信，2013(1):241－242.

［2］WEN J L，KUI R.Security，privacy and accountability in wireless access networks［J］.IEEE Wireless Communications，2009(8):80－87.

［3］李频. 虚拟专用网与防火墙集成的设计［J］.计算机应用与软件，2006(11):114－116.

［4］郭春梅，张如辉.SDN 网络技术及其安全性研究［J］.信息网络安全，2012(8):112－114.

［5］SHIN S，GU Guofei.Cloudwatcher:network security monitoring using OpenFlow in dynamic cloud networks［C］//Proc.IEEE International Conference on Network Protocols(ICNP).［S.l.］:IEEE Press，2012(11):1－6.