编者按：本文系SDNLAB技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。

分享嘉宾
--------------------------------------------------------------------------------------------------
刘文懋，博士，绿盟科技创新中心总监，清华大学博士后。长期从事云计算和SDN领域的安全研究，关注Openstack和Opendaylight为代表的新技术与网络安全结合出现的新挑战和新机遇，著有《软件定义安全-SDN/NFV新型网络的安全揭秘》。兴趣点还包括基于威胁情报的数据分析和物联网安全。
--------------------------------------------------------------------------------------------------

1 大背景

1.1 SDx背景

我比较喜欢用这张图作为开场白，在数据中心中，计算和存储的发展非常快，但是网络相对而言还是比较初级。这一点从Opentack的nova和neutron组件的成熟度可以看出来。

不过，SDN和NFV这些新的网络技术的出现为网络运维自动化带来了新的方向，通过控制平面的集中管控和虚拟网络资源的灵活管理，可以最终实现SDDC（软件定义数据中心）。

不过在云计算中，作为用户最关心的安全问题却在影响整体应用的成熟度。目前安全设备的交付、配置和运营等很多方面都需要人工参与，在虚拟化系统中还勉强ok，但在大规模的云计算数据中心就力不从心了。

反过来说，SDN和NFV的先进特性确实也给安全防护带来了想象空间，利用NFV的弹性、快捷可以快速部署大量的虚拟化安全设备，满足突发流量的防护；利用SDN的全局视野、快速流量调度就能实现防护快速生效。所以看待事物要客观，知利知弊。

1.2 安全背景

随着互联网/移动互联网的发展，层出不穷的安全事件成为个人/企业/国家面临的巨大挑战。就个人而言，信息泄露、电信诈骗引发了很多社会事件；就企业而言，敏感数据外泄，DDoS即服务，勒索软件肆虐造成了巨大的损失；就国家而言，网络部队攻击造成的如伊朗核设施遭到破坏，甚至影响美国大选。

近年来重量级的安全事件不绝于耳，如Target丑闻到Hacking Team武器库曝光，可以看到安全攻击呈现两种趋势：大规模杀伤性武器/核爆炸型攻击和特种部队型攻击。前者是如利用一个新发现的普遍使用的基础设施漏洞（如SSL心脏滴血漏洞）做全互联网层面的快速扫描、确定受害者和实施攻击，整个事件不超过72小时；后者是指针对重要的商业、政治目标，使用未公开的零日漏洞、有针对性的社会工程诱骗等一系列高级手法，自外向内一步步渗透，最终破坏系统或窃取重要数据。

这两种攻击手法不尽相同，但危害巨大。广谱的大规模攻击虽然原理简单、方法公开，但要赶在攻击者之前分析漏洞、提出解决思路、应用到安全产品、完成测试，到最后的投放更新，要在小时级做到响应，72小时内做到全部更新，在现有的安全体系下是非常有挑战性的。而定向的高级威胁更麻烦，需要在无数流量数据、日志信息中找到蛛丝马迹，了解攻击者的意图（TTP），无异于是大海捞针。更不用说攻击者还利用了多种攻击手法，可以绕过单个安全设备的防护。所以就legacy的安全防护体系，做到防护APT攻击，无疑是难上加难。

以上是大背景，即云计算给安全防护带来了挑战，网络空间的大背景又告诉我们安全防护已经跟不上攻击者的步伐了；同时，云计算的先进理念给安全防护带来了宝贵的方向，其先进技术也给安全防护带来了很好的工具设施。

2 软件定义安全

2.1 理念

“软件定义安全”这个词是Garnter最早提出来的，分析师Neil在《The Impact of Software-Defined Data Centers on Information Security》一文中给出了定义：

不过需要明确的是，“SDN/NFV安全”和“软件定义安全”不是一个概念，请大家不要将两者混为一谈，前者是新的网络技术的自身安全问题，后利用新的网络技术实现更多的防护功能，如自动化调度流量、安全服务链；而后者其实并非是一种技术，而是一种思想或一种体系架构，强调通过软件化的安全应用和安全控制平台，集中控制、智能决策和敏捷响应，以解决以往安全设备简单堆叠不能抵御频复杂、高级的安全威胁。当然两者也是有联系的，借助SDN/NFV的技术可以使软件定义安全更快落地。

