CN102347870B - 一种流量安全检测方法、设备和系统 - Google Patents
一种流量安全检测方法、设备和系统 Download PDFInfo
- Publication number
- CN102347870B CN102347870B CN201010243679.9A CN201010243679A CN102347870B CN 102347870 B CN102347870 B CN 102347870B CN 201010243679 A CN201010243679 A CN 201010243679A CN 102347870 B CN102347870 B CN 102347870B
- Authority
- CN
- China
- Prior art keywords
- gateway device
- initiator
- ipsec
- responder
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种IPSec流量安全检测方法、设备和系统,包括:发起方通过网关设备向响应方发起IPsec通信的IKE请求时,网关设备截获IKE请求,提取该请求的源地址和响应方对应的目的地址并保存在本地数据表中;分别与所述发起方、响应方进行加密协商,并分别建立与发起方、响应方的IPsec安全隧道;发起方将需要发送给响应方的数据包采用与网关设备协商的加密方法进行加密,通过与网关设备建立的IPsec安全隧道发送至所述网关设备;网关设备收到所述数据包后,通过与发起方协商好的加密方法对该数据包进行解密后,进行深度包检测;如果深度包检测通过,网关设备将该数据包通过与所述响应方协商好的加密方法进行加密后,通过与所述响应方建立的IPsec安全隧道发送至所述响应方。
Description
技术领域
本发明涉及网络通信技术,特别是指一种互联网协议安全(IPSec,Internet Protocol Security)流量安全检测方法、设备和系统。
背景技术
近二十年来,互联网用户和终端数目的急剧增长、网络技术的飞速进步,证明了具有简单、开放的设计理念的互联网的巨大成功。然而,正是由于互联网的简单和开放,互联网也面临着越来越多的新的要求和挑战,例如安全性差,难以控制和管理,面对故障和攻击难以及时做出反应等。随着互联网的进一步普及,这些问题越来越引人注目,网络生存性所需要应对的威胁也从单纯的随机故障扩展到了包括人为攻击在内的各种异常。人们普遍认识到,未来的网络应该具有新的特性,使得用户在使用它的时候更加方便的同时,也更加安全;也应该使得网络的运营者在面临各种异常状态时能及时地发现,并有效地做出反应。
达到更高的安全性往往需要对网络的控制和管理能力提出更高的要求。为了实现真正的可信和安全,网络必须具有对用户行为高度的控制和管理能力。
随着IPv4地址的耗尽,互联网向IPv6(Internet Protocolversion 6)过渡已经迫在眉睫。IPv6是IETF为IP协议分组通信制定的新的因特网标准,在IPv6中IPsec(Internet ProtocolSecurity)成为了必选内容。这样做的目的,是为了随着IPv6的进一步流行,IPsec可以得到更为广泛的使用。IPsec是保护IP协议安全通信的标准,通过对IP包为单位的信息加密来对传输途中的信息包进行加密或者防篡改的一种方法。第一版IPsec协议在RFCs 2401-2409中定义。在2005年第二版标准文档发布,新的文档定义在RFC4301和RFC4309中。
虽然IPsec可以保证通信期间用户端到端的信息安全,然而过多的使用IPsec协议将会使得通信内容完全加密,无法达到对互联网内容及流量可管可控的要求。同时由于IPsec的加密,无法实现队列调度,更加难以管理。因此,在IPsec普及之前,必须采用适当的方案能够在维持IPsec安全性的同时,一定程度上实现对用户行为、网络运行状态和网络资源的有效控制和流量和内容的管控。这种能力不仅对于建设安全的网络是必不可少的,而且对于未来网络的健康发展和持续的技术革新,都是必不可少的。
目前,有两种技术来实现IPsec下的包检测。
第一种方案是基于流的的IPsec深度检测,通过对IPsec VPN报文序列的上下文的分析和检测,按照标准的IPsec VPN报文序列格式去解析,定位SA协商请求报文和协商响应报文,并提取VPN关键信息。对于接收到的VPN序列,按照标准的IPsec VPN报文序列格式去解析,进行上下文的分析和检测。如果能正确解析,那么该IPsec VPN报文序列是标准的,如果不能解析,那么说明IPsec VPN报文序列是非标准的或者是伪造的。对于非标准报文,根据上下文信息特征分析检测出哪个报文是协商响应报文,再对这些非标准的报文进行关键字段的提取,如果根据上下文特征还检测不出来,则认为是伪造的IPsec VPN报文。
另一种检测方式是对上面一种方式的改进,该方式利用报文自身的偏移量模式特征,不依赖于上下文信息,而使用基于报文偏移量匹配的方法检测出来的协商响应报文,找到哪个是非标准的协商响应分组,然后在非标准的协商响应分组中的SA_payload字段中提取其中算法信息。这种方法可以检测使用不符合中国密码管理委员会政策规定的算法,或者是VPN生产厂家不按标准协议格式设计的非标准的IPsec协议的VPN,从而判断伪造的IPsec报文,并按照设置安全规则进行报警或记录日志的处理。
虽然现有技术能够识别和分析IPsec VPN报文是否为伪造,是否是非标准格式报文,但以上两种方案都只能通过序列中的格式来分析其加密方法如何,是否符合标准,即都仅支持对加密格式的检测。而加密后的内容仍然无法被检测到,无法对不同流量类型进行区别处理,更无法对于关键字进行监控监测,无法实现真正对该报文的深度检测。另外,伴随IPv6的普及,可能带来IPsec的滥用情况,也会给网络的信息和通信安全带来一定的隐患。
发明内容
有鉴于此,本发明的目的在于提出一种基于网关的对IPsec深度包检测方法、设备和系统,通过对IPsec的深度包检测,判断不同流量类型分配系统资源,设定不同的队列调度机制,实现差别服务,保证通信质量,防止系统高负荷运行状态下,系统丢弃关键流量,导致网络性能迅速恶化;另一方面也可以通过这个技术实现对关键字词的检测和安全监控。
基于上述目的本发明提供的一种IPSec流量安全检测方法,包括:
A.发起方通过网关设备向响应方发起IPsec通信的IKE请求时,所述网关设备截获IKE请求,提取该请求的源地址和响应方对应的目的地址并保存在本地数据表中;
B.所述网关设备分别与所述发起方、响应方进行加密协商,并分别建立与发起方、响应方的IPsec安全隧道;
C.所述发起方将需要发送给所述响应方的数据包采用与所述网关设备协商的加密方法进行加密,通过与所述网关设备建立的IPsec安全隧道发送至所述网关设备;
D.所述网关设备收到所述数据包后,通过与发起方协商好的加密方法对该数据包进行解密后,进行深度包检测;
E.如果深度包检测通过,所述网关设备将该数据包通过与所述响应方协商好的加密方法进行加密后,通过与所述响应方建立的IPsec安全隧道发送至所述响应方。
可选的,该方法所述步骤A进一步包括:
101,所述发起方向所述响应方发起IPsec通信的第一IKE请求;
102,所述网关设备监听到发起方当前发出的如果是端口号码为500或者4500的UDP数据包,则判定为该发起方准备与安全区域外部建立IPsec连接的所述第一IKE请求;
103,所述网关设备截断当前第一IKE请求的数据包,提取该数据包的源地址和响应方对应的目的地址并保存在本地数据表中,同时设置标识以表示该发起方希望建立安全连接;
104,所述网关设备回复所述发起方IKE请求失败通知消息,在该消息种携带该网关设备自身地址。
可选的,该方法所述网关设备启用LibpCap或者WinpCap功能进行监听。
可选的,该方法所述步骤B进一步包括:
201,所述发起方向所述响应方发起IPsec通信的第一IKE请求后,如果收到所述网关设备的失败通知消息,提取所述网关设备地址;向所述网关设备发起第二IKE请求,请求协商沟通使用的加密算法和密钥;
202,所述网关设备收到所述第二IKE请求后,查询本地数据表,如果发现表示该发起方希望建立安全连接的标识,则判定该发起方曾发送过所述第一IKE请求,并在所述数据表中提取出所述目的地址;
203,所述网关设备向所述目的地址对应的响应方发起第三IKE请求;
204,所述网关设备与响应方之间协商加密方法,协商成功后,响应方返回第三IKE请求成功消息,网关设备与响应方建立IPsec安全隧道;
205,所述网关设备向发起方返回第二IKE协商成功的响应消息,并将数据表中的所述标识复位;网关设备与发起方通过IKE确认双方身份后,协商加密方法,网关设备和发起方建立IPsec安全隧道。
可选的,该方法所述加密方法为AH和/或ESP加密协议。
可选的,该方法所述步骤E后进一步包括:通信完毕后,所述网关设备拆除与发起方、响应方建立的两条IPsec安全隧道,并从数据表中删除该发起方和响应方的对应条目。
可选的,该方法步骤D所述深度包检测包括:通过特征字检测,匹配固定位置、变动位置及状态特征字,识别业务流中特定数据报文,确认业务流承载的应用;
对于控制流和业务流是分离的业务,先识别出控制流,并根据控制流的协议对其进行应用层内容的解析,从协议内容中识别出相应的业务流。
可选的,该方法步骤E所述深度包检测通过后,所述网关设备进一步通过定义的策略完成安全流量管控和流量的优化。
可选的,该方法所述优化过程进一步包括:识别出各类业务流,并根据网络配置的组合条件,对业务进行整理统计,使得运营商和管控部门可以直观的统计网络的业务流量分布和用户的各种业务使用情况。
可选的,该方法如果所述深度包检测没有通过,所述网关设备向发起方发送通信失败的响应消息,并拦截该数据包并在系统中添加告警项,触发相关安全事件。
可选的,该方法所述网关设备位于发起方所在网络的出口。
基于上述目的本发明还提供了一种用于IPSec流量安全检测的网关设备,包括:
IPsec检测功能模块,用于截获发起方发起的IPsec通信的IKE请求;
地址关联功能模块,用于提取IPsec检测功能模块截获的所述IKE请求的源地址和响应方对应的目的地址,保存在本地数据表中;
IPsec连接发起模块,用于发起与所述发起方、响应方的加密协商,以及分别建立与发起方、响应方的IPsec安全隧道;
IPsec用户认证模块,用于收到发起方需要发送给响应方的数据包后,通过与发起方协商好的加密方法对该数据包进行解密,发送给安全检测服务器进行深度包检测;
IPsec数据包转发模块,用于接收所述安全检测服务器的检测结果,如果深度包检测通过,所述网关设备将该数据包通过与所述响应方协商好的加密方法进行加密后,通过与所述响应方建立的IPsec安全隧道发送至所述响应方。
可选的,该网关设备所述IPsec检测功能模块,监听到发起方当前发出的如果是端口号码为500或者4500的UDP数据包,则判定为该发起方准备与安全区域外部建立IPsec连接的所述IKE请求,并截断该数据包。
基于上述目的,本发明还提供了一种用于IPSec流量安全检测的系统,包括:如权利要求12或13所述的网关设备,以及与该网关设备相连用于深度包检测的安全检测服务器。
可选的,该系统所述深度包检测包括:通过特征字检测,匹配固定位置、变动位置及状态特征字,识别业务流中特定数据报文,确认业务流承载的应用;
对于控制流和业务流是分离的业务,先识别出控制流,并根据控制流的协议对其进行应用层内容的解析,从协议内容中识别出相应的业务流。
从上面所述可以看出,本发明提供的IPSec流量安全检测方法、设备和系统,突破传统思维,将原本的两个客户间建立IPSec隧道改为客户端与网关以及网关和响应端的IPsec隧道,通过建立两段隧道提供在网关对IPSec流量进行安全检测,并实现对加密的IPsec进行深度包检测,既保证了通信的安全性,又能够进行安全流量管控。
具体包括如下优点:
1)采用深度包检测技术可以对应用流中的数据报文内容进行探测,从而确定数据报文的真正应用,实现流量的监管,保证网络的安全。进一步通过深度包安全检测,能够判断不同流量类型,以此分配系统资源,设定不同的队列调度机制,实现差别服务,保证通信质量,防止系统高负荷运行状态下,系统丢弃关键流量所导致网络性能迅速恶化;另一方面也可以通过这个技术实现安全监控,实现对关键字词的检测。由于在客户端和网关之间仍采用IPsec连接,在链路上保证了适当的方案能够在保证IPsec安全的同时,一定程度上实现流量和内容的管控。同时本发明可以用于其它加密各种协议的深度包检测和安全流量管控。
2)系统组成简单。可直接利用现有网络中的网关设备加以硬件或软件的改造。
3)兼容性好。由于在客户端和网关之间仍采用IPsec连接,在链路上保证了适当的方案能够在保证IPsec安全的同时,一定程度上实现流量和内容的管控。很好地做到了与现有协议兼容。同时本发明可以用于其它加密各种协议的深度包检测和安全流量管控。
附图说明
图1为本发明实施例IPsec DPI系统组成结构示意图;
图2为本发明实施例网关设备设备内部结构示意图;
图3为本发明实施例IPsec示意图;
图4为本发明实施例IPsec IKE流程示意图;
图5为本发明实施例IKE初始化示意图;
图6为本发明实施例IPsec发现流程示意图;
图7为本发明实施例网关设备协商并建立IPsec安全链路的流程示意图;
图8为本发明实施例发起方向网关设备协商沟通使用的加密方法的流程示意图;
图9为本发明实施例网关设备向响应方发起IKE协商请求IKE3的流程示意图;
图10为本发明实施例网关设备向发起方确认IKE2的流程示意图;
图11为本发明实施例发起方和响应方之间两段安全隧道的结构示意图;
图12为本发明实施例通过深度包检测的流程示意图;
图13为本发明实施例AH报头在IP包的位置示意图;
图14为本发明实施例未通过深度包检测的流程示意图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白,以下结合具体实施例,并参照附图,对本发明进一步详细说明。
本发明IPSec流量安全检测系统的一个实施例,参见图1所示。主要包括:网关设备和安全检测服务器。其中,
网关设备11:放置在发起方主机A的安全网络域和响应方主机B网络之间,为支持三层路由功能的网关设备,可以实现用户数据流的中继和路由功能。在本发明优选实施例中,网关设备11位于安全区域边缘出口位置,实现IPsec检测、用户认证、响应地址关联及IPsec数据包转发的功能。
安全检测服务器12:为网关设备11侧旁挂的接入用户IPsecDPI设备,该安全检测服务器12可以在该网关设备的节点对IP包实现深度包检测功能。虽然现在非法应用可以隐藏端口号,但应用层的协议特征较难以隐藏,该安全检测服务器12的能够高效的识别出网络上的各种应用并进行内容审查。
可选的,所述安全检测服务器12也可以设置在所述网关设备11内部。
参见图2所示,为网关设备内部与本发明相关部分的结构示意图。主要包括:
IPsec检测功能模块,用于截获发起方发起的IPsec通信的IKE请求;
地址关联功能模块,用于提取IPsec检测功能模块截获的所述IKE请求的源地址和响应方对应的目的地址,保存在本地数据表中;
IPsec连接发起模块,用于发起与所述发起方、响应方的加密协商,以及分别建立与发起方、响应方的IPsec安全隧道;
IPsec用户认证模块,用于收到发起方需要发送给响应方的数据包后,通过与发起方协商好的加密方法对该数据包进行解密,发送给安全检测服务器进行深度包检测;
IPsec数据包转发模块,用于接收所述安全检测服务器的检测结果,如果深度包检测通过,所述网关设备将该数据包通过与所述响应方协商好的加密方法进行加密后,通过与所述响应方建立的IPsec安全隧道发送至所述响应方。
可选的,所述IPsec检测功能模块,可通过监听端口号码的方式识别所述IKE请求,例如监听到发起方当前发出的如果是端口号码为500或者4500的UDP数据包,则判定为该发起方准备与安全区域外部建立IPsec连接的所述IKE请求,并截断该数据包。
这里所涉及的IPsec是安全隧道的一条重要协议,IPsec协议族:主要对IP协议分组进行加密和认证的协议族。IPsec协议族主要包括:(1)保护分组流的协议;(2)用来建立这些安全分组流的密钥交换协议。前者又分成两个部分:加密分组流的封装安全载荷(ESP)及较少使用的认证头(AH),认证头提供了对分组流的认证并保证其消息完整性,但不提供保密性。安全分组流的密钥交换协议IKE协议是唯一已经制定的密钥交换协议。
其中,AH协议主要用于完成通信期间用户的身份验证,提供对整个数据报的完成性保护,以IP地址为标识;AH协议为IP通信提供数据源认证、数据完整性和反重播保证,它能保护通信免受篡改,但不能防止窃听,适合用于传输非机密数据。
ESP协议用于保护通信期间传递内容的安全性;由于AH不能对整个数据包提供完整的安全检察,所以IPsec引入了ESP协议为IP数据包提供完整性检查、认证和加密。ESP同时提供了安全服务和保密性服务,加强了IP包机密性并可防止篡改。ESP服务依据建立的安全关联SA是可选的。ESP可以单独使用,也可以和AH结合使用。ESP与AH各自提供的认证其根本区别在于它们的覆盖范围。在端对端的隧道通信中,ESP需要对整个数据包加密;但一般ESP不对整个数据包加密,而是只加密IP包的有效载荷部分,不包括IP头。
本发明IPSec流量安全检测方法主要包括:
发起方通过网关设备向响应方发起IPsec通信的IKE请求时,所述网关设备截获IKE请求,提取该请求的源地址和响应方对应的目的地址并保存在本地数据表中;
所述网关设备分别与所述发起方、响应方进行加密协商,并分别建立与发起方、响应方的IPsec安全隧道;
所述发起方将需要发送给所述响应方的数据包采用与所述网关设备协商的加密方法进行加密,通过与所述网关设备建立的IPsec安全隧道发送至所述网关设备;
所述网关设备收到所述数据包后,通过与发起方协商好的加密方法对该数据包进行解密后,进行深度包检测;
如果深度包检测通过,所述网关设备将该数据包通过与所述响应方协商好的加密方法进行加密后,通过与所述响应方建立的IPsec安全隧道发送至所述响应方。
下面对本发明IPSec流量安全检测方法的一个具体实施例进行详细说明。
本实施例方法主要包括三个过程,两个加解密过程和一个DPI过程:
1)加解密过程A:
本实施例中首先需要对IPsec包进行处理,使得网关设备可以检测其内容。开始IPsec流深度检测前,网关设备设备G判断用户准备使用IPsec协议。IPsec协议族主要由AH协议、ESP协议及IKE协议组成。这三种协议中,AH、ESP既可单独使用也可组合使用,但在IPsec加密前,作为唯一的密钥交换协议,他们都需要由IKE首先商定加密的协议和密钥,协商完毕后,双方再根据需要选择AH、ESP加密方式完成信息安全传送。因此通过判断用户启用IKE协议,网关设备G判断主机A准备开始使用IPsec加密数据。图3为IPsec图示。
根据现有技术,IPsec协议族主要由AH协议、ESP协议及IKE协议组成;其中AH协议主要用于完成通信期间用户的身份验证,提供对整个数据报的完成性保护,以IP地址为标识;ESP协议用于保护通信期间传递内容的安全性;IKE协议主要负责密钥管理,可以动态建立和维护SA,以IP地址或者cookie作为身份标识。
IKE协议结构:IKE协议主要负责密钥管理,可以动态建立和维护SA,以IP地址或者cookie作为身份标识。IKE属于一种混合型协议,由Internet安全关联(SA)、密钥管理协议(ISAKMP)和两种密钥交换协议(OAKLEY与SKEME)组成。IKE创建在由ISAKMP定义的框架上,沿用了OAKLEY的密钥交换模式以及SKEME的共享和密钥更新技术,还定义了它自己的两种密钥交换方式。
IKE包括了Internet安全关联(SA)、密钥管理协议(ISAKMP)和两种密钥交换协议(OAKLEY与SKEME),属于一种混合型协议。分析IKE协商的过程,可分为两个阶段:
第一阶段,协商通过两种模式的信息交换创建一个通信信道(IKE SA),并对该信道进行验证,为双方进一步的IKE通信提供机密性、消息完整性以及消息源验证服务。这两种模式的交换包括对身份进行保护的“主动模式”交换——交换加密策略、DiffieHellman共享值、Nonce和身份验证,确认双方身份以及根据基本ISAKMP文档制订的“积极模式”交换——在沟通了协商策略后,仅需要相应方认证发起方秉提供发起方的在场证据。可参见图4所示IPsec IKE流程图。
第二阶段,使用已建立的IKE SA建立IPsec SA,使用快速交换用来发起和响应房的在场证据而无须消息双方身份。另外,IKE自己还有两种交换:1、为通信各方间协商一个新的Diffie Hellman组类型的“新组模式”交换。新组模式属于请求和响应交换,交换过程中响应方仅需确认发起方的提议;2、在IKE通信双方间传送错误及状态消息的ISAKMP信息交换,仅用于发送错误及状态提示消息。可参见图5所示的IKE初始化图示。
本实施例根据IKE协议流程设计的IPsec发现流程参见图6所示。
步骤101,在预共享密钥认证的主模式下,由于发起方的主机A和响应方的主机B首先需进行IKE SA协商,这时发起方主机A向响应方主机B发起IKE请求1。
步骤102,在网络出口的所述网关设备G对接收到的数据包进行监听,当所述IKE请求1到达网络出口网关设备时,通过判断如果当前接收的数据包是由发起IPsec的主机A自500端口以UDP数据包形式发出的IKE请求,则判定其准备与安全区域外部建立IPsec连接,以进行IPsec交互。
其中,所述网关设备G可启用LibpCap或者WinpCap功能,在网关处保持监听模式,发现从主机A发出的端口号码为500或4500的UDP数据包。从而通过监听和发现该端口的数据包,网关设备G发现该主机A的IKE协商请求,判断该用户需要和安全区域外部建立IPsec连接。
步骤103,所述网关设备截断该数据包,检测包的源和目的地址,提取该数据包的源地址和响应方对应的目的地址并保存在本地数据表中,同时在对应的条目上设置标识S以表示该发起方希望建立安全连接。
步骤104,所述网关设备回复所述发起方IKE请求1失败通知消息,在该消息种携带该网关设备自身地址。
本步骤具体网关设备可回复给主机A使用ISAKMP错误消息——向相应方B地址的IKE1请求失败。
作为一个实施例,在该消息的尾部,网关设备加入网关SG本身地址的载荷消息,参见表1所示。
表1
其中各部分含义如下:
下一个报头(Next Payload):识别下一个使用IP协议号的报头
长度(Payload Length):AH报头长的值
安全参数索引(SPI):这是一个为数据报识别安全关联的32位伪随机值。SPI值0被保留来表明″没有安全关联存在″。
主机A得到建立IKE ISAKMP失败通知消息的同时,获得包含网关本身地址的载荷消息。此时主机A向本地安全数据表查询或审核网关的X.509证书,确认网关设备地址G是真实可信的。
然后进入网关设备协商并建立IPsec安全链路的流程,参见图7所示,包括:
步骤201,发起方主机A向网关设备G地址发起IKE协商请求2,该IKE协商请求2的目的地址为网关设备G,协商过程和正常IKE协商一样,以向网关请求协商沟通使用的加密方法,例如加密算法和密钥。本步骤具体参见图8所示。
步骤202,所述网关设备G收到所述IKE请求2后,查询本地数据表该主机用户对应的标识,如果发现所述标识S,则判定该发起方曾发送过所述IKE请求1,并在数据表中找到响应方主机B的目的地址。
步骤203,所述网关设备G向所述目的地址对应的响应方主机B发起IKE请求3。本步骤具体参见图9所示。
步骤204,所述网关设备G与响应方之间进行IKE协商,协商成功后,响应方返回第三IKE请求成功消息,网关设备G和响应方主机B建立IPsec安全隧道。
本步骤具体可包括:网关设备G和响应方主机B选择主动或积极模式,通过IKE3确认双方身份并沟通使用加密方法,比如:密钥、加密算法。IKE3协商结束后,网关设备G和响应方主机B间建立了IPsec安全隧道ST-GB。
该隧道建立方式可使用用户到用户传输模式也可以为网络隧道方式。用户到用户传输模式将有效的载荷进行加密,而不对IP头进行加密或者修改,所以路由是完整的,两个用户可以直接通讯,而使用哈希来保障在运输过程中的地址不被更改。另一种方式是使用网络隧道方式,对整个数据包进行加密,然后整个数据包封装到新的IP数据包和IP投下。网络隧道模式可以创建网络到网络之间的通讯,主机到网络或者主机到主机的通讯。
步骤205,IPsec安全隧道ST-GB建立后,所述网关设备G向发起方主机A返回确认IKE2协商成功的响应消息,并将数据表中的所述标识复位,例如删除标识S或改为初始值。网关设备G和发起方主机A通过IKE确认双方身份后,协商加密方法,例如:加密算法和密钥,此时网关设备G和发起方主机A间建立了IPsec安全隧道ST-AG。本步骤具体参见图10所示。
至此,保证了数据包在两段隧道中安全传输。其具体形态如图11所示。
接下来深度包检测流程参见图12所示,包括:
步骤301,发起方主机A根据与所述网关设备G进行IKE协商后的加密协议,对数据包进行AH和/或ESP加密后,通过所建立的IPsec安全隧道发送至所述网关设备G。
通过IP协议号″51″标识的AH协议在通信主机与通信主机之间、通信网关设备与通信网关设备之间或网关设备与主机之间提供安全服务。AH的工作原理是在每一个数据包上添加一个身份验证报头。AH报头插在IPv6逐跳路由头之后IPv6目的选项之前。图13显示了AH报头在IP包中的位置:
AH报头包含一个带密钥的hash散列。这个散列和数字签名作用相同,只是它不使用证书。由于在整个数据包中计算这个Hash散列,对数据的任何更改将致使散列无效,因此AH报头为数据提供了完整性保护,能为IP通信提供数据源认证、数据完整性和反重播保证,它能保护通信免受篡改,但AH不能防止窃听。
用户也可选择使用由IP协议号″50″标识的IPsec ESP加密上层传输协议信息、数据和ESP报尾,为IP数据包提供完整性检查、认证和加密。ESP认证报尾的完整性检查部分包括ESP报头、传输层协议报头,应用数据和ESP报尾,可以对整个数据包加密,但不包括IP报头,因此ESP不能保证IP报头不被篡改。
通过ESP和AH的选择使用,本发明保证传送数据在传送过程中的安全级别达到用户要求,未被修改,并且无法窃听,从而确保数据在两端IPsec隧道中的安全。
2)DPI过程:
步骤302,所述网关设备G收到发起方主机A发出的经过AH或/和ESP加密的所述数据包后,通过与发起方协商好的加密方法,即密钥和加密算法对该数据包进行解密。
步骤303,解密过程完成后,通过安全检测服务器进行IPsec包的深度包检测。
其中,由于普通报文检测仅分析IP包的层4以下的内容,包括源地址、目的地址、源端口、目的端口以及协议类型,无法检测到报文的实际内容,同时当前网络上的一些非法应用会仿冒合法报文的数据流以此来逃避检测,因而普通报文的检测是不彻底和不安全的。本发明实施例采用的深度包检测(DPI,Deep Packet Inspection)除了对前面的层次分析外,还增加了应用层分析,使用不同的协议的特征来定义不同的应用,识别各种应用及其内容。DPI使用固定位置特征字匹配、变动位置的特征匹配以及状态特征匹配三种匹配技术对特定的端口、特定的字符串或者特定的Bit序列进行识别,确定业务流承载的应用,检测应用程序或服务中的变量的正确性,以保证网络安全。通过DPI技术识别出各类业务流之后,根据网络配置的组合条件,如用户、时间、带宽、历史流量等,可以对业务流进行控制。另外,通过对特征字信息库的升级,DPI可以很方便的进行功能扩展,实现对新协议的检测。然而在IPsec下由于对内容进行了加密,传统的DPI无法实现对IPsec包的深度检测,必须使用其他方式来实现IPsec下的流量管控。
安全检测服务器可通过特征字检测,匹配固定位置、变动位置及状态特征字,识别业务流中特定数据报文,确认业务流承载的应用,例如需要检测Bittorrent协议,由于每个消息的前面都有一个数字来表示消息的长度,则长度19的消息特征字为“19BitTorrentProtocol”,通过该特征字即可检测该特定的业务流。此外,对于控制流和业务流是分离的某些业务,包括使用SIP、H323协议的RTP语音流等,由于业务流没有任何特征,安全检测服务器先识别出控制流,并根据控制流的协议通过内部的应用层处理设备对其进行解析,从协议内容中识别出相应的业务流。其中所述应用层处理设备主要检测应用层的内容。之后,网关设备通过定义的策略完成安全流量管控和流量的优化,如DPI可以识别出各类业务流,并根据网络配置的组合条件,对业务进行整理统计,使得运营商和管控部门可以直观的统计网络的业务流量分布和用户的各种业务使用情况,同时可以通过DPI检测发现网络中的攻击或者非法流量,如果检测内容无法通过,DPI设备拦截该数据包并在系统中添加告警项,触发相关安全事件。
3)加解密过程B:
步骤304,如果深度包检测通过,网关设备G通过与响应方协商好的加密方法,使用协商好的密钥和加密算法进行AH和/或ESP加密,以保证内容在隧道中的安全性。
步骤305,将加密后的数据包通过安全隧道ST-GB发送至响应方主机B。
通信完毕后,网关设备G分别拆除两段IPsec安全隧道ST-AG和ST-GB,同时从网关设备的所述数据表中删除主机A和主机B的对应条目。
深度包检测未通过的流程参见图14所示。
步骤401-403与上述步骤301-303相同。
如果在所述步骤303中深度包检测未通过,则执行步骤404,触发预先设置的安全措施。
步骤405,向发起方主机A发送IPsec通信失败的响应消息。
图6网关设备设备
在本发明中需注意的是IPsec客户A需要事先知道网关设备提供的公钥K,该公钥获取方式可通过软件里设置好,或者通过建立一个外部X.509证书,以此确认网关设备的身份,而网关的安全检测服务器最好需要事先获取国外服务器的公钥,从而能保证后来用于正式通信的session key可以安全的交换。另外方案可能会加大网关节点的负担,导致网络速度下降,同时可能增加IPsec协议的安全性的安全漏洞,带来一些安全隐患。因而十分有必要提供网关节点的安全性保护。
本领域普通技术人员可以理解:实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成,前述的程序可以存储于一计算机可读取存储介质中,该程序在执行时,执行包括上述方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
在实际应用中,可以按照以上方案在发起方网络的出口网关设备以硬件或软件形式增加相应的IPsec检测功能模块、IPsec用户认证模块、地址关联模块及IPsec数据包转发模块,并旁挂安全检测服务器。在现有的安全域的网络侧向用户提供网关设备的公钥K,该公钥可通过IPsec软件里设置,或者通过建立一个外部PKI来获取证书,以此实现网关设备的身份确认,防止冒用和中间人攻击情况发生。同时,在出口网关设备内新加入IPsec检测功能模块、IPsec用户认证模块、地址关联模块及IPsec数据包转发模块,记录IPSec链接并向目的端发起连接。除此之外,现有的GID6方案与已有IPsec其他过程相兼容,无需改变IPsec其他设置,可实际应用于宽带接入网络IPv6下的安全检测解决方案。
所属领域的普通技术人员应当理解:以上所述仅为本发明的具体实施例而已,并不用于限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (12)
1.一种IPSec流量安全检测方法,其特征在于,包括:
A.发起方通过网关设备向响应方发起IPsec通信的IKE请求时,所述网关设备截获IKE请求,提取该请求的源地址和响应方对应的目的地址并保存在本地数据表中;所述步骤A进一步包括:
101,所述发起方向所述响应方发起IPsec通信的第一IKE请求;
102,所述网关设备监听到发起方当前发出的如果是端口号码为500或者4500的UDP数据包,则判定为该发起方准备与安全区域外部建立IPsec连接的所述第一IKE请求;
103,所述网关设备截断当前第一IKE请求的数据包,提取该数据包的源地址和响应方对应的目的地址并保存在本地数据表中,同时设置标识以表示该发起方希望建立安全连接;
104,所述网关设备回复所述发起方IKE请求失败通知消息,在该消息种携带该网关设备自身地址;
B.所述网关设备分别与所述发起方、响应方进行加密协商,并分别建立与发起方、响应方的IPsec安全隧道;
C.所述发起方将需要发送给所述响应方的数据包采用与所述网关设备协商的加密方法进行加密,通过与所述网关设备建立的IPsec安全隧道发送至所述网关设备;
D.所述网关设备收到所述数据包后,通过与发起方协商好的加密方法对该数据包进行解密后,进行深度包检测;
E.如果深度包检测通过,所述网关设备将该数据包通过与所述响应方协商好的加密方法进行加密后,通过与所述响应方建立的IPsec安全隧道发送至所述响应方;
F.如果所述深度包检测没有通过,所述网关设备向发起方发送通信失败的响应消息,并拦截该数据包并在系统中添加告警项,触发相关安全事件。
2.根据权利要求1所述的方法,其特征在于,所述网关设备启用LibpCap或者WinpCap功能进行监听。
3.根据权利要求1所述的方法,其特征在于,所述步骤B进一步包括:
201,所述发起方向所述响应方发起IPsec通信的第一IKE请求后,如果收到所述网关设备的失败通知消息,提取所述网关设备地址;向所述网关设备发起第二IKE请求,请求协商沟通使用的加密算法和密钥;
202,所述网关设备收到所述第二IKE请求后,查询本地数据表,如果发现表示该发起方希望建立安全连接的标识,则判定该发起方曾发送过所述第一IKE请求,并在所述数据表中提取出所述目的地址;
203,所述网关设备向所述目的地址对应的响应方发起第三IKE请求;
204,所述网关设备与响应方之间协商加密方法,协商成功后,响应方返回第三IKE请求成功消息,网关设备与响应方建立IPsec安全隧道;
205,所述网关设备向发起方返回第二IKE协商成功的响应消息,并将数据表中的所述标识复位;网关设备与发起方通过IKE确认双方身份后,协商加密方法,网关设备和发起方建立IPsec安全隧道。
4.根据权利要求1所述的方法,其特征在于,所述加密方法为认证头AH和/或封装安全载荷ESP加密协议。
5.根据权利要求1所述的方法,其特征在于,所述步骤E后进一步包括:通信完毕后,所述网关设备拆除与发起方、响应方建立的两条IPsec安全隧道,并从数据表中删除该发起方和响应方的对应条目。
6.根据权利要求1所述的方法,其特征在于,步骤D所述深度包检测包括:通过特征字检测,匹配固定位置、变动位置及状态特征字,识别业务流中特定数据报文,确认业务流承载的应用;
对于控制流和业务流是分离的业务,先识别出控制流,并根据控制流的协议对其进行应用层内容的解析,从协议内容中识别出相应的业务流。
7.根据权利要求1所述的方法,其特征在于,步骤E所述深度包检测通过后,所述网关设备进一步通过定义的策略完成安全流量管控和流量的优化。
8.根据权利要求7所述的方法,其特征在于,所述优化过程进一步包括:识别出各类业务流,并根据网络配置的组合条件,对业务进行整理统计,使得运营商和管控部门可以直观的统计网络的业务流量分布和用户的各种业务使用情况。
9.根据权利要求1所述的方法,其特征在于,所述网关设备位于发起方所在网络的出口。
10.一种用于IPSec流量安全检测的网关设备,其特征在于,包括:
IPsec检测功能模块,用于监听到发起方当前发出的如果是端口号码为500或者4500的UDP数据包,则判定为该发起方准备与安全区域外部建立IPsec连接的IKE请求,截获该IKE请求的数据包;以及向发起方回复所述发起方IKE请求失败通知消息,在该消息种携带该网关设备自身地址;
地址关联功能模块,用于提取IPsec检测功能模块截获的所述IKE请求的源地址和响应方对应的目的地址,保存在本地数据表中,同时设置标识以表示该发起方希望建立安全连接;
IPsec连接发起模块,用于发起与所述发起方、响应方的加密协商,以及分别建立与发起方、响应方的IPsec安全隧道;
IPsec用户认证模块,用于收到发起方需要发送给响应方的数据包后,通过与发起方协商好的加密方法对该数据包进行解密,发送给安全检测服务器进行深度包检测;
IPsec数据包转发模块,用于接收所述安全检测服务器的检测结果,如果深度包检测通过,所述网关设备将该数据包通过与所述响应方协商好的加密方法进行加密后,通过与所述响应方建立的IPsec安全隧道发送至所述响应方。
11.一种用于IPSec流量安全检测的系统,其特征在于,包括:如权利要求10所述的网关设备,以及与该网关设备相连用于深度包检测的安全检测服务器。
12.根据权利要求11所述的系统,其特征在于,所述深度包检测包括:通过特征字检测,匹配固定位置、变动位置及状态特征字,识别业务流中特定数据报文,确认业务流承载的应用;
对于控制流和业务流是分离的业务,先识别出控制流,并根据控制流的协议对其进行应用层内容的解析,从协议内容中识别出相应的业务流。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010243679.9A CN102347870B (zh) | 2010-07-29 | 2010-07-29 | 一种流量安全检测方法、设备和系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201010243679.9A CN102347870B (zh) | 2010-07-29 | 2010-07-29 | 一种流量安全检测方法、设备和系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102347870A CN102347870A (zh) | 2012-02-08 |
CN102347870B true CN102347870B (zh) | 2015-09-09 |
Family
ID=45546178
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201010243679.9A Active CN102347870B (zh) | 2010-07-29 | 2010-07-29 | 一种流量安全检测方法、设备和系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102347870B (zh) |
Families Citing this family (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103685298A (zh) * | 2013-12-23 | 2014-03-26 | 上海交通大学无锡研究院 | 一种基于深度包检测的ssl中间人攻击发现方法 |
CN103929423B (zh) * | 2014-04-15 | 2017-08-25 | 广东电网公司电力科学研究院 | 处理电力规约的IPSec VPN安全转发方法与系统 |
CN104601577A (zh) * | 2015-01-16 | 2015-05-06 | 网神信息技术(北京)股份有限公司 | 基于vpn切换协议的方法和装置 |
CN105429962B (zh) * | 2015-11-03 | 2018-10-19 | 清华大学 | 一种通用的面向加密数据的中间网络服务构建方法与体系 |
CN107181716A (zh) * | 2016-03-10 | 2017-09-19 | 上海传真通信设备技术研究所有限公司 | 一种基于国家商用密码算法的网络安全通信系统及方法 |
CN106101075B (zh) * | 2016-05-31 | 2018-02-02 | 上海连尚网络科技有限公司 | 一种实现安全访问的方法与设备 |
CN106169990A (zh) * | 2016-06-22 | 2016-11-30 | 北京奇虎科技有限公司 | 一种加密流量数据监控的方法、装置及系统 |
CN107787003A (zh) * | 2016-08-24 | 2018-03-09 | 中兴通讯股份有限公司 | 一种流量检测的方法和装置 |
US10470192B2 (en) * | 2017-03-08 | 2019-11-05 | Zte Corporation | Traffic path change detection mechanism for mobile edge computing |
EP3379789A1 (en) * | 2017-03-20 | 2018-09-26 | Koninklijke Philips N.V. | Mutual authentication system |
CN107277027B (zh) * | 2017-06-30 | 2020-10-16 | 北京知道未来信息技术有限公司 | 一种旁路抢答设备识别方法及流量清洗方法 |
CN107645513A (zh) * | 2017-10-24 | 2018-01-30 | 哈尔滨工业大学(威海) | 一种IPsec内容审计装置及方法 |
CN108600279B (zh) * | 2018-07-31 | 2020-09-25 | 新华三信息安全技术有限公司 | 一种报文处理方法及装置 |
CN111416791B (zh) * | 2019-01-04 | 2022-06-14 | 华为技术有限公司 | 数据传输方法、设备与系统 |
CN109698840B (zh) * | 2019-02-27 | 2022-02-25 | 新华三大数据技术有限公司 | 检测dhcp恶意事件方法及装置 |
CN110099004A (zh) * | 2019-03-29 | 2019-08-06 | 贵阳忆联网络有限公司 | 一种网络安全路由方法及系统 |
CN112019418B (zh) * | 2019-05-31 | 2022-04-19 | 中国电信股份有限公司 | 基于野蛮模式的IPSec隧道建立方法及其装置 |
CN110691074B (zh) * | 2019-09-20 | 2022-04-22 | 西安瑞思凯微电子科技有限公司 | 一种IPv6数据加密方法、IPv6数据解密方法 |
CN110768958B (zh) * | 2019-09-20 | 2022-08-05 | 西安瑞思凯微电子科技有限公司 | 一种IPv4数据加密方法、IPv4数据解密方法 |
CN112714097A (zh) * | 2019-10-25 | 2021-04-27 | 华为技术有限公司 | 一种安全通信方法、装置及系统 |
CN111614660B (zh) * | 2020-05-19 | 2022-01-18 | 北京字节跳动网络技术有限公司 | 安全验证缺陷检测的方法、装置以及电子设备 |
CN112564969A (zh) * | 2020-12-04 | 2021-03-26 | 浪潮电子信息产业股份有限公司 | 简单网络管理协议中的信息传输方法、系统及相关装置 |
CN112910729A (zh) * | 2021-01-27 | 2021-06-04 | 江苏农林职业技术学院 | 一种支持IPSec VPN数据监控的方法 |
CN114221799B (zh) * | 2021-12-10 | 2024-03-22 | 中国人民银行数字货币研究所 | 一种通信监控方法、装置和系统 |
CN114500678A (zh) * | 2022-01-26 | 2022-05-13 | 阿里巴巴(中国)有限公司 | 一种网关与通信节点的建连方法及设备 |
CN114697022A (zh) * | 2022-03-18 | 2022-07-01 | 北京国泰网信科技有限公司 | 应用于配电网系统的加密认证方法 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8484473B2 (en) * | 2008-11-10 | 2013-07-09 | Telefonaktiebolaget Lm Ericsson (Publ) | Inter base station interface establishment |
-
2010
- 2010-07-29 CN CN201010243679.9A patent/CN102347870B/zh active Active
Non-Patent Citations (2)
Title |
---|
增强的NAT-PT和IPSec兼容解决方案;张志龙 等;《计算机工程》;20081130;正文第2-4节,图2-4 * |
牛丽君,吕成彬.安全的NAT-PT转换网关的设计.《安全的NAT-PT转换网关的设计》.2006, * |
Also Published As
Publication number | Publication date |
---|---|
CN102347870A (zh) | 2012-02-08 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102347870B (zh) | 一种流量安全检测方法、设备和系统 | |
US9602485B2 (en) | Network, network node with privacy preserving source attribution and admission control and device implemented method therfor | |
Frankel et al. | Guide to IPsec VPNs:. | |
US20040098620A1 (en) | System, apparatuses, methods, and computer-readable media using identification data in packet communications | |
Berger | Analysis of current VPN technologies | |
KR100839941B1 (ko) | IPSec 설정정보와 세션정보를 이용한 비정상IPSec 트래픽 제어 시스템 및 그 제어 방법 | |
CA2506418C (en) | Systems and apparatuses using identification data in network communication | |
CN105516062A (zh) | 一种实现L2TP over IPsec接入的方法 | |
CN114844730A (zh) | 一种基于可信隧道技术构建的网络系统 | |
CN113904809A (zh) | 一种通信方法、装置、电子设备及存储介质 | |
Park et al. | Session management for security systems in 5g standalone network | |
KR101448866B1 (ko) | 웹 보안 프로토콜에 따른 암호화 데이터를 복호화하는 보안 장치 및 그것의 동작 방법 | |
Amaldeep et al. | Cross Protocol Attack on IPSec-based VPN | |
KR101089269B1 (ko) | 보안 기능을 제공하는 안전한 에스아이피 프로토콜을 이용한 공격 탐지 방법 및 시스템 | |
CN109600745B (zh) | 一种新型的5g蜂窝网信道安全系统及安全实现方法 | |
Mahyoub et al. | Security analysis of critical 5g interfaces | |
Cisco | Introduction to Cisco IPsec Technology | |
Alhumrani et al. | Cryptographic protocols for secure cloud computing | |
Jacquin et al. | Too big or too small? the PTB-PTS ICMP-based attack against IPsec gateways | |
Arora et al. | Comparison of VPN protocols–IPSec, PPTP, and L2TP | |
KR20110087972A (ko) | 세션 테이블을 이용한 비정상 트래픽의 차단 방법 | |
JP2005065004A (ja) | 暗号化通信データ検査方法、暗号化通信データ検査装置及び暗号化通信データ検査プログラム | |
Belbachir et al. | Involved Security Solution in Voice over IP Networks | |
Zave et al. | 1 Security provided by endpoints | |
Munasinghe | VPN over a wireless infrastructure: evaluation and performance analysis |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |