1.背景
IPsec策略在防火墙与安全网关中被广泛采用,限制访问或有选择地实施安全操作。在大规模分布式系统中,各个站点通过VPN隧道进行安全通信,同时每个站点均有具体安全策略的安全网关保护其信息,而一些子域如财务部还有特定安全策略的防火墙保护其敏感数据,所有进入或外出通信量的安全操作根据安全策略做出决定,因此正确地指定与配置安全策略非常重要。目前各种安全实施中,对单个安全网关主要是手工配置IPsec策略,其效率低下且易出错。同时实施中一些小的或不易发现的错误都可能导致整个网络大的安全漏洞。
IPsec是由IETF提出保护IP层上通信量的标准化协议套件,其基本功能是进行访问控制和有选择性地实施安全。IPsec策略主要有2部分:条件与操作,若条件满足,则执行操作。策略中条件与IP首部字段中某些值进行匹配,例如:src=A, dst=B是策略条件,则只有源地址为A,目标地址为B的IP分组才被选择;安全操作:拒绝、允许和IPsec操作,即所选择的IP分组可能被丢弃、允许通过或将IPsec操作中指定的安全功能应用于选择的IP分组。IPsec操作属性包括:安全协议(认证或加密)、算法、模式、from(起始)、to(终止)。条件和操作结合在一起得到策略简单表示:(src=A, dst=B->allow),分组与策略逐个匹配,直到发现合适的策略。
2.策略问题分析
错误策略可能导致通信阻塞或严重的安全问题,一些可能是由人为因素所引起,而一些即使有经验的管理员也很难发现的策略之间的交互性所造成。如图1所示。
情形11条加密隧道在H1与SG1之间创建来保护其敏感通信。为了监测通信量的内容,防火墙FW1配置有拒绝所有加密通信量的策略,则传输中所有分组都要被FW1所丢弃。
情形2H1配置有从H1到SG2的所有通信量被加密的策略,FW1是进行访问控制或有选择的进行安全实施的防火墙。FW1有如下简单的访问控制策略:(src=H1,dst=H2->allow)与(others->deny),因为加密隧道增加新IP首部(目标地址改变为SG1),则FW1将错误地丢弃应该允许通过的从H1->H2的所有通信量。
情形3site1内有财务部门site1.1,site2内有财务部门site2.1,且均有安全网关,授权相应安全策略来保护其财产。SG1.1决定从site1.1->site2所有通信量从SG1.1->SG2.1通过时都被保护,然而情况并非如此。首先,在SG1指定的策略中,如果没有调整针对上层隧道的选择器,则通信量将跳过低层隧道而缺乏从SG2->SG2.1所要求的保护。其次,也确实进行了调整,则通信量将经过2个隧道。通信量首先在SG1.1进行封装,当从SG1->SG2.1时再次进行封装,到达SG2.1解封以后,发现目的地址是SG2,于是通信量被返回到SG2,最后SG2再次对通信量解封,发现真实目的地址是SG2.1内部的主机,结果通信量以明文形式发送到其最终目的地址。然而最初要求是从SG2->SG2.1通信量被加密,但从以上分析可知:由于策略交互,并未达到既定目标。
以上结果很明显不是想要的并且也是错误的,从而策略配置完全正确的困难性主要存在于2个方面:
(1)隧道操作在选择器选择时造成的形势很复杂;
(2)尽管单个策略看起来满足单个目标,但是对所有的对象缺乏整体概念。
根据IETF IPSP(IP Security Policy)工作小组要求草案,IPsec策略必须满足下列要求:
- 要求在较高层次上定义策略以及高级策略必须能被清晰定义;
- 相信策略确实做了他所声称的,并且实现也是正确的;
- 必须能够支持复杂的策略管理方案,同时能控制和改变许多远程设备的策略;
- 在大型网络系统中,必须能授权不同实体使其能确定自己的策略;
- 所采用的机制必须不能对IPsec中任何协议做任何改动且不能依赖SA协商协议。
简单起见,高级策略称作安全要求,是高级目标,实现策略是具体计划以满足目标;IPsec策略管理主要任务是有效、清楚地表示高级安全要求。在安全要求中,只需指定对某些通信量的安全操作而不用关心具体参数。IPsec策略主要有4个要求:
(1)ACR(Access Control Requirement)安全的基本功能之一是进行访问控制,限制其仅能访问可信赖的通信量。指定ACR的简单方式是:flow id->deny(allow);
(2)SCR(Security Coverage Requirement)要求对通信量的保护能覆盖该区域内所有连接和节点。因为通信量经过的路径中某些节点需要监测通信量内容,可授权某些节点访问通信量内容。在具体策略中指定不同算法,而算法强度在要求中指定。在具体策略中选择合适算法达到要求强度,指定一个SCR被一定强度的安全函数保护。表示从“from”到“to”通信量简单方法是:flow id->protect(sec_function, strength,from,to,trusted_nodes)。只有从“from”到“to”保护域内的每一个连接与节点的通信量(除了可信赖节点)均提供足够安全保护时才能满足该要求。
(3)CAR(Content Access Requirement)一些节点可能需要访问通信量内容。然而,当加密隧道通过该节点时,通信量的内容便不能被访问。同样,由于需要修改通信量内容,如果认证隧道通过某些节点,便不能对通信量内容进行修改。为了防止某些节点访问通信量内容,应拒绝某些安全函数应用于这些节点:flow id->deny_sec(sec_function,access_nodes)。
(4)SAR(Security Association Requirement)为了执行认证/加密功能,需要指定某些节点与另外一些节点创建具有某些安全功能的SA。指定SAR的简单方式为:flow id->denySA (SA_peer1,SA_peer2,sec_functions)。仅当SA_peer1中的任何节点与SA_peer2中的任何节点均没有形成具有sec_functions的SA时,该要求才被满足。
3. 确定满足安全要求的策略
给定一个要求集合,发现满足所有这些要求的策略集合;否则返回一个“失败”报文。这里提出一个新方法,利用该方法生成的策略是正确的,即生成的策略集合确实能满足所有要求;该方法也是完全的,即一个要求就有一个解决方案;该方法也是有效的。从要求到策略的映射,即是低级策略是高级要求的具体实现。针对一个要求,可能有许多不同策略来满足。例如,从H1->H2对通信量保护可以表示为:(scr=H1, dst=H2->protect (sec_fun[ENC], strength[strong], from [H1], to[H2], trusted_noeds[Ra,Rb]))的SCR,通过一条或多条隧道连接来满足该SCR。可信赖节点不应用安全函数,而下一隧道再运用该安全函数。CAR与SAR限制在什么地方与怎样创建隧道。隧道配置以后,易确定访问控制策略,故在此不对访问控制要求做更多描述,关键是确定不违反CARs与SARs而又满足SCRs的隧道策略。
其中 {all} 表示中间所有路由网关是不可信赖的。在图2中,中间隧道是Req1弱加密保护域,顶部隧道表示Rew2保护域,最下层隧道表示Req3保护域。问题是满足Three_Req3的策略是什么?本文中利用该例来解释生成策略的方法。
4. 生成策略的束方法
4.1满足每束通信量要求的策略
把整个通信量分成多个互不相关通信量流的集合(称为束),每一束均遇到单个惟一的安全要求的集合。例如在Three_Reqs中共有4束,其中每束分别遇到不同的要求操作:(src=1.1.*, dst=2.1.*)->(Req1.action, Req2.action, Req3.action), (src=1.1.*, dst=w.*-2.2.*)->(Req1action, Req2.action), (src=1.*-1.1.*,dst=2.1.*)->(Req1.action, Req3.action), (src=1.1*-1.1.*, dst=2.*-2.1.*)->(Req1.action)。在束方法中分2步解决该问题:
(1)从给定要求中,把整个通信量分成互不相关的束;然后找出满足每束要求的子集;
(2)针对每束要求操作集合,生成其策略操作部分,束过滤器作为策略的选择器部分。
在本文中主要集中在这2个问题,首先解决第2步:根据每束的要求操作集合,怎样生成正确的策略操作。
4.2满足安全要求操作集合的策略操作
为了满足该区域内安全范围要求,需要通过该保护区域的一条或多条连接隧道。如图3所示。
假定上面隧道是认证隧道,下面隧道是加密隧道,分组在N1处被封装在N2又被封装,发送到N3,在N3处先解封再封装,再次被发送到N4。通过这样的配置,上面隧道链的认证范围是从N1->N3,下层隧道链的加密范围是从N2->N4。由于SARs,CARs或隧道重叠所强加的限制,一条不停止隧道穿过保护域几乎是不可能的。若把传输分组的最里面隧道叫基本隧道,对应SA为基本SA,那么基本隧道需要链接穿过保护域,提供给该域的保护范围。为了满足所有的SCRs,至少需要所允许的SA对级连在一起覆盖所要求的域。若把允许的SA对描述为边,那么就找到一条SA路径。若没有这样的SA路径来携带分组通过要求集合的保护域,那么该要求集合就一定不能被满足。
目标是创建满足所有SCRs,CARs与SARs的隧道,CARs与SARs限制在什么地方创建隧道。CARs与SARs允许生成的SAs叫作合格SAs;SCRs主要有2个功能:加密与认证。基本隧道只能提供一个功能范围,同时需要另外一条隧道在基本隧道上面提供另一功能范围,称之为第2 SAs,基本隧道与第2隧道一起提供不违反CARs与SARs的安全范围。通过图示方法解释找到合格的SA路径,目前有5个结点:N1, N2,…,N5,3个SCRs:(ENC,N2, N4, {N3}), (ENC, strong, N3, N5, {N4}), (AUTH, middle, N1, N4, ordinary,{N3})。同样也有CAR节点(ENC,AUTH,N4)以及3个SARs (N2,N5,ENC),(N1, N4, AUTH),(N1,N5,ENC)。
首先合并3个SCRs,获得对每个连接与节点的范围要求。利用数组sec_link与sec_node来表示范围要求,如sec_node[1]是1~2连接的范围要求。
由此可以看出N2是针对认证的不可信赖节点。为了找到基本SAs,需要如图4所示的3个图,其中ENC与AUTH图是为了确定第2个SA路径。
在图4中,边除了不被SARs允许之外都满足SARs,虚线表示没有SA连接(针对特定的安全功能没有安全范围要求)。针对CAR接点N4,跨越N4的所有边都要被删除(如15,25,35)。对不可信赖的接点N2,所有起止于N2的边都要从图4(c)中删除,而且为了防止在AUTH图中这些边成为第S2A的可能性,所有起止于N2的边也都要从AUTH图中删除,于是满足这些条件的图如图5所示。
在图5中,逐个考察所有边是否为合格基本边,边合格仅当在第2个功能图中对这个连接的跨度上有SA路径,例如:在图5(c)中14加密是合格的,因为在图5(b)中有连接134路径。该例中所有边都是合格的,因为他们每个均有第2 SA为第2个安全功能提供必要安全范围。最后找到通过145的最短路径,满足所有要求的隧道配置如图6所示。在连接45上针对AUTH功能没有隧道,是因为图5(b)中连接选择是0SA边。
4.3 束与顺序
利用束方法,解决策略问题主要分2个步骤:
(1)把通信量分成不相关的束,然后找到针对每束的要求列表;
(2)利用策略生成方法确定策略操作部分。在前面已经对第2步进行了详细的描述,此处对第1步进行讨论:怎样把通信量分成许多互不相关的束,并得到每一束要求列表。
为了把通信量分成束,需要计算过滤器的交集与差集。在Three_Req3中,F1∩F2∩F3遇到Reg1.action,Reg2.action,Reg3.aciton。F2F3遇到Reg1.action 和Reg3.aciton,F3F2遇到Reg1.action和Reg2.action。计算K个过滤器交集的简单方法是把每个过滤器与已经存在的过滤器逐个进行比较,最后确定出交集。
为了把通信量流分成束,需进行不但耗时而又占用空间的差集计算,为此提出一种新方法把通信量流分成束。该方法将增加新的过滤器与策略,同时尽可能保留原来策略。例如:为通信量(1.*, 2.*)已经创建了一个隧道,针对通信量(1.1.*, 2.*)又有一个新的要求,并不改变已经存在的隧道,但需要在已经存在策略顶部增加新策略即过滤器(1.1.*, 2.*),首先检测新的过滤器,仅有(1.*-1.1.*, 2.*)的通信量才被此策略所选择。这也获得了好像是为2个互不相关的束:(1.1.*, 2.*) 和 (1.*-1.1.*, 2.*)创建策略一样的结果。
目前有3个主要问题:
(1)为生成策略的选择器部分,需要计算束过滤器;
(2)利用策略生成方法生成策略操作部分之前,怎样获得每束的要求列表;
(3)为保证生成正确的策略,怎样保证把策略插入到合适的位置。
为了方便要求与顺序追踪采用关系树机制。例如在Three_Reqs中,有3个过滤器:
F1 (1.*, 2.*), F2 (1.1.*, 2.*), F3 (1.*, 2.1.*)。如图7所示,首先处理具有Reg1的过滤器F1,当Reg2(具有过滤器F2)提出后,则F2为F1的孩子,因为F2被F1包含;当Reg3提出时,计算迭加部分生成具有Reg3的过滤器F4,因为F4被F2包含,则F4是F2的孩子;又因为F3被F1包含,则F3作为F1的孩子插入到关系树中。
利用关系树,可以解决上面提到的3个问题:为在关系树中选择器是节点过滤器的每个节点生成策略集。每个节点要求列表是该节点本身与他所有上级的要求的级连。只要特定结点的策略被正确插入到他所包含的最近结点策略的顶部,那么策略顺序就是正确的,因此利用上面的关系树生成下面4个策略的集合{plicy_set1, policy_set2,policy_set3,policy_set4}来满足给定要求的集合:{{Req1}, {Req1, Req2}, {Req1, Req3},{Req1,Req2,Req3}}。
策略集合的顺序是:{policy_set4, policy_set2, policy_set3, policy_set1},策略集合的过滤器是{F4,F2,F3,F1},于是获得与计算不相关的束:{F4,F2F4,F3F4,F1F2F3}一样的结果。
在Three_Req3例子中,4束{(1.1.*, 2.1.*), (1.*-1.1.*, 2.1.*), (1.1.*, 2.*-2.1.*), (1.*-1.1.*, 2.*-2.1.*)} 分别面对这样的要求 {(Req1, Req2,Req3), (Req1, Req3), (Req1, Req2), (Req1)} , 除了3个SCRs之外,还有CARs节点,即(ENC, AUTH, SG1) (ENC, AUTH, SG2) ,则策略结果如下图8所示。
5. 结论
目前网络的安全性问题日益突出,基于IPsec的VPN方案是解决此问题的良好途径,而安全策略问题的指定与配置又是IPsec/VPN中的关键所在。本文提出了一种解决安全策略问题的方法,通过把整个通信量流分成互不相关的束,发现满足每束的要求;然后生成每束的策略解决了IPsec/VPN中的安全策略问题,具有很好的现实意义。同时根据该方法找到合适的算法是需要进一步做的工作。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
思科通过收购Duo来增强云安全性
思科宣布以23.5亿美元收购Duo Security公司,此次收购将为该网络公司的云安全产品组合增添了两步身份 […]
-
Accenture公司的Tammy Moskites探讨CISO职位变化
首席信息安全官(CISO)职位仍在不断发展和成熟,对于这些变化,或许没有人比Tammy Moskites更有话 […]
-
企业没有从过往网络安全事件中吸取教训
根据Pluralsight作家同时也是安全专家Troy Hunt表示,反复发生的网络安全事件表明企业仍然在基础 […]
-
微软公司提供IE浏览器零日“双杀”漏洞补丁
微软公司2018年五月份的周二补丁日提供了IE浏览器零日漏洞补丁修复,该漏洞上个月已经被外部攻击者利用。(译注 […]