IPSEC配置VPN.docx
- 文档编号:24511688
- 上传时间:2023-05-28
- 格式:DOCX
- 页数:39
- 大小:2.12MB
IPSEC配置VPN.docx
《IPSEC配置VPN.docx》由会员分享,可在线阅读,更多相关《IPSEC配置VPN.docx(39页珍藏版)》请在冰豆网上搜索。
IPSEC配置VPN
信息安全实验报告
实验8-1VPN实验
一实验目的
通过实验了解虚拟专用网的实验原理,熟悉硬件VPN的配置,掌握在Windows操作系统中利用IPSec(IP协议安全协议)配置VPN的方法。
二实验原理
2.1介绍
所谓VPN(VirtualPrivateNetwork,虚拟专用网络),是指将物理上分布在不同地点的网络通过公用骨干网联接而成逻辑上的虚拟子网,这里的公用网主要指Interet。
为了保障信息在Internet上传输的安全性,VPN通过建立隧道机制实现,隧道机制可以提供一定的安全性,并且使VPN中分组的封装方式、地址信息与承载网络的封装方式、地址信息无关。
VPN技术采用了认证、存取控制、机密性、数据完整性等措施,以保证信息在传输中不被偷看、篡改、复制。
2.2VPN的类型
VPN类型有:
远程访问虚拟网(AccessVPN)、企业内部虚拟网(IntranetVPN)和企业扩展虚拟网(ExtranetVPN)。
这三种类型的VPN分别与传统的远程访问网络(Client-LAN)、企业内联网Intranet以及企业网和相关合作伙伴的企业网所构成的Extranet相对应(LAN-LAN)。
1、AccessVPN
在AccessVPN的应用中,利用二层网络隧道技术在公用网络上建立VPN隧道连接来输私有网络数据。
AccessVPN的结构有两种类型:
一种是用户发起(Client—initiated)的VPN连接;另一种是接入服务器发起(NAS—initiated)的VPN连接。
2、IntranetVPN
IntranetVPN通过公用网络进行企业各个分布点互联,是传统的专线网或其它企业网的扩展或替代形式。
利用IP网络构建VPN的实质是通过公用网在各个路由器之间建立VPN安全隧道来传输用户的私有网络数据,用于构建这种VPN连接的隧道技术有IPSec、GRE等。
结合服务商提供的QoS机制,可以有效、可靠地使用网络资源,保证了网络质量。
3、ExtranetVPN
ExtranetVPN是指利用VPN将企业网延伸至合作伙伴与客户。
在传统的专线构建方式下,Extranet通过专线互联实现,网络管理与访问控制需要维护,甚至还需要在Extranet的用户侧安装兼容的网络设备。
虽然可以通过拨号方式构建Extranet,但需要为不同的Extranet用户进行设置,同样降低不了复杂度。
ExtranetVPN以其易于构建与管理为解决以上问题提供了有效的手段,其实现技术与AccessVPN和IntranetVPN相同。
Extranet用户对于ExtranetVPN的访问权限可以通过防火墙等手段来设置与管理。
2.3VPN协议
目前VPN主要采用四项技术:
隧道技术(Tunneling)、加解密技术(Encryption&Decryption)、密钥管理技术(Keymanagement)、身份认证技术(Authentication).其中隧道技术是实现VPN的底层核心技术。
目前存在多种支持隧道技术的协议,如通用路由封装协议(GRE),点到点隧道协议(PPTP),二层转发协议(L2F)、二层隧道协议(L2TP)、IP安全协议(IPSec)、多协议标记交换(MPLS)等,其中L2TP、1PSec和MPLS最引人注目.而1PSec和MPLS是当前研究讨论的重点隧道协议按工作在ISO网络模型的第几层可分为两种:
第二层隧道协议(如PPTP、L2F、L2TP和MPLS),第三层隧道协议(如GRE和IPSee),其本质区别在于用户的IP数据包是被封装在何种数据包中在隧道里传输的.不同的隧道协议可以配合使用。
第二层隧道协议L2TP协议
L2TP隧道协议是典型的被动式隧道协议.它结合了L2F和PPTP的优点.可以让用户从客户端或访问服务器端发起VPN连接。
L2TP是把链路层PPP帧封装在公共网络设施如IP、ATM、帧中继中进行隧道传输的封装协议,它结合了L2F和PPTP的优点,可以让用户从客户端或接入服务器端发起VPN连接。
L2TP定义了利用公共网络设施封装传输链路层PPP帧的方法。
L2TP的好处在于支持多种协议,用户可以保留原来的IPX、AppleTalk等协议原有的IP地址,企业在原来非IP网上的投资不致于浪费.另外,L2TP还解决了多个PPP链路的捆绑问题。
L2TP主要由LAC(接入集中器)和LNS(L2TP网络服务器)构成。
LAC支持客户端的L2TP,用于发起呼叫,接收呼叫和建立隧道。
LNS是所有隧道的终点,L2TP使得PPP协议的终点由LAC延伸到LNS。
第三层隧道协议IPSec协议
1PSec是一组协议的总称.它包括安全协议及为这些安全协议协商安全参数的密钥管理协议。
1PSec提供访问控制、数据完整性、身份认证、重放保护、加密以及数据流分类加密等服务.IPSec在IP层提供这些安全服务,包括了两个子协议:
EncapsulatedSecurityPayload(ESP),保护IP包数据不被第三方介入,通过使用对称加密算法(例如Blowfish、3DES)。
AuthenticationHeader(AH),保护IP包头不被第三方介入和伪造,通过计算校验以及对IP包头的字段进行安全散列来实现。
ESP和AH可以根据环境的不同,分别或者一同使用。
IPsec既可以用来直接加密主机之间的网络通讯(也就是传输模式);也可以用来在两个子网之间建造“虚拟隧道”用于两个网络之间的安全通讯(也就是隧道模式)。
通信双方何时应实现ESP或AH保护,保护什么样的通信,保护的强度以及何时应实现密钥协商等,受到实施IPSec的安全策略的控制。
AH提供的数据完整性保护,ESP提供数据完整性和机密性保护,AH和ESP同时具有认证功能。
AH或ESP协议都支持两种模式的使用:
隧道模式和传输模式.隧道模式对传经不安全的链路或Internet的专用lP内部数据包进行加密和封装(此种模式适合于有网络地址转换(NAT)的环境),其报文封装方式如图2所示。
传输模式直接对IP负载内容(即TCP或UDP数据)加密(适合于无NAT的环境)。
认证头(AuthenticationHeader,AH)是一个安全协议头。
插在IP头和上层协议头(如TCP/UDP)之间,可在传输模式下使用,为IP包提供数据完整性和验证服务。
通过使用数据完整性检查,可判定数据包在传输过程中是否被篡改:
通过使用验证机制,终端系统或网络设备可对用户或应用进行验证、过滤通信流;验证机常4还可防止地址欺骗攻击及重播攻击。
AH协议所提供的认证覆盖了IP头的大多数字段和上层协议的所有字段。
但是,IP头中的某些字段值在报文传送的过程中会被路由器改变,所以报文的发送方不可能预知信宿方所见的这些字段的值。
所以,AH不能保护这样的字段。
AH可以单独应用,也可以与ESP协议一起应用,
还可以以隧道方式嵌套使用。
ESP协议也提供可选择的认证服务,AH与ESP二者的认证服务的差别在于它们计算时所覆盖的范围不同,也就是说,ESP认证不覆盖ESP头前面的IP头。
ESP为IP数据包提供完整性检查、认证和加密,提供机密性并可防止篡改。
ESP服务依据建立的安全关联(SA)是可选的。
然而,也有一些限制:
完整性检查需要和认证一起进行。
,仅当与完整性检查和认证一起时重播(Replay)保护才是可选的,重播保护只能由接收方选择。
ESP的加密服务是可选的,但如果启用加密,则也就同时选择了完整性检查和认证。
因为如果仅使用加密,入侵者就可能伪造包以发动密码分析攻击。
ESP可以单独使用,也可以和AH结合使用。
一般ESP不对整个数据包加密,而是只加密IP包的有效载荷部分,不包括IP头。
但在端对端的隧道通信中,ESP需要对整个数据包加密。
ESP报头插在IP报头之后,TCP或UDP等传输层协议报头之前。
ESP由IP协议号"50"标识。
如图:
ESP报头字段包括:
·SecurityParametersIndex(SPI,安全参数索引):
为数据包识别安全关联。
·SequenceNumber(序列号):
从1开始的32位单增序列号,不允许重复,唯一地标识了每一个发送数据包,为安全关联提供反重播保护。
接收端校验序列号为该字段值的数据包是否已经被接收过,若是,则拒收该数据包。
ESP报尾字段包括:
·Padding(扩展位):
0-255个字节。
DH算法要求数据长度(以位为单位)模512为448,若应用数据长度不足,则用扩展位填充。
·PaddingLength(扩展位长度):
接收端根据该字段长度去除数据中扩展位。
·NextHeader(下一个报头):
识别下一个使用IP协议号的报头,如TCP或UDP。
ESP认证报尾字段:
·AuthenticationData(AD,认证数据):
包含完整性检查和。
完整性检查部分包括ESP报头、有效载荷(应用程序数据)和ESP报尾。
如下图:
图4ESP的加密部分和完整性检查部分
ESP报头的位置在IP报头之后,TCP,UDP,或者ICMP等传输层协议报头之前。
如果已经有其他IPSec协议使用,则ESP报头应插在其他任何IPSec协议报头之前。
ESP认证报尾的完整性检查部分包括ESP报头、传输层协议报头,应用数据和ESP报尾,但不包括IP报头,因此ESP不能保证IP报头不被篡改。
ESP加密部分包括上层传输协议信息、数据和ESP报尾。
ESP隧道模式和AH隧道模式与传输模式略有不同。
在隧道模式下,整个原数据包被当作有效载荷封装了起来,外面附上新的IP报头。
其中"内部"IP报头(原IP报头)指定最终的信源和信宿地址,而"外部"IP报头(新IP报头)中包含的常常是做中间处理的安全网关地址。
与传输模式不同,在隧道模式中,原IP地址被当作有效载荷的一部分受到IPSec的安全保护,另外,通过对数据加密,还可以将数据包目的地址隐藏起来,这样更有助于保护端对端隧道通信中数据的安全性。
ESP隧道模式中签名部分(完整性检查和认证部分)和加密部分分别如图所示。
ESP的签名不包括新IP头。
图5ESP隧道模式
下图标示出了AH隧道模式中的签名部分。
AH隧道模式为整个数据包提供完整性检查和认证,认证功能优于ESP。
但在隧道技术中,AH协议很少单独实现,通常与ESP协议组合使用。
图6AH隧道模式
三实验环境
多台联网WindowsXPProfessional计算机。
四实验内容和步骤
•1.捕获VPN协商和加密后的数据包,过程如下:
可以看到本机在连接需要VPN连接的其他主机时,首先收到的第一个包是需要协商安全的IP连接,然后ping通,以下是分析其加密过程:
•2.对应捕获的数据包,分析IPSec建立连接和加密的原理。
分析双方连接的数据包,第一部分建立连接如下:
(1)因特网密钥交换协议(IKE)
IKE协议属于IPSecVPN体系的动态密钥协商部分,它是可供选择的动态密钥交换协议之一,目前已经成为事实上的工业标准。
IKE协议用来进行VPN的认证与SA会话密钥的协商,它沿用了Internet安全关联和密钥交换协议(ISAKMP)1201的基础、Oakley密钥确定协议的模式以及SKEME协议的共享和密钥更新技术。
IKE协议可以动态地建立SA,为通信双方提供IPScc安全通信所需的相关信息。
IKE协议为自动密钥交换奠定了基础,其高强度与可靠性是IPSecVPN数据安全传输的先决条件和保证。
IKE是个非常复杂的协议,整个IKE协议规范分为三个部分:
ISAKMP、IKE、DOL。
IKE协商机制的目的是产生一个通过验证的密钥和提供双方同意的安全服务,即最终提供IPSecSA,使IPSecVPN之间能够建立安全的数据通信隧道。
IKE通过两个阶段的协商过程来建立IPSecSA。
第一阶段建立ISAKMPSA,它的作用是保护接下来的第二阶段中协商IPSecSA(即通信实际用到的SA)的过程的安全,第二阶段利用第一阶段得到的ISAKMPSA建立IPSecSA。
ISAKMPSA和IPSecSA的区别在于前者是双向的。
IKE把动态协商过程定义成两个阶段的原因是为了提高IKE的协商效率。
因为第一阶段协商的结果可应用于多个第二阶段协商过程,而第二阶段协商过程可以同时进行多个,这样就能减少传输往返和幂运算,从而大大提高了协商的效率。
对于协商过程的第一阶段,IKE存在两种模式:
主模式和野蛮模式。
主模式是一种身份保护交换模式,而野蛮模式基于ISAKMP的野蛮交换法。
本次试验中的IPSEC采用主模式。
在第二阶段,IKE提供了快速模式,它的作用是为IKE之外的其它协议协商SA。
对于参与密钥交换的双方,如果建立了ISAKMPSA,那么不管谁是发起者,任何一方都可以主动发起第二阶段的协商。
在IKE整个协商过程中,ISAKMP消息(或者称为IKE消息)被用来进行SA的协商交互。
第一阶段
协商创建一个通信信道(ISAKMPSA),并对该信道进行认证,为双方进一步的IKE通信提供机密性、数据完整性以及数据源认证服务:
主要用来建立对ISAKMP消息自身的保护措施,并不建立用于保护用户数据流的SA和密钥。
在阶段一中使用的密码学操作是一些大计算量的操作,破解困难,但不经常使用,因为一个第一阶段的交换可以支持多重的后续第二阶段交换。
,第一阶段的初始化工作一般一天或一周才做一次,而第二阶段的初始化工作几分钟就做一次。
第一阶段提供两种模式:
主模式和野蛮模式。
IKE的主模式和野蛮模式选用4种验证方法,不同的验证方法得到不同的密钥值:
SKEYID,并可生成后续的3种密钥:
SKEYID_d,SKEYID_a和SKEYID_e。
SKEYID_d用于为IPSec以及其它协议提供密钥材料,SKEYID_a用来保障1KE消息的完整性以及对数据源的身份进行验证,SKEYID_e用:
F对IKE消息进行加密。
计算公式如下:
此外,发起者和响应者要以不同的方式计算自己的摘要,发起者和响应者的摘要如下:
主模式交换
该阶段所捕获的包如下:
主模式中共包含6条消息,最终建立ISAKMPSA,6条消息包括属性协商、D—II交换、随机数nonce交换以及对双方身份的认证。
主模式的交换如下所示。
主模式的主要功能是身份保护,主要采用4种方法:
(1)预共享密钥(PresharedKey)验证;
(2)数字签名(DigitalSignature)验证;
(3)公共密钥加密(PublicKeyEncryption)验证;
(4)修改过的公共密钥加密(RevisedPublicKeyEncryption)验证。
下面是这4种验证方法的交换过程。
1.预共享密钥验证
预共亭密密钥验证,这是最简单的一种验证方法,发起者和响应者必须事先协商一个共享密钥,在主模式中采用预共享密钥验证的过程如下图所示。
其中:
HDR是每次交换的ISAKMP头;HDR*表示后面的载荷被加密;
Ni和Nr表示随机数nonce载荷;
KE是D-H交换公钥载荷;
IDi和IDr是ISAKMP身份标识载荷。
在预共享密钥验证的主模式中,SKEYID的计算公式如下:
SKEYID=prf(Pre—shared—key,Ni,Nr)
其中Prc-shared—key是预共享密钥,由于生成SKEYID时用到随机数,
所以交换双方的每一次密钥协商过程产生的SKEYID必定不同。
2.数字签名验证
主模式也可通过公共密钥签名加以验证,要么采用DSS算法,要么采用RSA算法,公共密钥通常是从证书(Cert)中获取的,而IKE允许证书的交换,而且也允许从一个通信远方那里索取证书,发起者和响应者分别用自己的私钥对HASH签名,对方利用相应的公钥验证签名,具体过程如下图所示。
其中,可选的载荷用[]表示,发起者和响应者的签名及SKEYID的计算方法如下:
SIG_I=PRVKEY_I(HASH_I)
SIG—R=PRVKEYR(HASH—R)
SKEYID=prf(Ni,Nr,gxy)
3.公共密钥加密验证
共有两种验证的方法采用加密Nonce的交换,一种是标准的公共密钥加密验证方法,一种是修订过的公共密钥加密验证方法,标准的公共密钥加密验证的过程如下图所示。
图中,<>PK-X(X表示i或r),表示用“x”的公共密钥进行加密,在第3条消息中,发起者在响应者传送身份之前就己知响应者的公钥。
在收到散列值后,发起者和响应者分别验证对方的身份。
SKEYID的计算公式为:
SKEYID—prf(hash(Ni,Nr),Cookie_I,Cookie_R)
上述公钥加密验证的缺点主要在于需要进行4次耗时的加密运算,在修订过的公共密钥加密验证中修订了这种缺陷,只要求一半的公共密钥运算,而对其它载荷的加密采用对称加密算
第二阶段
通过主模式或野蛮模式建立好ISAKMPSA之后,可以用它为其它安全协议(如IPSec)生成相应的SA,这些SA是通过快速模式来建立的。
快速模式交换的信息必须在ISAKMPSA的保护下,除了ISAKMP头,其它载荷都必须加密,快速模式对载荷的排列顺序有要求,即ISAKMP头、散列载荷、SA载荷。
HASH值用来验证消息。
在单独一个ISAKMPSA的保护下,可以并发地执行多个快速模式交换。
在一次快速交换模式中,通信双方需要协商拟定IPSecSA的各项特征,并为其生成密钥。
ISAKMPSA保护快速模式交换的方法是对其进行加密,并对消息进行验证。
消息验证还是通过prf进行,来自ISAKMPSA的SKEYID_a作为一个密钥,对快速模式交换的整个信息进行验证,而通过SKEYIDe则可保障交换的机密性。
具体交换过程如图所示。
交换消息中的哈希值为:
HASH
(1)=prf(SKEYI_a,M_ID,SA,Ni,[gx],[IDi,IDr])
HASH
(2)=prf(SKEYID_a,M_ID,Nr,SA,Ni,[gy],[IDi,IDr])
HASH(3)=prf(SKEYID_a,0,M_ID,Ni,Nr)
其中[]中的内容为要求完美前向服务(PFS)的计算方法,M_ID是IKE
报文的ISAKMF报头中的消息标识。
如果不要求完美前向服务,则KE载荷不被交换,新密钥为:
KEYMAI=prf(SKEYID_d,protocol,SPI,Ni,Nr)
如果要求完美自前向服务,则交换KE载荷,新密钥为:
KEYMAI=prf(SKEYID_d,gxy,protocol,SPI,Ni,Nr)
gxy是KE载荷交换生成的D-H共享密钥,protocol和SPI是ISAKMP载荷中协议域和SPI域。
这样,1KE协商完成:
为通信双方建立了一个安全、认证的通道;建立了一个1PSecSA并为IPSec生成密钥材料。
为确保进行顺利和安全的Internet协议安全(IPSec)通信,Internet密钥交换(InternetKeyExchange,IKE)协议将执行一项双阶段协商。
IKE同时结合了Internet安全关联密钥管理协议(ISAKMP)和Oakley密钥确定协议的组合。
对于Windows2000和WindowsXP的IPSec实施,这两个阶段分别是主模式(MainMode)和快速模式(QuickMode)协商。
∙主模式
主模式(也称为第1阶段)IKE协商在两台计算机之间建立一个称为ISAKMP安全关联(SecurityAssociation,SA)的安全通道。
ISAKMPSA用于保护安全协商。
为实现这个目标,主模式协商将确定特定的一组密码保护套件(cryptographicprotectionsuite),交换加密材料来建立共享秘密密钥,以及对计算机身份进行身份验证。
∙快速模式
快速模式(也称为第2阶段)IKE协商在两台计算机之间建立一个通道来保护数据。
由于这个阶段涉及SA(代表IPSec服务进行协商)的创建,因此在快捷模式期间建立的SA称为IPSecSA。
在快捷模式期间,加密材料将被刷新,或在必要时生成新的密钥。
在此期间还会选择一个用于保护特定IP流量的保护套件。
快速模式没有被看作是完整的交换,因为它依赖主模式交换。
ISAKMP消息
ISAKMP消息是源和目标UDP端口被设置为500的UDP消息的有效负载,由一个ISAKMP报头和一个或多个ISAKMP有效负载组成。
ISAKMP有效负载包含协商信息,并且对大多数ISAKMP消息来说都是加密的。
加密保护了大多数协商避免被捕获了ISAKMP流量的恶意用户所查看。
Windows2000和WindowsXP的IPSec用于主模式和快速模式协商的ISAKMP有效负载包括:
∙安全关联
包含推荐的保护套件的一个列表,或者为某个SA选定的一个保护套件。
∙开发商ID
包含开发厂商定义的一个字符串或一个数字,以便某个IPSec实施能够识别正在运行相同实现的IPSec对等方。
开发商ID值必须是唯一的,并且通常是某个IPSec实施的设计者所创建的众所周知的文本的hash码。
在WindowsXP和Windows2000的IPSec中,开发商ID值为:
0x1E-2B-51-69-05-99-1C-7D-7C-96-FC-BF-B5-87-E4-61-00-00-00-02。
∙密钥交换
包含Diffie-Hellman密钥交换过程的Diffie-Hellman公共密钥信息。
∙Nonce
包含一个仅使用一次的伪随机数。
Nonces可提供中继信息。
∙Kerberos令牌
包含一个IPSec对等方的当前Kerberos令牌,IPSec对等方通过一个Kerberos密钥分发中心(KerberosKeyDistributionCenter,KDC)使用它来对另一个IPSec对等方进行身份验证。
∙身份验证
包含用于识别和验证一个IPSec对等方身份的信息。
∙Hash
包含一个hash值,这个值是一个hash函数对一组字段或其他参数所执行的计算结果。
Hash有效负载可用于提供IPSec对等方的完整性或身份验证。
∙证书请求
包含可信任的根认证中心(certificationauthoritie,CA)的一个列表,IPSec对等方从这些认证中心那里接受一个用于身份验证的证书或证书链。
∙证书
包含一个IP对等方的证书或证书链。
∙签名
包含一个数字签名,它是对一组字段或参数执行计算来得出的。
Signature有效负载在主模式协商的身份验证阶段中提供数据完整性和认可服务。
∙通知
包含控制信息,比如错误条件。
除了前四条消息之外,所有消息的其他有效负载都是加密的,并且根据所选择的身份验证方法而定。
这些消息将在“主模式协商,第3部分:
身份验证”一节中进行讨论。
返回页首
主模式协商
主模式协商在以下三个部分中进行:
1.保护套件的协商
2.Diffie-Hellman交换
3.身份验证
主模式协商由一组六条ISAKMP消息的组成。
发起者和响应者均发送3条消息。
发起者是通过发送第一个ISAKMP消息来发起安全通信的IPSec对等方。
响应者发送第二个消息,它是发起者正在向其请求安全通信的IPSec对等方。
前四条主模式消息未经加密,如下表(表1)所示。
表1主模式消息1至4
主模式消息
发送者
有效负载
1
发起者
安全关联(包含建议)、开发商ID
2
响应者
安全关联(包
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IPSEC 配置 VPN
![提示](https://static.bdocx.com/images/bang_tan.gif)