论文研究-一种基于OpenFlow协议的规则冲突检测与解决方案 .pdf

所需积分/C币:13 2019-08-15 16:06:30 961KB .PDF
收藏 收藏
举报

一种基于OpenFlow协议的规则冲突检测与解决方案,杨宁,彭扬,软件定义网络(Software Defined Network,SDN)是一种新型的网络架构,它将网络的控制功能和转发功能进行解耦,实现了网络控制的可编程化
团技论文在线 http:/www.paper.edu.cn 项格式,安全应用的规则会被新的最短路径规则所取代,使得安全应用的规则被避丌 要求更好的 安全应用 管理员等) 伟 S3 Path 2 2 防火墙 Path 1 图1-1安全应用规则被避开的情况 北向应用的种类很多,有管理员、普通应用、访客等,它们的安全等级应该依次递减, 上面的例子是一种安全等级低的应用规则取代∫安全等级高的应用规则的情况。 除了上述情况之外,由于流表项规则可以改写数据包地址信息,所以流表项的改写或者 新增有可能导致防火墙被绕过,这就出现了网终信息的潜在泄漏 针对SDN架构中的规则冲突情况,日前已经有一些团队进行了学习研究。 Phillip porras团队提出了基JNOx控制器的安全增强内核 Fornix,它利用别名集 归约的方式,将所有的规则用源和目的地址、端口、通配符等米表示。先把想要插入流表的 规则进行别名集约束,然后把已经存在流表中的规则进行别名集约束,将二者进行交集和动 作类型检测,这在一定程度上避免了冲突的发生。但是 FortNox存在误判的问题。比如一个 安全应用的规则是丢弃a到b的数据包,那么它的源别名集是(a),目的别名集是(c), 生成的别名集规则是:(a)(c) drop packet。如果网络中有三台交换机,流表分別是:匹 15 配a到b的数据包将源地址改为d;匹配d到b的数据包将目的地址改为c,匹配d到c的 数据包将日的地止改为b,那么通过别名集的检测方法是会得出规则冲突的结果的,但是实 际情况是数据包进行转发的时候并没有出现规则违反 王鹃团队在 Floodlight上实现了一个改进防火墙应用 flow verifier,这是基于 Flowpath的SDN安全策略动态检测和解决方法,通过比较有改写地址操作的 Flowpath Space 20 和防火墙的 Deny Authorization Space,对防火墙安全策略进行动态冲突检测和解决。但是此 团技论文在线 http:/www.paper.edu.cn 论文仅仅考虑了防火墙规则和其他流项规则之间的冲突,没有考虑防火墙之外的流衣项规 则之间的冲突情况。 本文借鉴了现有的SDN安全架构的成果,同时在它们的基础上在规则存储时加上规 则创建者和安仝等级两个标志位,并为了提高系统的反应速度加了一个规则缓存,若一个规 则不需要立即部署到网络中,可以先存到规则缓存中,定吋进行冲突检测并同步到交换机, 对于需要立即部署的规则就实时的进行冲突检测并解决。当我们的冲突检测模块检测到规则 之闫出现冲突时不能单纯的按照优先级的高低进行规则的丢弃,而要根据不同的情况进行不 同的解决 2规则冲突检测与解决方案实现 规则冲突检测解决方案分为规则转换、规则存储和冲突检测及解决几个功能,整个的模 块设计如图2-1所示。 安全应用 普通应用 (管理员等) 访客 北向接口 规则 规则创建者 (流衣项) 创建者优先缴 规则加工 规则处理 (添加额外标志位) 紧急程度 高 是 紧急稈度 判断冲突 冲突 低 否 定时 处理 规则仓库 规则缓存 SDN 规则 控制器 同步 南向接口 Host1 Host3 Switch 1 Switch2 Host2 Host4 图2-1规则冲突检测模块 整个的规则冲突检测解决模块分为规则转换、规则存储和冲突检测及解决几个功能, 15 面,论文会针对不同的功能分小节进行详细的介绍。 4 团技论文在线 http:/www.paper.edu.cn 2.1规则转换 因为数据包在匹配流表项时仅通过“匹配域”和“优先级”两个属性进行匹配,所以无 法识别规则是由谁发起,也尢法判断新的流表项是由哪个应用产生。为∫应对这种情况,我 们需要对流表项进行额外的处理,即对流表项添加三个标识位,分别是规则创建者、安全等 级和处理紧急度。 规则创建者用来标识是哪个应用给控制器下发的流表项,设置这个字段的目的是在进行 规则冲突检测之后可以追溯到规则创建者,进而进行相应的通知提盤。 安全等级是用来表示不同的规则创建者的安全等级。虽说每个应用有自己独有的规则创 建者标识,但是从整体上可以分为几大类,本文将规则创建者分为安全应用、用户和访客几 大类。其中安全应用的等级设为3,用户的等级设为2,访客的等级设为1。当然,这个安 仝等级的数量和配置应该是开放给管理员的,这里说的只是本文使用的安全等级。异络 中可能这种方式并不适用,因为不同的网络中管理员对安全等级的配置可能并不相同。 处理紧急度是防止一次进行过多规则冲突检测时导致的系统停顿,为了提高系统反应速 度,规则下发到控訇器后,根据紧急程度,伉先处理紧急度髙的,控制器接收到一个规则就 15 立即进行判断;而对于紧急度低的我们先进行缓存,然后每隔一段时间定时进行处理。 规则转换模块主要是将规则与上述三个标志位组合在一起然后存储到规则仓斥中,即我 们下面所讲的规则仓库中存储的规则都是带有标志位的 22规则缓存和规则仓库 因为流衣项的规则有处理紧急度,处理紧急度高的是直接进行冲突检测的,而处理紧急 度低的是先存储在规则缓存中,然后每隔一段时间将规则取出进行冲突检测。 规则仓库是存储通过了冲突检测的流表项。这里面存储的流表项就已经是带有新标志位 的了。而当我们将规则同步到交换机中的时候是不需要把这些标志位带上的,因为我们进行 冲突检测的时候是根据规则仓库里面的内容,所以交换机中的流表项不需要进行修改 规则缓存在前面提到过,当一条规则并不需要立即部署到网终中时,先将其存到规则缓 25 存中,然后每隔一段时间取出规则缓存中的规则进行冲突检测。而如果一条规则的处理紧急 度是“紧怠”时,规则缓存不起作用 23冲突检测 冲突检测是整个模块的重点,主要借鉴的思想是HSA( Header Space Analysis),它主 要帮助我们进行规则空间的生成。通过前面的两个模块,有效的流表项已经存到了规则仓库 里面,同时控制器又可以获得网络设备的拓扑关系,接下来的工作就是根据以上两个已知条 件将全网的数据流转发路径求出来 根据头部空间分析的思想,数据包在內络进行转发可以转化为数据包经过传递函数和拓 扑函数作用的过程。整个的转发过程可以用公式2-1来表示: T(h,p)=(r(…y(r(hp) (2-1) 其中,φ(h,p)表示包头为h的数据包经过p接口进入网络或者进行卜一跳转发。r(h;p) 团技论文在线 http:/www.paper.edu.cn 衣示数据包从一个交换机的p端∏转发到下一交换机的另·接冂的过程。 同样的,获得全网的数据流转发路径的思想就是:指定一个转发路径的起始位置,比如 其起始节点的头部信息,然后通过网络的拓扑结构,我们可以得到下一个交换机。获取交换 机中的流表项的头部信息(匹配域),如果出现重合,那么将下一跳交换机加入转发路径中。 然后依次进行下一跳交换机的获取以及目的地址和源地址的比较,直到找到目的节点。这样 条转发路径就生成了。 在进行上一珧目的地址和下一跳源地址进行比较的时候,本文采取将二者转换成二进制 然后求交集的过程。地址求交集是根据表2-1的规刈进行的 表2-1数据包包头对应位交集结果 Bi B 0 X 对两个数据包的包头进行交集运算的付候是对每一位进行交集运算,如果交集中有一位 结果是z则交集为空集,其他情况下是存在交集的。 基于上面的转发路径的生成过稈,我们可以根据已有流表项规则以及网络的拓扑结构生 成流表项的规则空间。 如果在部署模块的吋候,网络中已经存在一部分安全应用规则和流茯项,我们对这种情 IS 况需要进行额外的处理。因为部署模块之前,网络中并没有规则创建者的概念,所以在进行 冲突检测时只比较防火墙规则和交换杋中现有流表项规则。防火墙规则中只关注阻止数据包 从一台设备发往另一台设备的那部分,例如Src:10.0.0.1,Dst:10.0.0.3, Block,而对J其它 类型的防火墙规则不需要将其考虑在内。交换机中现有流表项规则主要用米获取全网的转发 路径,然后将其与防火墙规则进行对比,如果发现有重合的地方则调用下一小节的模块进行 20 冲突解决 而正式部署成功模块之后,我们进行规则冲突检测主要是分为两大类情况,一种是应用 规则的新增与更改,另一种是防火墙规则的插入与更改。对于已经存在的流表项规则我们将 其取出存到规则仓库中,并把所有的规则安全等级设为2,规则创建者置空。这只是一种可 能的解决方案,最理想的情况还是在网络枃建之初就部岧规则沖突检测模块。 25 应用规则的新增与更改 在进行应用规则的新增与更改的时候,我们需要进行两次冲突判断。一次是进行新增应 用规则与已有流表项之间的冲突检测,另一次是更新后的流表项规则与防火墙规则进行冲突 检测 在进行新增应用规则与已有流表项规则的冲突检测时,我们将新增的应用规则生成一个 30 规则空间,已有的流表项规则按照上述的转发规则生成一个转发空间,将两个规则空间进行 比较,通过重合的产生与否来判断冲突。进行冲突检测之后我们需要更新已有流表项空间。 6 团技论文在线 http:/www.paper.edu.cn 然后将其与防火墙规则再次进行冲突检测,因为新增的流表项规则之间可能存在依赖关系, 所以我们将规则空间更新之后可能会引入新的冲突,所以需要进行第次冲突检测,即将新 的流表项空间与防火墙空间进行对比,判断冲突的产生 在我们进行规则空间更新的时侯,一种做法是整体的重新生成,这样固然可以达到日的, 但是这样做的效率比较低,性能不好;考虑到我们对一个或某几个交换机流表项的更改影响 到的交换机只是它的附近范围,所以我们进行规则空间重计算的时候只更新目标交换机附近 部分即可,这样会人人提高模块效率。 防火墙规则的新增与更改 这种情况处理起来相对比较简单,我们只需要进行一次冲突检测。新增的防火墙规则如 果不是 Block规则,直接将*其应用到网络中即可,不需要进行冲突检测。新增防火墙规则如 果是 Block规则,那么就会产生规则被避开的可能性。所以在进行防火墙策略的改变或者新 増之前,先检査它与之前已经应用的防火墙策略之间存不存在依赖关系,然后进行防火墙策 路空间的重新生成,然后与已有流表项转发空间比较进行冲突检测。 更改防火墙规则时也是一样的道理,重新进行防火墙规则空间的计算并比较与之对应的 15 流表项规则空间检查是否存在冲突。 24冲突解决 当应用的规则与比其安全等级高的规则发生冲突时,还可以将其分为两种情况,一种情 况是流表项规则中地址信包含在高安全等级规则的地址信息中,即流表项规则是高安全等级 规则的一部分,这时候的处理策略比较简单,直接把出现冲突的流表项规灲移除就可以了。 20 但是如果只是流表项规则的一部分违反了髙安全等级应用的规则,这时候就不能简单的进行 流表项规则的移除,如果直接全部移除的话会导致不违反高安全等级应用规则的某些流表项 也被移除,当数据包到达交换机进行流表匹配的时候就会重新去控制器获取流表,加大控制 器的负担。木文采取在高安全等级应用规则指定的源主机的下一跳交换机和目的主机的上 跳主机插入拒绝指定信息流经过的流表项,同时保证新插入的流表项优宄级比较扃,这样是 25 保证此条规则被数据包优先匹配,然后将新的流表项也加入规则仓库中,同时更新规则空间。 比如一个高安全等级应用的规则是Src:Xxxx,Dst:xx00, Block一个主机的地址是1000, 如果在这个主机的前一跳交换札上加一条新的流表项,Src:xxx,Dst:x100, Forward。这时 候可以检测出高安全等级应用的规则和新的流表项之间存在冲突,且流表项规则空间是 (xxx→x100),高安全等级应用规则是(xxXX→xX00),前者的空间比后者的空间要小 30 所以在插入这个流表项的时侯是直接进行丟乔。假如这时的流表项是(xxXx→xxx0),这时 候处理冲突时不是进行简单的丢弃,而是在首尾交换杋上加上新的流表项,去除这种冲突情 况,同时将流表项的更改存储到规则仓库中。还有一种思想是将流表项规则中去掉与安全应 用冲突的部分,但是这种方式容易受到流表项更改的影响,所以本文采取的是第一种方法。 由于规灲在规则仓库中存储时我们保存」它的创建者标志位,在进行完冲突处理后,我 35 们可以根据规则的创建者标志位给相应的规则创建应用返回一个通知信息,告知它的规则变 7 团技论文在线 http:/www.paper.edu.cn 3规则冲突检测与解决方案测试 31冲突解决 本文仿真实验使用的操作系统是 Ubuntu1204,使用 Wininet来模拟SDN的网络设备 资源,通过在虚拟杋中运行 Wininet来建立模拟拓扑图结构和模块运行情况,采用的控制器 是 Open Daylight" Lithiun-SR3版本, Wininet是2.30dl,使用了 Wireshark进行网络的抓包 在进行规则冲突测试的时候,采用的网终拓扑如图3-1所示,这是利用 Wininet开放的 API接口自定义的网络拓扑。 ontro‖let 2 端口2 端口1 端口2 10.00.1 10.0.0.2 10.0.0.3 10.0.04 图3-1模拟网络拓扑图 32功能验证和性能测试 每个交换机中的流表项是默认流表项,即每个主机相互之间都是可以ping通的。仿真 中的防火墙规则是阻止h往h3发送数据包,所以我们的hl主机和h3主机之间的通信路径 是不通的。 15 若s2交换机中新埤如下流表项: Sre:10.0.0.1Dst:10.0.0.4 Action: modify Srclp to I0.0.0.2, modify dstIp to10.0.0.3 output:2(指定端冂) 这时候如果去进行 hI ping h4的操作,那么h4并不会接收到数据包,这时侯的数据包 仝都发送给了h3,如图3-2所示 国利技论文在线 http:/www.paper.edu.cn ile Edit view Go Capture Analyze statistics Telephony Tools nternal oeo rootooningubuntu: / home/ning/downlead/mininet/mininetfexamples 县劊三x。感Q中中争晋 cookie=ex2be60 duration=77:9, table,nD3 ockets:1, n_bytes Filter. s, table=o, n_ packets=30, n by tes=4 Time Source Destination Proto cookie=ex0 10.0.0,4acttcnsrdwsrc:1.,0.2,nodmwdst:1e.,0,3,op tion=1e. 238s, table=O, n_ packets=D, n bytes=o, ip, nN src=10.6 8H41.85/518,8,,2 81842.8456951.0.0.2 10.日.0.3 82843.8532510.0.0.2 16,8,0,3 nd: pirgal 18384.86167916.0.0,2 16,.0,3 ICMP int 87045.7257310.0.0.2 18.8.0.5 ting ping reachability 8845.87163510.0..2 8.8.b.5 89 61110.0 19884.87168310.0..2 16.0.63 191049.87210110.0.02 10,6.0,3 16% droppe (10/12 received) 93850.83716810.0.0.2 16,8,0,了 ICMP net> h1 ping 94851.875618.7 188.B.5 ICMP PING 10.0.0.4(16.6.6.4)5e(84)bytes of data 95852.87167210.0.0.2 196853.87168510.0..2 16.8.8.3 ICHP 10.0.0.4 ping statistics rane 195: 95 tyres on wire (784 bITS). 9B bytes captured (784 bITs) ackets transmitted, e received, 100x packet loss, time 1999ns P Fthernat IT, Srr a7.76 75 r& 13 Rp (a7 75 25 rR- 13: Re),I<t.Qh: fa: 6Q..ch 图3-2 hI ping h4的情况 可以看到,由于s2中新增的一条流表项,它是匹配源地址是h1、目的地址是h4的数 据包,将它的源地址改为h2,日的地址改为h3,这样在进行 hI ping h4的过程中,现在ping 不通了,但是hl发往h4的数据包最终发到了h3,这样就避开了防火墙规则。 在控制器中加上本文设计的规则冲突检测模块之后进行相同的实验,可以发现, hI ping h4之后并不会出现数据包转移的情况,去査看s2中的流表项可以发现新增的流表项不存在, 这表明规则冲突检测解决模块正确生效。对于其它的几利情况,包括:新増和修改安全应用 规则、新増和修改流表项规则乜进行了相应的实验测试,结果与预期一致,都是可以正确的 检测和处理冲突。 在整个模块的性能测试方面,由于流表项标志位中有处理紧急度这一指标,这一指标在 进行性能测试的时候并不容易进行衡量,所以我们测试时将处理紧急度均设置为了紧急,即 立即进行冲突检测和同步。 冲突检测的性能是受流表项的数量和网络拓扑的复杂程度(影响规则空间和转发路径图 15 的建立)的影响的,为了找出这两个因素对于冲突检测模块的影响程度,仿真时另外搭建了 个有9台交换机和28个主机的稍复杂的网络,交换机之间存在交叉连接的情况。针对上 面两种简单和复杂的网络,测试在流表项数日变化的情况下规则冲突检测模块的耗时,结果 如图3-3所示 简单拓扑 一复杂拓扑 3456789101112131415 流表项数量/100 20 图3-3简单拓扑和复杂拓扑下模块性能比较 9 团技论文在线 http:/www.paper.edu.cn 4结论 本文的⊥要工作是针对当前SDN架构中存在的规则冲突,包括应用规则(流表项规则) 与防火墙规则的冲突以及流表项规则之间的冲突,提出了一个基于 Open Flow协议的规则冲 突检测与解决方案,并通过搭建SDN网络实验平台对方案进行了具体实施验证。 本文设计的规则冲突检测与解决方案能够解决实际生产环境中冇可能出现的规则冲突, 它的主要创新点在于通过在控制器中进行流表项以及相应标志位的二次存储,同时借助头部 空间分析进行规则空间的生成,不但实现」应用规灲与防火墙规则的冲突检测,也实现了应 用规则之间的冲突检测。相比之前的策咯冲突解决方案做了改进,解决了 FortNOX安全内 核可能出现误判的问题,解决了 Flow Verifier防火墙应用只能检测流表项规则与防火墙规则 10之闰的冲突。同时,方案中对流表项规则新增的“处理紧急度”字段可以在一定稈度上缓解 控制器的压力,提高內络性能。 参考文献]( References) [1] D. thomas, Gray K Software defined networks[M].O'Reilly Media, Inc, 1005 Gravenstein Highway North, Sebastopol, CA 95472, 2013: 33-34 15 [2]雷葆华,王峰,王莤等.SDN核心技术剖析和实战指南[.北京:电子工业岀版 社,2014:199-200 Network Foundation. openflow switch specification[qL].2009.12(2013.4)[2014.09]http://www.opennetworking.org/sdn-resource/onf-sp ecifications 20 [4] Kazemian P, Varghese G, Mckeown N. Header Space Analysis: Static Checking For Nctworks[A]. Uscnix Confcrcncc on Nctworkcd Systcms Dcsign and Implementation[C] 2012:9-9 [5] Kazemian P, Chang M, Zeng H, et al. Real time network policy checking using header space analysis[A]. Usenix Conference on Networked Systems Design and Implementation(Cl 25 2013:99-112. [6 Porras P, Shin S, Ycgncswaran V, ct al. A Sccurity Enforcement Kcrncl for Open Flow Networks[A. HotSDN 12: Proceedings of the first workshop on Hot topics in software defined networks[C].2012121-126 「η王鹃,王江,焦虹阳,等.一种基于 Open Flow的SDN访间控制策略实时冲突检测与解决 方法[.计算机学报,2015,38(4:872-883 [8]minineT.[qL].http://www.mininet.org [9 Medved J, Varga R, Tkacik A, et al. Open Daylight: Towards a model-driven sdn controller architecture [A]. 2014 IEEE 15th International Symposium on IEEE[C]. 2014: 1-6 -10-

...展开详情
试读 10P 论文研究-一种基于OpenFlow协议的规则冲突检测与解决方案 .pdf
立即下载 低至0.43元/次 身份认证VIP会员低至7折
    抢沙发
    一个资源只可评论一次,评论内容不能少于5个字
    • 至尊王者

      成功上传501个资源即可获取
    关注 私信 TA的资源
    上传资源赚积分,得勋章
    最新推荐
    论文研究-一种基于OpenFlow协议的规则冲突检测与解决方案 .pdf 13积分/C币 立即下载
    1/10
    论文研究-一种基于OpenFlow协议的规则冲突检测与解决方案 .pdf第1页
    论文研究-一种基于OpenFlow协议的规则冲突检测与解决方案 .pdf第2页
    论文研究-一种基于OpenFlow协议的规则冲突检测与解决方案 .pdf第3页

    试读已结束,剩余7页未读...

    13积分/C币 立即下载 >