NoOps

Ops make no ops | Ops的目标是没有Ops，嗯！

浅谈IPSec

作者： |   10,135 浏览  | 

IPSec VPN介绍
IPSec通过添加新的预定义头部对网络层以上数据的提供保护。
| Layer2 | Layer3IP | IPSec头部 | TCP | FTP | data |
注：红色为加密部分

IPSec VPN存在两种类型,一种为LAN-to-LAN,一种为Remote-Access。

LAN-To-LAN（Site-To-Site L2L）

1

L2L通过在不同站点间建立IPSec Tunnel来完成来实现不通站点间的三层通讯并且提供安全保护。

Remote-Access

1

Remote-Access通过Client的VPN软件连接Site路由器(Firewall)VPN网关来访问Site内部资源。

IPSec 保护模式
IPSec提供了两种数据包封装类型及工作模式。

ESP Transport Mode：
传输模式保护原始IP头部后面的数据，在原始IP头和payload间插入IPSec头部(ESP或AH)。典型应用为端到端的会话，并且要求原始IP头部全局可路由。
ESP Transport数据包封装图解：
esp trans

ESP Tunnel Mode：

esp tunnel

隧道模式保护所有IP数据并封装新的IP头部，不使用原始IP头部进行路由。在IPSec头前加入新的IP头部源目为IPSec peer地址。并允许RFC1918(私有地址)规定的地址参与VPN穿越互联网。

AH Transport Mode：

ah-trans

AH Tunnel Mode：

ah-tunnel

两种IPSec协议

Encapsulating Security Payload (ESP)

  •  主流IPSec协议
  • 应用场景：L2L、Remote Access
  • 工作在网络层
  • 提供加密和完整性校验
  • 可以穿越特定的NAT（通过额外Feature：NAT-T）

Authentication Header（AH）

  • 非主流IPSec协议
  • 应用场景：P2P（IPv6环境）
  • 工作在网络层
  • 提供完成性校验
  • 不支持NAT环境

如何区分两种模式
首先在IPSec VPN存在两个概念，一个为通讯点，一个为加密点。通讯点位发出的为不加密的数据，加密点为经过设备就进行了IPSec封装。当加密点不等于通讯点时为tunnel Mode。当加密点等于通讯点则为Transport Mode。

33333

 

IPSec VPN组成部分
IPSec有是三个主要协议组成

  • Internet Key Exchange (IKE) protocol：提供了协商安全参数的框架,建立认证的密钥
  • Encapsulating Security Payload (ESP) protocol：提供了框架用于加密、认证、保据保
  • Authentication Header (AH) protocol：为验证和保护数据提供了一个框架

Internet Key Exchange (IKE)

         IKE互联网密钥交换协议负责在两个对等体之间协商一条隧道, IKE在IPSec中的主要作用为：

  • 协商协议参数
  • 交换公共密钥
  • 认证对端
  • 管理密钥和后续密钥的交换

IKE类型与IPSec是一个复合的协议,包含三个不同的协议：

  • Secure Key Exchange Mechanism （SKEME）：定义了以认证为目的的公共密钥加密的机制
  • Key Determination Protocol （OAKLEY）：提供在两个IPSEC对等体间达成相同加密密钥的基本模式的机制
  •  Internet Security Association and Key Management Protocol （ISAKMP）：定义了消息交换的体系结构，包括两个IPSEC对等体分组形式和状态转变(定义封装格式和协商包交换的方式)

 

1

 

IKE协议存在两个阶段三个模式如图：

2

在两个IPSec 对等体间使用Main-mode交换通过6个报文来完成.如果使用Aggressive mode的话则需要三个报文完成阶段1的交换.阶段2的Quick-mode则需要在两个对等体间通过另外三个报文完成交换。

两个阶段三种模式在IPSec Session中的描述：

  1. 感兴趣流(ACL)触发了Interface的Crypto MAP后激发IPSec Session。
  2. IKE第一阶段使用Main-Mode或Aggressive-mode协商，结果产生两个对等体间的IKE的Security Association（SA）。
  3. IKE第二阶段使用Quick-mode协商，结果在两个对等间产生IPSec SA(一入向解密一出向加密)
  4. 双方使用ESP或AH封装在隧道中进行数据传输

IKE两个阶段职责

  1. 通过Main-Mode或Aggressive-Mode协商一个安全的认证隧道
  2. 通过Quick-Mode协商IPSec用于后续真实数据加解密的SA

第一阶段主要作用(Main-Mode或Aggressive-Mode)

  1. 协商一组一致的参数，用于两个对等体间Main-Mode部分报文(4-5报文)和Quick-Mode所有报文交换的认证和加密。(1-4报文为明文，5-9报文为密文)3
  2. 认证两端对等体
  3. 产生用于加密实际数据的密钥

     所有信息的协商在Main-mode或Aggressive-Mode中进行，包含下一阶段加密实际数据的密钥，和IKE或ISAKMP的SA，任意两个对等体只有一个IKE或ISAKMP的SA。

第二阶段(Quick-Mode)主要作用

Quick-Mode的主要作用是在两个对等体间协商一组一致的参数来创建IPSec SA用于真实数据的加解密，并且在此进行PFS(Perfect forward secrecy)，PFS及在Quick-Mode从新做DH的交换，产生新的密钥用于IPSec数据的加密

安全关联Security Association（SA）

  • “安全联盟”(IPSec术语，简称为SA)是构成IPSec的基础。SA是两个同心实体经协商建立的一种协定。它们决定了用来保护数据包安全的IPSec协议、转码方式、密钥以及密钥的有效存在时间等等。任何IPSec实施方案始终会构造一个SA数据库(SADB)，由它来维护IPSec协议用来保障数据包安全的SA记录。
  • SA是单向的。如果两个主机(比如A和B)正在通过ESP进行安全通信，那么主机A就需要一个SA，即SA(Out)，用来处理外发的数据包；另外还需要有一个不同的SA，即SA(IN)用来处理进入的数据包。主机A的(Out)和主机B的SA(in)将共享相同的加密参数(比如密钥)。
  • SA还是(与协议相关)的。每种协议都有一个SA。那么主机A和B同时通过AH和ESP进行安全通信，那么每个主机都会针对每一种协议来构建SA即4个两对SA。

    ISAKMP/IKE SA在对两个对等体间只存在一个,show的结果也是一样的，因为IKE得发起方和响应方是唯一的。4 5

谁先发起的谁就是发起方。不存在IPSec SA中的返回数据包会颠倒源目进行加解密。加解密是通过报文Cookies来标示。Cookie会一直沿用9个包结束。6

IKE协商过程
IKE第一阶段存在两种模式，两种模式在不同环境下应用，应用原则为Remote-Access 使用预共享密钥为Aggressive-Mode（For Cisco 其余厂商基本都是可以选择使用哪种模式），其余全部是Main-Mode。

Main-Mode 6个报文交换
IKE第一阶段Messages 1、2作用
协商用于产生ISAKMP SA的安全参数，ISAKMP SA用于后续5-9包的加密和完整性效验和认证。
在两个报文交换前，发起方和响应方必须计算出标示报文的Cookie。发起方首先计算出自身的cookies放入ISAKMP中Initiator cookies中，Responder cookies值为0000000.接收方收到后报文后计算出自身的cookies填入responder cookies位置，进行第二个报文的回复。这个cookies一直沿用到9个包结束。
产生Cookies过程：
产生initiator cookies：八字节的伪随机数用于anti-clogging
CKY-I= md5{src_ip, dest_ip}, random number, time, and date

产生responder cookies：八字节的伪随机数用于anti-clogging
CKY-I= md5{src_ip, dest_ip}, random number, time, and date
在对等体之间产生伪随机数用于防止中间人的DOS攻击, cookies是基于每个对等体的唯一标示符因此防止了重放攻击。