2.2 架构

其实分析师是高屋建瓴的提出了理念，具体实现学术界、工业界每家众说纷纭。例如NDSS'13上有篇文章介绍FRESCO，其结构如图4.2所示。

图中主要的扩展内容都部署在SDN的控制平面，维持了原有数据平面功能的单一性，避免给数据平面造成新的负担。图示中的模块（Module）用于实现基本安全动作（例如检查TCP连接是否成功、数据包分析、数据流重定向等），利用FRESCO提供的脚本语言可以将这些基本模块进行自定义组织，形成一个完整的动作链，即为图中的实例（instance）。实例利用事件（event）作为输入触发相应模块的功能，事件有可能由FRESCO系统中的模块产生，也有可能由传统安全设备产生。当事件发生时，根据由角本自定义的实例，几个模块组织在一起形成一系列的安全动作，通过集成在网络控制器内的安全执行内核SEK（FRESCO Security Enforcement Kernel）实现，FRESCO应用层的能力呈现都需要控制平面的功能扩展SEK予以支持。

FRESCO系统的实现方案中实验了安全设备模块化分和重组，不同厂家的安全功能被封装成基本安全模块，利用角本对简单基本的安全动作进行组合，可提供复杂的安全功能，这在一定程度上验证了安全功能分解和重组的可行性和优势，使安全公司或SDN网络安全服务提供商可以快速开发基于SDN的安全产品和服务。这种程序化、自动化的响应过程是一种软件定义安全的实现，能减轻安全运维负担，根据文中评估结果，这种方案也极大的减少了代码量，虽然处理过程增加了响应时间，但整体时延较小。

FRESCO采用了安全应用与网络控制器紧耦合的方式，需要在网络控制器NOX上增加安全执行内核(Security Enforcemnet Kernel)，安全能力作为SDN应用部署在控制器上也使安全应用过于依赖控制层环境，较难实现迁移复用；并且上层应用产生安全策略可能导致与控制层上其它应用下发的策略冲突。所以在工业界需要一个开放的安全体系，能与SDN或其他控制平面松耦合。即便网络用的是overlay，或是underlay，即便是vlan组网，或是vxlan，即便是这个，或是哪个，安全控制平台只关心SDN控制器调度流量的语义：将从A到B的流量牵引/阻断/镜像到C处，这样就大大简化了安全方案，也提高了其灵活性。

我这边提的架构是这样的：

安全架构最终最重要的是安全控制平台，地位相当于sdn控制器，执行所有的安全核心功能，如资源管理、日志分析、网络控制、服务编排等，其中资源管理组件与安全资源池对接，各种各样的安全设备提供安全能力，而非独立的安全盒子；服务编排组件可以支持多个安全应用的安全策略共同作用于某个被防护主体上。同时控制平台可调用SDN控制器的北向API将流量牵引到相应的防护设备上，也可以调用云平台的API去获取租户、虚拟机等资产的信息。

当然，别家的方案更不一样，如华三、启明也有自己的方案，大家可自行参阅。

2.3 案例：Web防护

以往企业通过WAF（Web应用防火墙）怎么防护网站呢？往往需要花费几个月的时间进行售前沟通、招标、下单，然后厂家发货，到货后由工程人员加电、配置、测试，最后进行日常运营。整个过程时间开销很大，配置繁杂。如果我们引入软件定义安全的体系后，就可以将这一切变得简单。

假设我们有一个与Openstack、SDN控制器（Floodlight、ODL...）集成的安全控制平台，并且开发了一个Web安全应用。那么用户只需要登录到Openstack平台上，点击安全应用，将WAF拖动到被防护VM，此时安全应用做了什么事情呢？

首先，安全应用通过控制平台，快速部署了若干个虚拟WAF，然后通过SDN控制器将原来直接到VM的流量牵引到了相应的虚拟WAF，并将WAF输出口的流量牵引到相应的目标VM，最后安全应用向防护虚拟WAF下发防护策略，告知其部署模式、防护网站等一系列信息。

可见，通过自动化的安全控制平面，可以将以前费时费力的安全运营变得高效简单，这与SDN的初衷是一致的。

回到我们开头的话题，如果攻击者进行广谱扫描尝试攻击时，用户只需要租用短期的Web防护就能抵御这些攻击，现在大的安全厂商（比如绿盟^_^)能够在小时级做云端应急响应，快速将防护规则推送给在线的WAF，使用在线补丁就能防护住所有利用这个漏洞的恶意攻击。

当然这里还有很多问题需要研究，比如要考虑这个设备部署位置的优劣、资源调度、处理性能等一系列问题。

另外在开头的另一个抗APT的场景中，防守方可以通过多安全设备或安全机制的协同进行快速防护，那么可能多安全应用及多安全设备的编排，除了旁路虚拟流量分析设备外，需要串联一个虚拟IPS，可能还需要再旁路一个文件沙箱，数据包流向序列、安全策略下发什么、下发到哪里，如何保证多个安全应用下发的策略一致，这就涉及到安全服务链。这又是偏学术的大话题了，不做详述。

2.4 落地：安全资源池

另外一个很经典的问题就是这个虚拟安全设备部署在计算节点里面，靠近被防护VM，还是部署在专用的安全节点上？前者的好处是不需要额外的带宽，可以重用计算资源，缺点是需要hypervisor层面的服务链和引流API，并且可能将安全运营和业务运营搞在一起，容易出问题；后者的好处是给安全划分了独立的区域，安全运营相对独立一些，只要将流量牵引出来，就可以在安全节点内部做按需的服务编排，安全厂商是完全可控的，但坏处是流量外引和回注需要额外的带宽，安全节点拓扑上不能部署太远。具体使用哪种方式，跟云服务商的安全集成难度有关，跟云服务商的安全需求有关，跟安全厂商的方案也有关。

不过如上面的软件定义安全架构图所示，我们使用的是资源池方案，也就是说不管你的安全设备是物理的还是虚拟的，是硬件虚拟化还是VM，对上体现的都是安全能力. 举个例子，安全应用需要的对某个VM1的向外流量做控制，那么它将安全策略下发后，安全控制平台寻找满足要求的安全资源，最后可能找到了绿盟的下一代防火墙NF，也可能找到了天融信的防火墙，也可能找到了SDN控制器在某个虚拟交换机上下发流表，也可能找到Openstack启用安全组或FWaaS，等等。只要最终能满足对流量做访问控制，目的就达到了，这就是软件定义安全的思想：控制和数据分离、逻辑和实现分离。

理想情况下，安全应用几乎不需要改变，就能适配各种云平台（当然要解决安全控制平台与云平台的API对接问题）。根据过去两年与各种主流云服务商集成的经验，我们认为在计算节点中部署虚拟安全设备是有难度的，涉及到VM驱动硬盘QGA接口等问题、二层三层流量牵引问题。要知道VMWare NSX和华为Fushionsphere的方案都是将安全设备部署在计算节点内部，但NSX历经两年才完成与Checkpoint、PANW的对接，在去年Q3以后才ready，可想而知其中艰难。所以很抱歉，我在前面说的软件定义安全架构通过松耦合对接云平台和SDN控制器的推论似乎被打脸了，现实却是很骨感：网络架构师不明白为啥安全应用要这样那样控制流量，正如网络运维团队不理解安全运维团队的各种需求一样，所以在API层面的磨合会是一个短期痛苦、长期向好的过程。

企业毕竟要赚钱，安全毕竟在业务之后，所以权衡之后我们更倾向于硬件资源池的方案，做出这个选择是比较艰难的。当然在一些开放的云平台上，如Openstack/KVM/Openvswitch环境中，特别是部署如漏扫、流量分析这样偏软件层面的安全设备技术上可以说是毫无压力，所以虚拟化资源池也是OK的。

在硬件资源池的方案中，南北向流量可以如下图所示进行处理：

流量进入资源池后，根据安全需要，可以依次经过多个安全节点的虚拟防火墙、虚拟WAF和虚拟IPS等，处理完毕后进入云计算系统。东西向也是类似的，不过安全节点可以部署在每个机架上，处理该机架或邻近机架中VM的业务流量。

安全应用编排这部分跟SDN关系不太大了，我们现在在做一个应用商店的事情，可以将应用托管到云上，用户需要时可购买、快速部署和生效。感兴趣的群友可私聊。

3 To sum up：

