本文提出了一种基于SDN技术的网络入侵阻断系统的设计方案,具有实践价值,是一种新的解决思路。 211工程三期CERNET 主干网升级工程中建设的 CERNET 主干网运行管理与安全保障系统中包含了一个大型分布式应急响应服务管理系统CHAIRS[1](Cooperative Hybrid Aided Incidence Response System),该系统已部署在 CERNET 的 38 个主节点,为各节点提供应急响应服务管理功能。对于CHAIRS系统提供的安全警报,需要各节点或校园网的安全管理员进行应急响应,发现并解决网络中存在的安全问题或安全隐患。一般而言,对威胁的响应主要包括相辅相成的跟踪分析和攻击阻断两种措施。但是传统的基于防火墙、黑洞路由[2]等技术的响应系统,在实际使用时存在着两方面的问题: 1)由于把过滤设备和边界路由器等路由设备完全分离开来,所以过滤系统并不能根据网络流量情况的变化,来实时自适应地对过滤措施进行调节; 2)当存在多个子网时,每个子网内的过滤设施需要分别改变各自的边界路由设置,缺乏统一调配,各个系统之间协作困难。 SDN技术的出现,为网络安全事件的应急响应带来了新的实现思路。 一方面,通过使用SDN硬件和软件,可以使得将传统的网络设备转变成为入侵阻断设备,对流量控制能力的自适应性大大加强。 另一方面,SDN的引入也使得应急响应较容易地实现集中控制,可以实现面向更大规模网络的安全事件响应。 基于上述设想,我们提出通过使用SDN技术设计实现一个入侵阻断系统(HYDRA,HYbrid Detection Response Agent),并在CERNET南京主节点的接入网边界进行了实验部署,实现对江苏省100多所入网高校的DDoS阻断保护和恶意流量样本采集。同时,各校园网可以选择自行部署该系统,提供本校园网内的网络安全事件应急响应能力。 本文首先在第一节中介绍了关于入侵响应的相关研究和目前的研究存在的不足。然后,在第二节中对系统的设计与实现进行了介绍。紧接着,在第三章中说明了系统的响应规则设计。第四章中对系统的实验工作进行了介绍。最后,在第五章中总结了全文。 1. 相关研究 目前SDN技术在网络安全应急响应方面的应用并不多,在这为数不多的应用中,D4A[3]项目和Bro Network Security Monitor[4](以下简称Bro Monitor)是比较有代表性的两个项目。 D4A(Defense4All Protection)项目是Opendaylight(以下简称ODL)项目的子项目。在D4A项目中,包括了从攻击检测到攻击阻断的完整功能。D4A项目的原理类似于传统的“黑洞路由”技术,通过改变交换机的转发表,将流量转发到“洗流中心”,对攻击流量进行过滤,然后将非攻击流量转发回原有的转发路径。目前,D4A项目主要存在两方面的不足,一方面,D4A和Opendaylight控制器紧耦合在一起,导致D4A项目缺乏跨控制器部署的能力。另一方面,D4A项目结构复杂,集成了检测和响应两个方面的内容,彼此之间紧耦合在一起,很难将D4A的响应部分与现有的IDS对接,形成自动化的响应。 Bro Monitor原本是一个NIDS,但是引入了SDN思想和技术后,使得Bro Monitor也具备了响应能力。Bro Monitor中的Event Engine会根据检测到的攻击事件,调用Network Control Framework来生成具体的响应规则并发送给OpenFlow Backend,然后OpenFlow Backend会根据具体的控制器不同,调用不同的接口。Bro Monitor由于OpenFlow Backend的存在解决了与控制器的耦合问题,但是还存在与其他IDS不兼容,无法分布式部署的问题。 2. HYDRA系统的设计 目前CENET主干网与省网主节点之间的拓扑结构如图1所示。攻击流量与恶意流量混杂在正常的流量中,通过主干网,然后经主干网边界路由器,进入到各个省网中,最终到达被攻击的网络设备,完成对网络设施和服务的攻击。
图1 HYDRA系统运行环境图 引入SDN技术后,将OpenFlow交换机串联在边界路由器的下行方向。HYDRA系统一方面会接收CHAIRS系统提供的攻击特征作为输入,根据攻击特征生成响应规则。另一方面,HYDRA系统允许网络管理员直接设置响应规则。响应规则分为两类,分别是阻断和采集。阻断规则会将匹配的报文丢弃,采集规则会在不影响报文转发的情况下,对报文进行采集。最终,所有的响应规则会被转化为流表项,并通过SDN控制器将流表项发送给交换机,从而实现对攻击流量的阻断,以及对恶意流量的样本采集。 在此拓扑结构下,HYDRA系统一方面可以根据实时网络状态对阻断策略进行调整,另一方面,也使得HYDRA系统具备了分布式部署,以及节点间协同响应的能力。 和D4A系统不同,HYDRA系统对攻击流量的阻断是在OpenFlow交换机上完成的。好处是简化了系统的部署的难度,无需设置专用的“洗流中心”,不足之处则在于,由于受到OpenFlow协议匹配字段的限制,无法对攻击流进行细粒度的筛选。相比于Bro Monitor,尽管都是在OpenFlow交换机上完成对攻击流量的阻断,但是HYDRA系统具备了分布式部署,多个网络协同响应的能力。
图2 HYDRA系统结构图 HYDRA系统结构图如图2所示,整个系统由五部分组成,包括控制节点,执行节点,采集器,控制器,SDN交换机。其中控制节点是全网唯一的,整个网络内只有一个控制器。其余四项的数量并不是固定的,可以根据需要进行调整。
图3 控制节点数据流图
4 实验与分析 实验与分析部分包括交换机测试和HYDRA系统实验两部分。 4.1 交换机测试 交换机测试的目的是验证交换机对OpenFlow协议的支持程度,测量OpenFlow Channel的性能,为系统的部署奠定基础 一般而言对网络设备的测试主要包括四个方面的内容,分别是一致性测试,互通性测试,性能测试以及鲁棒性测试。结合本实验中使用的SDN交换机,H3C S6300(以下简称S6300)交换机的实际情况,本实验中以一致性测试和性能测试为主。 一致性测试中使用RYU控制器,构造待测试功能的报文,验证交换机对HYDRA系统必须的Flow-table, Counter, Multi-Controller, 端口映射以及混合式转发功能验证。通过实验验证后,确认了S6300交换机作为混合式Oepnflow交换机可以满足对HYDRA系统的功能要求。 性能测试目标是测试交换机的OpenFlow Channel的性能。考虑到在HYDRA系统中,OpenFlow Channel中的消息,以流表修改和流表状态读取为主。所以在测试时,选择OpenFlow 流表操作的响应时间作为性能测试的指标。测量随着流表项和请求数量的不同,流表操作响应时间的变化。在OpenFlow协议中,流表修改报文,在正常情况下是没有反馈的,只有在流表修改失败的情况下才会返回错误消息。所以在测量时,使用流表状态请求(FLOW_STAT_REQUEST)报文的响应时间作为交换机的性能指标,考察性能与流表项数量以及OpenFlow Channel中消息数量之间的关系。实验原理如图7所示。实验结果如图8所示。
图7 性能测试原理图
图8 OpenFlow Channel性能测试结果图 根据性能测试的结果,可以发现在PPS一定时,响应时间随着流表项数的增加并没有太过明显的增加;但是随着PPS的快速增加,响应时间出现了快速增长。在PPS达到10000时,平均响应时间已经达到了1秒。在超过10000后,随着PPS的增加响应时间快速增加。考虑到HYDRA系统对OpenFlow Channel PPS要求并不高,所以H3C S6300交换机可以满足HYDRA系统的性能要求。 4.2 HYDRA系统实验 HYDRA系统实验中采用分光得到的JSERNET实时流量,实验拓扑如图9所示。实验内容分为两部分,分别是DNS报文采集实验与僵尸网络C&C报文采集实验。
图9 系统实验拓扑图 DNS报文采集时,考虑到DNS协议默认使用UDP协议进行传输,DNS服务器地址为53。所以设置响应规则内容为:IP协议号为UDP,端口为53,启动时间为2016-04-28 17:00:01,停止时间为2016-04-28 18:00:01动作为采集。
图9 DNS 采集报文实验 僵尸网络C&C报文采集中,对于僵尸网络控制器,不仅仅要采集其发出的报文,还要采集其接收的报文,从而才能在双向报文的基础上分析得到僵尸网络活跃情况和行为规律。于是,为每一个控制器设置一条响应规则,响应规则的源宿IP字段为控制器IP地址,动作为采集,启动和停止操作由管理手工控制。采集结果如图10所示。
图10 僵尸网络C&C控制器流量采集实验 5. 总结 本文使用SDN技术设计并实现了入侵阻断系统HYDRA。相比于同类系统,HYDRA系统可以不受网络拓扑的约束,在现有网络的基础上,将SDN交换机插入到网络边界,从而实现对攻击流量的阻断和追踪。实现更为灵活,更为敏捷的入侵阻断。当前系统尽管提供API供IDS调用,具备网络攻击自动化响应的能力,但是却没有提供具体的响应模型。未来的工作将主要集中于对网络攻击的自动化响应模型以及相关技术的研究上。 参考文献 [1] 吕少阳. CHAIRS系统运行管理与离线检测的设计与实现[D]. 东南大学, 2013. [2] 梁清. 基于BGP协议的流量过滤系统的设计与实现[D]. 东南大学, 2011. [3]Brooks M, Yang B. A Man-in-the-Middle attack against OpenDayLight SDN controller[C]//Proceedings of the 4th Annual ACM Conference on Research in Information Technology. ACM, 2015: 45-49. [4] Vern Paxson. The Bro Network Security Monitor (2015) [EB\OL]. https://www.bro.org/ [5] 马亚洲, 龚俭, 杨望. 面向应急响应的高速网络流量采集设计与实现[J]. Journal on Communications, 2014. [6]OSRG. Build SDN Agilely [EB\OL]. https://osrg.github.io/ryu/ [7]ONF. The OpenFlow Switch Specification (2015) [EB\OL]. http://ONF.org. [8] atarajan S, Huang X, Wolf T. Efficient conflict detection in flow-based virtualized networks[C]//Computing, Networking and Communications (ICNC), 2012 International Conference on. IEEE, 2012: 690-696. 作者单位:东南大学计算机科学与工程学院 2.1 控制节点 在HYDRA系统中控制节点是唯一的,控制节点负责协调各个执行节点以进行面向全网的安全响应,监控各个执行节点的运行状态。同时,为了简化设计,控制节点仅仅调用执行节点的接口,并不直接和控制器进行交互。对于执行节点而言,控制节点是一个特殊的用户。控制节点的数据流如图3所示。用户响应需求和CHAIRS系统提供的攻击特征,最终会被转化为规则发送给执行节点进行处理。 2.2 执行节点 执行节点是HYDRA系统的核心,负责执行该子网内的响应措施。执行节点的数据流图如图4所示。不同于控制节点,执行节点的用户包括网络管理员,CHAIRS系统以及HYDRA系统的控制节点。三类用户以不同的形式提交规则。最终由OpenFlow交换机和采集器完成报文的采集和阻断。 图4 执行节点数据流图 在完成响应规则的分发后,HYDRA执行节点会监控响应规则的状态,并根据规则的内容以及用户的控制命令,撤销对应的规则。 2.3 采集器 采集器根据执行节点的命令,对SDN交换机转发到采集器网卡的报文进行接收与保存。为了保证采集的性能,当前HYDRA系统中的采集器源自网络安全监测与应急响应系统[5](MONSTER, Monitor On Network Security and Tool for Emergency Response)的报文采集模块,采用了“0-COPY”技术,保证了报文采集的效率。 2.4 SDN控制器和交换机 HYRDA系统作为SDN应用,通过调用SDN控制器的接口,来完成对流量的控制。目前在HYDRA系统中采用了开源的RYU[6]控制器作为系统的控制器,通过调用RYU控制器的REST API,来完成对控制器服务的调用。最终,响应规则会被转化为OpenFlow流表项,发送到SDN交换机,完成对流量的控制。为了承载更大规模的流量,HYDRA系统支持在一个子网内部署多个SDN交换机。 3 规则设计 在HYDRA系统中,所有的响应需求最终都会被转化为响应规则。响应规则的匹配能力是否强大,可以执行的动作是否足够丰富,决定了系统对网络攻击的响应能力。 响应规则的设计首先受到OpenFlow[7]协议的约束(本文工作中采用的OpenFlow协议版本为1.3.1)。由于规则最终会被转化为OpenFlow流表项,所以响应规则中不能含有流表项不支持的匹配字段。其次,规则的设计需要兼顾响应的需求,尽可能多的匹配字段,意味着对目标报文的精确阻断;强大的规则表达能力,则可以避免冗余,提高系统的效率。最后,在规则中还需要提供对有效时间以及匹配报文数量的控制。在有效时间结束,或者匹配了足够多的报文后,规则便自动失效。这样,一方面可以减轻了响应控制的工作量,另一方面也可以避免大量无效规则对交换机流表项资源以及HYDRA系统资源的占用。 HYDRA响应规则(R)由三部分组成,分别是匹配字段(M),动作参数(A),以及启停条件参数(E)。一条完整的响应规则可以表述为R={M,A,E}。其中,匹配字段部分决定了哪些报文将被该规则处理,动作参数决定了匹配成功的报文将被如何处理,启停条件参数决定了规则有效期。 响应规则的组成如表1所示。为了保证系统的兼容性,在规则设计时,选择了OpenFlow协议中除入端口之外的所有必要匹配字段。同时为了提高规则的表达能力,额外添加了源宿IP字段和源宿端口字段。源宿IP字段相当于是源IP与宿IP通过“或”关系结合后产生的新字段。和其他匹配字段不同,源宿IP字段最多可以设置两个IP地址或者地址段。从而可以用一条规则实现对单个IP的出入流量,以及一对IP地址的交互流量的匹配。同时为了避免因同时设置源IP,宿IP,源宿IP而导致的歧义,在规则定义中,源宿IP的优先级要更高一些,在指定了,源宿IP字段后便会遮蔽源IP以及宿IP字段,使源IP以及宿IP字段失效。源宿端口的含义与源宿IP相同。需要说明的是,如果同时制定了源宿IP和源宿端口,会生成四条流表项。 表1 响应规则组成表 启停条件参数包括四项内容,分别是启动时间,超时时间,匹配的最大报文数,匹配的最大字节数。启动时间用来说明规则生效的时间,使用UNIX时间戳来表示,为0表示立即生效。超时时间则是用来说明在被触发后,规则的有效期,即超时失效时间,单位为秒,为0表示不超时。在规则匹配的报文数或字节数超过最大报文数或最大字节数后,规则便会自动失效,同样,字段值为0表示该字段无效。 图5 规则处理流程图 在响应规则被提交后,规则的处理流程如图5所示。在流表项生成时,对于阻断规则,最终生成的流表项指令列表为空,即不执行任何指令,匹配的报文便会被丢弃。对于采集规则,流表项的指令集会相对复杂一些,包括两条指令,分别是Apply-Action指令,以及Write-Action指令。Apply-Action指令将报文转发到NORMAL端口,即将报文送回传统的转发逻辑进行正常转发,Write-Action指令则是将报文转发到采集端口。从而在实现了报文复制的同时,将正常转发提到了优先位置,尽可能减少了样本采集对报文正常转发的影响。最后在冲突检测时,将当前待处理的流表项与所有HYDRA系统生成的、并处于有效状态的流表项进行冲突检测,具体算法采用了基于哈希表前缀树的冲突检测方法[8]。 最终实现完成后,规则数量与单条规则处理时间之间的关系如图6所示,可以发现随着系统中规则数量的增加,处理时间也随之增加,规则数量和处理时间之间是一个近似线性的关系,与理论分析的得出的时间复杂度O(n)的误差在可以接受的范围内。 图6 规则数量与规则处理时间 |