发起方Phase 1 Sending Message 1 报文7

  • ISAKMP Header—-ISAKMP头部包含发起者的Cookies,响应者的Cookies值为0，待响应者进行Sending Massage 2计算出后填充。Next Payload字段中的值表示Next Payload为SA Payload。
  • SA Payload—-在此包含Domain of Interpretation(DOI)来说明这条信息用于IPSec。另外一条重要的信息为situation，Situation通过32bit来标示IPSec SA Proposal和协商在什么环境下进行的。
  • Proposal payload—-最主要的信息为Proposal transforms: xx 包含几个第一阶段策略集
  • Transform payload—-第一阶段策略8

响应方Phase 1 Sending Message 2 报文
响应者发送第二个报文，第二个报文将发回与第一个报文向匹配的第一阶段策略。9

Payloads包含下列信息

  • ISAKMP header —- 可以看到ISAKMP header中的cookie被值为各自的值
  • SA payload —- SA payload 包含与发起者发送的一致的信息
  • Proposal payload —- proposal payload包含的响应方所接受的信息
  • Transform payload —- transform payload包含响应方所接受的信息

关于Timeout的协商
IKE SA timeout时间是通过transform payloads来协商. 响应者所接受的transform payload不但要包含所有的属性, 响应者的IKA SA的timeout必须等于或者小于，如果没有这样的transform payload协商失败。响应者的lifetime小于或者等于发起者的，如果小于最后的lifetime还是发起者所指定的默认86400

IKE第一阶段Messages 3、4作用
发起方和响应双方都必须在两者之间产生DH的shared secret(共享秘密)。因为DH的协商时对等体之间的关键部分。
Diffie-Hellman Algorithm
DH算法是IPSec中的核心算法用于协商产生密钥。DH算法计算过程：10

开始交换自己的公共密钥(大A)，Alice将A给Bob，而Bob将B给Alice,他们再次执行乘幂运算,使用当事人的公共值作为底数，以生成共享密钥

根据定义的group number(1,2,5)产生g和p，并随机产生小a，通过第一个公式求出大A，并且交给Bob,Bob接收到A后将用A和随机产生的b和g,p进行第二公式的运算(Alice也同样)，两者所得出的结果是相同即产生共享的密钥（共享秘密），后续加密IPSec实际数据/HMAC的密钥通过这个共享密钥衍生。

发起方Phase 1 Sending Message 3 报文
第三个报文从发起方到响应方. ISAKMP header包头的信息类似与之前的报文，同样使用1，2所计算的cookies.然而,两个新的payloads定义了此报文类型—key exchange payload and nonce payload
Key exchange (KE) payload—KE payload中携带了DH public value X(之前公式中所提到的大A和大B)
Nonce payload—-临时的payload，产生方法同前讨论的一样11

响应方Phase 1 Sending Message 4 报文
第四个包从响应者到发起方，与第三个包非常相似包含响应者的DH public value 和nonce12

IKE第一阶段Messages 5、6作用
5，6大体来说是在加密的环境下进行对等体的认证。在5，6前对等体已经计算出了DH的共享秘密，另外基于交换的nonce计算出DH的密钥，两个对等体都预存了共享密钥并产生三个密钥，用于验证对等体及后续IKE加密的交换

这个密钥称为Session key(SKEYs)。下面是产生的三个密钥：

  • SKEYID_d—用于计算产生后续IPSec KEY资源
  • SKEYID_a—用于数据完成性效验和认证后续IKE报文
  • SKEYID_e—用于加密后续IKE报文

发起方Phase 1 Sending Message 5 报文13

  • Identity/hash payload使用SKEYID_e加密
  • Identity payload—-这个payload包含identity身份信息.发起方的IP地址或主机名
  • Hash yaload—-hash payload计算方法

响应者Phase 1 Sending Message 6 报文14

Main-Mode第一阶段使用预共享密钥认证概述

    Main-mode1-4个包完成了资源交换和收集为了最后IKE两个报文(5,6)的交换(认证)。双方进行验证重新计算hash并与接收到的hash payload进行匹配,如果两个值相同，则认为认证成功。

下列是对等体之间认证的过程
Initiator认证responder
Step1.使用SKEYID_E解密报文
Step2.通过ID_R发现配置的PK-R(pre-shared key or responder)
Step3.计算自身的Hash_R
Step4:如果接收的Hash_R等于自我生成的Hash_R,那么则认证成功

Responder认证initiator
Step1:使用SKEYID_E解密报文
Step2:通过ID_I找到配置的PK-I(pre-shared key or initiator)
Step3:计算自身的Hash_I
Step4:如果接收的Hash_I等于自我生成的Hash_I那么则认证成功

这时IKE SA建立，main-mode使用preshared key认证成功。

IKE第二阶段Messages 1、2、3作用

  1. 提交发送方第二阶段策略，发送方对实际流量处理的策略
  2. 接收方接收其中某一个策略
  3. 确认，隧道建立,建立IPSec SA.

PFS (perfect forward secrecy)

对于一种密码系统，如果一个密钥被窃取，那么只有被这个密钥加密的数据会被窃取。
有一些加密系统的密钥都是从最开始的一个密钥导出的，所以如果第一个密钥被窃取，攻击者将可能收集到足够的信息来导出其它的密钥。
在使用PFS之前，PFS使得IPSEC第二阶段的密钥是从第一阶段的密钥导出的，使用PFS，使IPSEC的两个阶段的密钥是独立的。所以采用PFS来提高安全性。
PFS是发起者到响应者一个可协商的属性,发起者提出需要支持PFS的信息包含在Quick-Mode中的Key Exchange Attribute Payload中。如果响应者支持PFS，Quick-Mode继续交换。如果响应者不支持，将返回“Attributes Not Supported”响应者并接受发起方PFS的配置。
注意，已Main-Mode提供和接受的方式协商DH组在Quick-Mode中是不可能的。因为Quick-Mode只有一次交换，DH交换必须发生在该交换中。因此，配置在两端的PFS DH组必须匹配。
(测试过程中发现在两端配置PFS可以不必相同，可能是因为IOS版本的区别测试的版本为12.4(15)T5，测试结果：
1. 发起者配置PFS响应者不配置PFS可以正常通讯PFS组为发起者。
2. 发起者配置Group5响应者配置Group2可以正常通讯PFS组为Group2。
3. 发起者配置Group2响应者配置Group5不能通讯。)

发起者Phase 2 Sending Message 1 报文15

响应者Phase 2 Sending Message 2 报文16

发起者Phase 2 Sending Message 3 报文17

Encapsulating Security Payload（ESP）
网络层协议，协议号50，ESP提供了私密性(加密)、数据完整性、源认证(HMAC)。提供了防重放攻击。封装在原始数据的header和trailer。18注：每种颜色代表所在位置包含的字段

  • Security Parameter Index(SPI)安全参数索引：通过32-bit值定义了数据用于IPSec SA进行的处理
  • Sequence number序列号：每一次包交换序列号加1，序列号是一个递增的过程。提供了防重放攻击。（重放攻击：攻击者截获一个加密的数据包不断的向目标发送要求目的解密来消耗资源达到DOS效果）
  • Payload Data：IP头后面数据部分
  • Authentication Data：HMAC后的值

Authentication Header（AH）

AH认证头，网络层协议，协议号为51。提供了重放攻击保护(可选)、数据完整性、源认证(HMAC)与ESP不同的时AH不提供私密性(加密)。在原始IP头部和TCP/UDP头间插入AH头部。19

HMAC(Hash Message Authentication Code)
HMAC为IPSec提供了数据完整性、源认证的功能、防止了中间人攻击。下面来介绍HMAC如何提供上述功能。
将原始数据加预先定义的key一起做hash，将hash后的结果和原始数据一同发到目的地，目的地接受到后用预定义key加接收到的原始数据再做一次hash，得出hash值于接收到的进行匹配如果相同则说明数据中途没有被修改。
HMAC图解20

注：OSPF路由传递也是运用了这个技术

IPSec VPN建连Debug

发表评论