深入理解IPSec/VPN/IKEV1/IKEV2

2018年7月2日22:15:30 发表评论 16,301 views

IPSec
IPSec(InternetProtocolSecurity Internet 协议安全性 (IPSec)是一种开放标准的框架结构,通过使用加密的安全服务以确保在 Internet 协议 (IP) 网络上进行保密而安全的通讯,是安全联网的长期方向。它通过端对端的安全性来提供主动的保护以防止专用网络与 Internet 的攻击。

IPSecVPN是VPN的一种,一般是LAN-TO-LAN形式,也有资料显示有end-to-end和终端端到网关形式;

IPSec中的安全算法

1.源认证:用于对对等体的身份确认,具体方法包含:PSK(pre-share key);PK3(public key infrustructure公钥基础设施)数字证书,RSA等,后两种为非对称加密算法

2.数据加密:对传输的数据进行加密,确保数据私密性,具体方法包含:des(data encrypt standard)共有2种密钥长度40bits,56bits,3des密钥长度为56bits的3倍;aes(advanced encrypted standard)AES 加密共有三种形式,分为AES 128(128-bit 长度加密),AES 192(192-bit 长度加密)以及AES 256(256-bit 长度加密);由于AES 256 加密长度够长,安全性够高,所以推荐使用AES 256。这些是对称加密算法

3.完整性校验:对接收的数据进行检查,确保数据没有被篡改,主要使用hash算法(HMAC hashed message authentication code),包含MD5(message digest输出128bit校验结果);SHA-1(secure hash algorithm 1)输出160bits校验结果

4.密钥交换算法:安全交换加密数据时使用的密钥,采用DH(Diffie-Hellman)算法,是一种确保共享KEY安全穿越不安全网络的方法,它是OAKLEY的一个组成部分,分为group1(768位),group2(1024位),group5(1536),group14

SA(Security Association)

通过SPI(secure parameter index),序列号,感兴趣流唯一标识一个sa,其中的序列号实现anti-reply功能

IPsec 的所有会话都是在通道中传输的,包括协商密钥,传递用户数据;这样的通道称为SA(Security Association),SA 并不是隧道,而是一组规则,就好比是需要会话的对等体之间必须遵守的一份合同。SA 中的规则能够保证所有数据的安全传递,因此SA 中包含了之前提到的保证数据和密钥安全时必不可少的认证、加密等安全策略,这些需要用到的技术,都要在SA 中定义。因为VPN 之间传输的数据需要加密才能保证安全,并且加密时所用到的密钥要更加安全,所以对待密钥,我们也需要付出巨大的努力。在密钥的安全上,由IKE负责,而数据的安全,则由IPsec 负责,虽然是这么说,但需要注意,IKE 也是IPsec不可分割的一部分,IKE 不是独立存在的。SA 并不是只有一个,由于密钥安全和数据安全我们是分开对待的,所以SA 有两个,分别是定义了如何保护密钥和如何保护数据,这两个SA 就是:

ISAKMP Security Association(IKE SA)
IKE SA 要保护的对象是与密钥有关的,IKE 并不直接关心用户数据,并且IKE SA是为安全协商IPsec SA 服务的。IKE SA 的lifetime 默认为86,400 seconds,即一天,默认没有volume limit。
IPsec Security Association(IPsec SA)

每个SA都有lifetime,过期后SA便无效,lifetime使用time (second) 和volume limit(byte count)来衡量,在建立SA 时就会协商出来,双方会比对,最终取值小的一方;通常是时间先过期,在要过期最后120 秒之前,会自动重建另一条SA,避免活动的SA 到期后无法传输数据,这样就能实现平滑过渡,以丢最少的包。

用户的数据流量真正是在IPsec SA 上传递的,而不是在IKE SA;IPsec SA 直接为用户数据流服务,IPsec SA 中的所有安全策略都是为了用户数据流的安全。每个IPsec 对等体都有一对IPsec SA,一个是去往远程目的地的,而另一个是从远程回来的,也就是一进一出,都存放在本地SA Database 中。
IPsec SA 的lifetime 默认为3600 seconds,即1 小时;默认volume limit 为4,608,000Kbytes,4.608Gbyte。因为SA 有两个,分为IKE SA 和IPsec SA,两个SA 分别定义了如何保护密钥以及如何保护数据,其实这两个SA 都是由IKE 建立起来的,所以将IKE 的整个运行过程分成了两个Phase(阶段):

IKE(Internet Key Exchange)是一个框架包含isakmp,Oakley,smme三中协议

IKEV1
第一阶段:
main mode共6个包交互;前两个包用于对等体之间的认证和相关策略的协商,接着的两个包用于密钥的协商和交换nonce(当前时间)值,最后两个包用于交换身份id密文传输接下的ipsec_sa协商数据和相关密钥
aggressive mode:简化main mode的6个包交换为4个包交换,从第四个包开始为密文,保护接下来的ipsec_sa协商数据和相关密钥
第二阶段:利用第一阶段的IKE_sa保护ipsec_sa的协商,数据传输时的密钥的生成与交换,最终生成ipsec_sa用以保护实际通信中的数据流量
深入理解IPSec/VPN/IKEV1/IKEV2

注:图片来源网络如有侵权,请及时联系删除

IKEV2
第一阶段:四个包交换,initialer和responser两次请求和响应,对应IKEV1的前6个包交换的内容.第二阶段为create_child_sa不再是IKEV1中的quick mode,协商ipsec_sa用于数据流量的认证,加密,完整性校验等,交互次数不定
第二阶段:与IKEV1基本相同,只是交互的报文变成CREATE_CHILD_SA用以生成保护数据流量的IPSEC_SA
有了ipsec_sa以后,当匹配到感兴趣的流量时,就会对这些流量加密传输,
IKEV1和IKEV2的对比:
V2和V1一样,也是使用UDP500端口进行IKE_SA和IPSEC_SA的协商。但是不再存在esp和AH的流量了。因为在后续的流量中,统一流量都是UDP4500传输了。也就是说,用NAT-T传输了。所以在IKEV2的环境里,不再担心NAT环境了。
IPSEC的封装模式:tunnel mode和transport mode这里不再详述;
IPSEC增强特性包含如下:
1.DPD(dead peer detect)
2.IPSEC_SA Idle Timer
3.HA(high available)
4.heartbeat(与hsrp或者vrrp结合)
5.RRI(reverse route injection)自动向site的内网igp中注入一条静态路由将感兴趣流引向IPSEC出口网关设备
华为路由器配置IPSec举例:
acl number 3000
rule 5 permit ip source 4.4.4.4 0 destination 5.5.5.5 0
rule 10 permit ip source 4.4.4.4 0 destination 1.1.35.0 0.0.0.255
rule 15 permit ip source 10.1.14.0 0.0.0.255 destination 5.5.5.5 0
rule 20 permit ip source 10.1.14.0 0.0.0.255 destination 1.1.35.0 0.0.0.255
#
ipsec proposal 11
#
ike proposal 12
#
ike peer r3-2 v2
pre-shared-key simple huawei
ike-proposal 12
local-address 12.1.1.1
remote-address 23.1.1.3
ipsec policy test 1 isakmp
security acl 3000
ike-peer r3-2
proposal 11
interface GigabitEthernet0/0/0---公网出口
ip address 12.1.1.1 255.255.255.0
ipsec policy test
深入理解IPSec/VPN/IKEV1/IKEV2
抓包举例
===========================
NAT穿越:

一、为什么要使用nat穿越(nat-t)技术 

那是因为nat与ipsec的共存的问题导致的。有哪些方面不共存呢。(欢迎大家补充,我这里说几点) 

1.nat实现机制问题导致不共存 

 nat设备只支持tcp、udp和icmp流量,对于ah和esp协议不支持。 

 

2.ah和nat的共存问题 

ah会校验整个ip头部(除TTL)和数据部分,然后过了nat设备之后会改变其源ip,从而导致校验失败。

 

3.ike的id字段与nat不共存 

在ike协商的时候某些验证方式会是用ip地址作为id载荷的内容,过了nat设备导致源ip地址改变验证失败。

 

 二、nat-t实现机制

1.对于ike version 1的主模式而言:

①.在ike协商报文中,若IPSEC支持了nat-t功能,则会在报文中携带vendor ID字段,该字段中包含了对RFC3947hash后的值和ietfike00ike02hash后的值。如下图:

所以在协商之初,通信双方需要告诉对端自己是否支持nat-t。即在第一二个报文中会携带上述vendor ID字段。来标识自己支持nat-t。

②.判断传输过程中是否有经过nat设备,是用过NAT-D字段来说明的,该字段会包含两个hash值,如下:

Hash_R=PRF(CKY-ICKY-R|R-IP|R-Port)

Hash_I=PRF(CKY-I|CKY-R|I-IP|I-Port)

一个是对端ip和端口的hash,一个是本地ip和端口的hashCKY-ICKY-R是发起方和接收方的cookie值。当收到对端的报文,发现hash值不一样的时候,说明报文经过了nat设备。

于是通信双方会在第三四两个报文中携带这个NAT-D这个hash值。来判断中间是否经过nat设备。若是经过nat设备,那么第五六个报文将会在ip头部后面加上一个udp4500端口的头部。若判断没有经过nat,则不加udp4500头部。


2.对于ike version 1野蛮模式而言:

由于一共就三个包来完成ike的协商,所以发起端在第一个报文里会携带vendor ID字段,来标识自己使能了nat-t功能。当接收方收到该报文之后,若是支持nat-t功能会直接回复NAT-D字段(Hash_I和Hash_R),不会加上vendor ID了。接收方收到这个报文之后,会根据hash值判断是否经过了nat设备,若是经过了nat则会加上upd4500端口来发送第三个报文,否则则不会加。


3.对于ike version 2而言:

Ike v2的处理就简单多了。大家可以想一下,发送方有必要发vendor ID字段来标明自己使能了nat-t功能吗?完全没有必要,你只需要发送NAT-D字段过来我就知道你使能还是没有使能了。所以在v2里面就直接省略了发这个vendor ID字段了,直接就发送NAT-D。当接收方收到该报文会回复一个NAT-D。然后双方都知道中间是否经过了nat设备,若是经过了在第三四个包的时候就会加上udp4500的头部。反之则不加。

实验举例:
深入理解IPSec/VPN/IKEV1/IKEV2

图例:实验拓扑

华为配置:
acl number 3000
rule 5 permit ip source 172.16.1.0 0.0.0.255 destination 20.1.1.0 0.0.0.255
rule 10 permit ip source 10.1.1.0 0.0.0.255 destination 20.1.1.0 0.0.0.255
#
ipsec proposal 11
#
ike proposal 11
#
ike peer r1 v2
pre-shared-key simple huawei
ike-proposal 11
local-id-type name
peer-id-type name
remote-name r1
nat traversal
remote-address 12.1.1.1
#
ipsec policy test 1 isakmp
security acl 3000
ike-peer r1
proposal 11
以下为抓包图例
深入理解IPSec/VPN/IKEV1/IKEV2

注:抓包图例

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: