IPSec简介(Internet Protocol Security)
IPSec简介(Internet Protocol Security)
起源
随着Internet的发展,越来越多的企业直接通过Internet进行互联,但由于IP协议未考虑安全性,而且Internet上有大量的不可靠用户和网络设备,所以用户业务数据要穿越这些未知网络,根本无法保证数据的安全性,数据易被伪造、篡改或窃取。因此,迫切需要一种兼容IP协议的通用的网络安全方案。
为了解决上述问题,IPSec(Internet Protocol Security)应运而生。IPSec是对IP的安全性补充,其工作在IP层,为IP网络通信提供透明的安全服务。
定义
IPSec是IETF(Internet
Engineering Task
Force)制定的一组开放的网络安全协议。它并不是一个单独的协议,而是一系列为IP网络提供安全性的协议和服务的集合,包括认证头AH(Authentication
Header)和封装安全载荷ESP(Encapsulating Security
Payload)两个安全协议、密钥交换和用于验证及加密的一些算法等。
通过这些协议,在两个设备之间建立一条IPSec隧道。数据通过IPSec隧道进行转发,实现保护数据的安全性。
受益
IPSec通过加密与验证等方式,从以下几个方面保障了用户业务数据在Internet中的安全传输:
数据来源验证:接收方验证发送方身份是否合法。
数据加密:发送方对数据进行加密,以密文的形式在Internet上传送,接收方对接收的加密数据进行解密后处理或直接转发。
数据完整性:接收方对接收的数据进行验证,以判定报文是否被篡改。
抗重放:接收方拒绝旧的或重复的数据包,防止恶意用户通过重复发送捕获到的数据包所进行的攻击。
安全联盟
安全联盟SA(Security
Association)是通信对等体间对某些要素的协定,它描述了对等体间如何利用安全服务(例如加密)进行安全的通信。这些要素包括对等体间使用何种安全协议、需要保护的数据流特征、对等体间传输的数据的封装模式、协议采用的加密和验证算法,以及用于数据安全转换、传输的密钥和SA的生存周期等。
IPSec安全传输数据的前提是在IPSec对等体(即运行IPSec协议的两个端点)之间成功建立安全联盟。IPSec安全联盟简称IPSec
SA,由一个三元组来唯一标识,这个三元组包括安全参数索引SPI(Security Parameter
Index)、目的IP地址和使用的安全协议号(AH或ESP)。其中,SPI是为唯一标识SA而生成的一个32位比特的数值,它被封装在AH和ESP头中。
IPSec SA是单向的逻辑连接,通常成对建立(Inbound和Outbound)。因此两个IPSec对等体之间的双向通信,最少需要建立一对IPSec SA形成一个安全互通的IPSec隧道,分别对两个方向的数据流进行安全保护,如图所示。
另外,IPSec SA的个数还与安全协议相关。如果只使用AH或ESP来保护两个对等体之间的流量,则对等体之间就有两个SA,每个方向上一个。如果对等体同时使用了AH和ESP,那么对等体之间就需要四个SA,每个方向上两个,分别对应AH和ESP。
建立IPSec SA有两种方式:
手工方式和IKE方式。二者的主要差异如表所示。
手工和IKE方式的差异
对比项 | 手工方式建立IPSec SA | IKE方式自动建立IPSec SA |
---|---|---|
加密/验证密钥配置和刷新方式 | 手工配置、刷新,而且易出错 密钥管理成本很高 | 密钥通过DH算法生成、动态刷新 密钥管理成本低 |
SPI取值 | 手工配置 | 随机生成 |
生存周期 | 无生存周期限制,SA永久存在 | 由双方的生存周期参数控制,SA动态刷新 |
安全性 | 低 | 高 |
适用场景 | 小型网络 | 小型、中大型网络 |
安全协议
IPSec使用认证头AH(Authentication Header)和封装安全载荷ESP(Encapsulating Security Payload)两种IP传输层协议来提供认证或加密等安全服务。
AH协议
AH仅支持认证功能,不支持加密功能。AH在每一个数据包的标准IP报头后面添加一个AH报文头,如封装模式所示。AH对数据包和认证密钥进行Hash计算,接收方收到带有计算结果的数据包后,执行同样的Hash计算并与原计算结果比较,传输过程中对数据的任何更改将使计算结果无效,这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。
ESP协议
ESP支持认证和加密功能。ESP在每一个数据包的标准IP报头后面添加一个ESP报文头,并在数据包后面追加一个ESP尾(ESP
Trailer和ESP Auth
data),如封装模式所示。与AH不同的是,ESP将数据中的有效载荷进行加密后再封装到数据包中,以保证数据的机密性,但ESP没有对IP头的内容进行保护,除非IP头被封装在ESP内部(采用隧道模式)。
AH和ESP协议的简单比较如表所示。
AH协议与ESP协议比较
安全特性 | AH | ESP |
---|---|---|
协议号 | 51 | 50 |
数据完整性校验 | 支持(验证整个IP报文) | 支持(传输模式:不验证IP头,隧道模式:验证整个IP报文) |
数据源验证 | 支持 | 支持 |
数据加密 | 不支持 | 支持 |
防报文重放攻击 | 支持 | 支持 |
IPSec NAT-T(NAT穿越) | 不支持 | 支持 |
从表中可以看出两个协议各有优缺点,在安全性要求较高的场景中可以考虑联合使用AH协议和ESP协议。
AH报文头字段含义
字段 | 长度 | 含义 |
---|---|---|
下一头部 | 8比特 | 标识AH报文头后面的负载类型。传输模式下,是被保护的上层协议(TCP或UDP)或ESP协议的编号;隧道模式下,是IP协议或ESP协议的编号。 说明: 当AH与ESP协议同时使用时,AH报文头的下一头部为ESP报文头。 |
负载长度 | 8比特 | 表示以32比特为单位的AH报文头长度减2,缺省为4。 |
保留字段 | 16比特 | 保留将来使用,缺省为0。 |
SPI | 32比特 | IPSec安全参数索引,用于唯一标识IPSec安全联盟。 |
序列号 | 32比特 | 是一个从1开始的单项递增的计数器,唯一地标识每一个数据包,用于防止重放攻击。 |
认证数据 | 一个变长字段,长度为32比特的整数倍,通常为96比特。 | 该字段包含数据完整性校验值 ICV(Integrity Check Value),用于接收方进行完整性校验。可选择的认证算法有MD5、SHA1、SHA2、SM3。 说明: MD5和SHA1验证算法存在安全隐患,建议优先使用SHA2或SM3算法。 |
ESP报文头字段含义
字段 | 长度 | 含义 |
---|---|---|
SPI | 32比特 | IPSec安全参数索引,用于唯一标识IPSec安全联盟。 |
序列号 | 32比特 | 是一个从1开始的单项递增的计数器,唯一地标识每一个数据包,用于防止重放攻击。 |
负载数据 | — | 包含原始IP报文中可变长度数据内容。ESP保护的内容类型由下一头部字段标识。 |
填充字段 | — | 用于增加ESP报文头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的长度不是加密算法所要求的块长度时,需要进行填充补齐。 |
填充长度 | 8比特 | 给出前面填充字段的长度,置0时表示没有填充。 |
下一头部 | 8比特 | 标识ESP报文头后面的下一个负载类型。传输模式下,是被保护的上层协议(TCP或UDP)的编号;隧道模式下,是IP协议的编号。 |
认证数据 | 一个变长字段,长度为32比特的整数倍,通常为96比特。 | 该字段包含数据完整性校验值ICV,用于接收方进行完整性校验。可选择的认证算法与AH的相同。 ESP的验证功能是可选的,如果启动了数据包验证,会在加密数据的尾部添加一个ICV数值。 |
封装模式
封装模式是指将AH或ESP相关的字段插入到原始IP报文中,以实现对报文的认证和加密,封装模式有传输模式和隧道模式两种。
传输模式
在传输模式中,AH头或ESP头被插入到IP头与传输层协议头之间,保护TCP/UDP/ICMP负载。由于传输模式未添加额外的IP头,所以原始报文中的IP地址在加密后报文的IP头中可见。以TCP报文为例,原始报文经过传输模式封装后,报文格式如图1所示。
隧道模式
在隧道模式下,AH头或ESP头被插到原始IP头之前,另外生成一个新的报文头放到AH头或ESP头之前,保护IP头和负载。以TCP报文为例,原始报文经隧道模式封装后的报文结构如图所示。
隧道模式下报文封装
传输模式和隧道模式比较
传输模式和隧道模式的区别在于:
从安全性来讲,隧道模式优于传输模式。它可以完全地对原始IP数据包进行验证和加密。隧道模式下可以隐藏内部IP地址,协议类型和端口。
从性能来讲,隧道模式因为有一个额外的IP头,所以它将比传输模式占用更多带宽。
从场景来讲,传输模式主要应用于两台主机或一台主机和一台VPN网关之间通信;隧道模式主要应用于两台VPN网关之间或一台主机与一台VPN网关之间的通信。
当安全协议同时采用AH和ESP时,AH和ESP协议必须采用相同的封装模式。
加密和验证
IPSec提供了两种安全机制:加密和验证。加密机制保证数据的机密性,防止数据在传输过程中被窃听;验证机制能保证数据真实可靠,防止数据在传输过程中被仿冒和篡改。
加密
IPSec采用对称加密算法对数据进行加密和解密。如图1所示,数据发送方和接收方使用相同的密钥进行加密、解密。
图1 加密和解密的过程
用于加密和解密的对称密钥可以手工配置,也可以通过IKE协议自动协商生成。
常用的对称加密算法包括:数据加密标准DES(Data
Encryption Standard)、3DES(Triple Data Encryption
Standard)、先进加密标准AES(Advanced Encryption
Standard)国密算法(SM4)。其中,DES和3DES算法安全性低,存在安全风险,不推荐使用。
验证
IPSec的加密功能,无法验证解密后的信息是否是原始发送的信息或完整。IPSec采用HMAC(Keyed-Hash Message Authentication Code)功能,比较完整性校验值ICV进行数据包完整性和真实性验证。
通常情况下,加密和验证通常配合使用。如图2所示,在IPSec发送方,加密后的报文通过验证算法和对称密钥生成完整性校验值ICV,IP报文和完整性校验值ICV同时发给对端;在IPSec接收方,使用相同的验证算法和对称密钥对加密报文进行处理,同样得到完整性校验值ICV,然后比较完整性校验值ICV进行数据完整性和真实性验证,验证不通过的报文直接丢弃,验证通过的报文再进行解密。
同加密一样,用于验证的对称密钥也可以手工配置,或者通过IKE协议自动协商生成。
常用的验证算法包括:消息摘要MD5(Message
Digest 5)、安全散列算法SHA1(Secure Hash Algorithm 1)、SHA2、国密算法SM3(Senior
Middle 3)。其中,MD5、SHA1算法安全性低,存在安全风险,不推荐使用。
密钥交换
使用对称密钥进行加密、验证时,如何安全地共享密钥是一个很重要的问题。有两种方法解决这个问题:
带外共享密钥
在发送、接收设备上手工配置静态的加密、验证密钥。双方通过带外共享的方式(例如通过电话或邮件方式)保证密钥一致性。这种方式的缺点是安全性低,可扩展性差,在点到多点组网中配置密钥的工作量成倍增加。另外,为提升网络安全性需要周期性修改密钥,这种方式下也很难实施。
使用一个安全的密钥分发协议
通过IKE协议自动协商密钥。IKE采用DH(Diffie-Hellman)算法在不安全的网络上安全地分发密钥。这种方式配置简单,可扩展性好,特别是在大型动态的网络环境下此优点更加突出。同时,通信双方通过交换密钥交换材料来计算共享的密钥,即使第三方截获了双方用于计算密钥的所有交换数据,也无法计算出真正的密钥,这样极大地提高了安全性。
IKE协议
因特网密钥交换IKE(Internet
Key Exchange)协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上,是基于UDP(User Datagram
Protocol)的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务,能够简化IPSec的配置和维护工作。
IKE与IPSec的关系如图1所示,对等体之间建立一个IKE SA完成身份验证和密钥信息交换后,在IKE SA的保护下,根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后,对等体间的数据将在IPSec隧道中加密传输。
IKE SA是一个双向的逻辑连接,两个对等体间只建立一个IKE SA。
IKE安全机制
IKE具有一套自保护机制,可以在网络上安全地认证身份、分发密钥、建立IPSec SA:
身份认证
身份认证确认通信双方的身份(对等体的IP地址或名称),包括预共享密钥PSK(pre-shared key)认证、数字证书RSA(rsa-signature)认证和数字信封认证。
在预共享密钥认证中,通信双方采用共享的密钥对报文进行Hash计算,判断双方的计算结果是否相同。如果相同,则认证通过;否则认证失败。
当有1个对等体对应多个对等体时,需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立,但安全性较低。
在数字证书认证中,通信双方使用CA证书进行数字证书合法性验证,双方各有自己的公钥(网络上传输)和私钥(自己持有)。发送方对原始报文进行Hash计算,并用自己的私钥对报文计算结果进行加密,生成数字签名。接收方使用发送方的公钥对数字签名进行解密,并对报文进行Hash计算,判断计算结果与解密后的结果是否相同。如果相同,则认证通过;否则认证失败。
使用数字证书安全性高,但需要CA来颁发数字证书,适合在大型网络中使用。
在数字信封认证中,发送方首先随机产生一个对称密钥,使用接收方的公钥对此对称密钥进行加密(被公钥加密的对称密钥称为数字信封),发送方用对称密钥加密报文,同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥,再用对称密钥解密报文,同时根据发送方的公钥对数字签名进行解密,验证发送方的数字签名是否正确。如果正确,则认证通过;否则认证失败。
数字信封认证用于设备需要符合国家密码管理局要求时使用,此认证方法只能在IKEv1的主模式协商过程中支持。
IKE支持的认证算法有:MD5、SHA1、SHA2-256、SHA2-384、SHA2-512、SM3。
身份保护
身份数据在密钥产生之后加密传送,实现了对身份数据的保护。
IKE支持的加密算法有:DES、3DES、AES-128、AES-192、AES-256和SM4。
DH
DH是一种公共密钥交换方法,它用于产生密钥材料,并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后,两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候,通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。
PFS
完善的前向安全性PFS(Perfect Forward Secrecy)通过执行一次额外的DH交换,确保即使IKE SA中使用的密钥被泄露,IPSec SA中使用的密钥也不会受到损害。
MD5和SHA1认证算法不安全,建议使用SHA2-256、SHA2-384、SHA2-512、SM3算法。
DES和3DES加密算法不安全,建议使用AES或SM算法。
IKE版本
IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点:
简化了安全联盟的协商过程,提高了协商效率。
IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA:第一阶段,通信双方协商和建立IKE本身使用的安全通道,建立一个IKE
SA;第二阶段,利用这个已通过了认证和安全保护的安全通道,建立一对IPSec
SA。IKEv2则简化了协商过程,在一次协商中可直接生成IPSec的密钥并建立IPSec
SA。IKEv1和IKEv2的具体协商过程请分别参见IKEv1协商安全联盟的过程和IKEv2协商安全联盟的过程。
修复了多处公认的密码学方面的安全漏洞,提高了安全性能。
加入对EAP(Extensible Authentication Protocol)身份认证方式的支持,提高了认证方式的灵活性和可扩展性。
EAP是一种支持多种认证方法的认证协议,可扩展性是其最大的优点,即若想加入新的认证方式,可以像组件一样加入,而不用变动原来的认证体系。当前EAP认证已经广泛应用于拨号接入网络中。
VPN配置案例汇总、VPN汇总(列表、list、全)vpnlist
http://www.zh-cjh.com/wenzhangguilei/1193.html
2、本资源基本为原创,部分来源其他付费资源平台或互联网收集,如有侵权请联系及时处理。
3、本站大部分文章的截图来源实验测试环境,请不要在生产环境中随意模仿,以免带来灾难性后果。
转载请保留出处: www.zh-cjh.com珠海陈坚浩博客 » IPSec简介(Internet Protocol Security)
作者: cjh
手机扫一扫,手机上查看此文章: |
一切源于价值!
其他 模板文件不存在: ./template/plugins/comment/pc/index.htm