1 软件定义安全不等于SDN安全，但两者有千丝万缕的关系
2 软件定义安全可以重构整个安全防护体系，特别是与大数据分析、机器学习等技术结合后，可做到对安全威胁的快速防护、快速检测、快速响应
3 安全资源池不仅仅适用于云环境，还可以部署在传统IT环境，其弹性、敏捷的特性可能会诞生出新的安全防护手段
4 软件定义安全是理念，最后可能融合到NG-SOC中

Q&A

Q1：这个要专用的安全设备吗？还是一般服务器就可以？
A1：在绿盟的实现中，技术上不需要专有的安全设备，因为目前大部分都可以跑在x86平台上

Q2:请问一下 现在虚拟化部署的比如漏扫 能实现对vmware虚机或者kvm openstack这些软件的漏扫吗？我的意思是能实现和硬件漏扫设备达到一样的效果吗？
A2：可以的，漏扫分为版本扫描和原理扫描，可以匹配软件版本，也可以通过漏洞原型验证。我记得前年绿盟云安全解决方案发布的时候，我讲的胶片中就列举了openstack和vmware的漏洞，不少还是高危的。我们自己搭建的openstack和docker这些系统也老被扫出问题，当然只通过版本扫描容易出误报，不过这是技术层面的事情了，原理上是ok的。

Q3：对于一个虚拟安全设备，一次可以对多个业务进行处理么？性能怎样？
A3：这个在安全设备中通常是由安全策略实现的，即下发多个策略，策略A防护网站A，启用xss防护、跨站防护等；策略B防护网站B

Q4：刚好您刚刚讲到了waf 我了解到一家云安全厂商 上海有云信息cloudguarding这家公司 他们的云waf是不是按照您说的那个架构来实现的
A4：我记得他们确实也是做waf的，不过不太清楚技术路线，可能物理和虚拟都有吧。不过单设备没什么用，还是要看他们有没有方案，是否能整合到自动化的平台中。

Q5：博士，数据中心可以的话，那么在DC化的机房，即运营商边缘DC或核心DC也可以进行相应的部署？是否有过这方向的开发计划？
A5：我们正在跟运营商做相关的工作，比如一些研发云和公有云。其实SDSec方案关注安全业务，只要能跟云管理平台做好对接，问题都不大

Q6：我想了解你们实际测试结果，对于策略在虚拟设备的执行，通常怎么推荐的？是一个设备一个策略，但对应多个业务？还是多个策略对应一个业务？
A6：通常而言，一个设备多个策略，性能要看宿主机和交换机（ovs+dpdk，linux bridge还是直通网卡），直通方式能做到跟物理机性能相当。不过我们现在在研究资源池的问题，当一个网站量比较大的时候，会启动多个虚拟安全设备，通过sdn做LB，此时一个设备理论上可能只有一个策略了，这块涉及到调度的QoS

Q7：请问刘博士大型网络的多层级联盟控制器和这套安全架构的融合有啥考虑吗？就是安全架构与多sdn控制器的协同
A7：我认为安全运营和网络运营/云平台运营是分离的，因为本质上这两块属于不同的运营团队，但两者是松耦合的，因为在SDDC环境中，两边都有开放的API，所以，安全平台需要通过一些事先双方确定好的方式（如SDN控制器的北向API）对网络的流量做（对于云平台业务）安全的操作，比如对恶意流量做阻断、mirror、重定向等，所以这要求sdn控制器提供相应的北向api，其实安全控制平台不关心sdn是一个控制器还是多个，是ad-hoc还是层级，只要你有一个api的访问入口即可，这样就简化了设计，明确了彼此的责权，这在网络运营和安全运营中是非常重要的，不然双方要打架的。

Q8：目前在现网中是否有哪些著名商用案例是贯彻SDS这个思想的？
A8：因为SDS还是比较新，所以现网中还比较少，落地的历程我也写了，不过去年我们中了两个项目都是相关的，相信今年还会有不少

----------------------------------------------------------------------------------------------------
SDNLAB微信直播群定位为面向网络创新技术的爱好者及从业人员进行交流、学习、分享，吸引了来自高校、云服务提供商、互联网厂商、设备厂商、运营商等单位的从业人员近千人，每周会组织定向的技术及业界动态分享，如果你有需要分享的请加微信：353176266联系。