解剖NetScreen (4)

本文档的Copyleft归yfydz所有,使用GPL发布,可以自由拷贝,转载,转载时请保持文档的完整性,严禁用于任何商业用途。
msn: [email protected]
来源:http://yfydz.cublog.cn

0. 声明
本文仅仅是从技术角度分析如何实现NetScreen防火墙,即如果要把本人的一台Linux机器变成NetScreen防火墙估计要作那些工作,所有观点均为个人观点,不代表任何组织或团体,只谈技术,不带任何吹捧、攻击或贬低,欢迎大家一起讨论,有错误请指正,但对文章中如有不明白的名词和概念请问google而不要问我。

1. 参考资料:
http://www.juniper.net/techpubs/software/screenos/screenos5.1.0/translated/
CE_v5_SC.pdf 第5卷:VPN

2. 前言
 
VPN现在也成了防火墙功能的一个重要组成部分,最常用的VPN协议是IPSec,其次还有PPTP、L2TP,至于SSL VPN一般是作为单独设备出现,不作为防火墙;而MPLS一般只是电信设备里用。
 
NS支持的是IPSec和L2TP,没提PPTP。NS以前不作SSL VPN,收购了一个作SSL VPN的公司后也有SSL VPN的专门产品。
 
3. 协议概述
 
3.1 IPSec
 
IPSec是一个标准协议族,最新基本框架标准在RFC4301-4309中定义,原来老标准体系(RFC2410-2412)中的主要部分:RFC2401,2402, 2404, 2406, 2407, 2408, 2409已经被废除了,只有RFC2403,2405, 2410, 2411, 2412还有效,此外还有其他相关的各种RFC和draft,一个比较完整的VPN标准列表可见:http://www.vpnc.org/vpn-standards.html
 
(感叹一声:计算机的东西变化就是快,一个东西都还没上手就已经作废了,想想还要搞一辈子真是苦啊,555)
 
IPSec使用的协议为AH(51)或ESP(50),模式为通道模式或传输模式,密钥可以是手工配置,也可以是自动密钥交换,目前实现使用 IKE协议(RFC2409),以后就是IKEv2了(RFC4306),这种情况下通信双方需要共享一些信息,该信息可能是共享的数据串,也可能是公开密钥算法中对方的公钥或证书。
 
IKE分两个阶段,第一阶段有两种协商模式,main mode和aggressive mode,第一阶段主要是身份认证和协商加密和认证算法,协商的前两步是明文,后面就是加密的了,NAT-T,XAUTH等在此阶段使用;第2阶段只有一种模式,quick mode,协商信息都是都是加密的,协商通信的SA,确定通信加密密钥(对称加密密钥),PFS在此阶段使用。
 
IPSec中涉及几乎所有PKI相关技术,关于PKI可参考PKCS系列,关于X.509证书可以参考RFC2459,证书管理协议参考RFC4210,不过国内PKI建设还是比较差,真正用证书的IPSec不多。
 
IPSec本身还有很多相关技术,如:为提高安全性的完美向前加密PFS;为支持NAT环境的NAT-T;检测对方失效的DPD;提供用户级认证的XAUTH;通过IPSec通道传输多播/广播信息等。
 
IPSec的实现分两类,一种是网关,为内部网络的通信进行保护,一般称为VPN网关;一种是主机,为本机的通信进行保护,一般称为VPN客户端。在RFC中规定,网关必须实现通道模式,而传输模式是可选的,而主机必须同时支持通道和传输模式。
 
IPSec实际应用环境分为静态网关到静态网关;静态网关到动态网关;静态网关到静态客户端;静态网关到动态客户端;动态网关到动态网关;动态网关到动态客户端等多种类型,后两种的实现需要第3方设备的支持,如VPN管理中心,DDNS等。
 
IPSec设备使用模式可分为路由模式或透明模式,还要支持一些特殊网络拓扑环境,如星型VPN、同网段VPN通道等。
 
IPSec的高可用性分两类,一是通道热备,通过VPN网关冗余实现,要能实现通道状态备份;二是通道均衡,VPN流量自动均衡,自动识别失效通道。VPN的高可用性属于难度很大的功能。
 
所以说,目前要实现某一情况的IPSec现在不算很难,因为现在open source的IPSec实现已经不少,但能完全实现上述所有情况的还是比较困难的。
 
在Linux下,IPSec最有名的实现是freeswan,并有很多相关补丁,可以实现绝大多数IPSec需求,但关于高可靠性方面是个空白。在国内使用的话,一般还会要求支持国产加密算法。在Linux2.6中,已经自带了IPSec的实现(native IPSec),不过在内核中它和freeswan只能二选一,不能同时使用。
 
freeswan提供的IPSec是基于路由的,不支持基于策略的VPN;使用native IPSec和netfilter配合,也许能实现基于策略的VPN。
 
3.2 L2TP
 
L2TP标准在RFC2661中定义,目前大部分实现都是基于此RFC,而最新的L2TPv3则在RFC3931中定义。其实l2TP只是提供一种封装方法,并没有加密认证过程,所以真正要保证安全一般是和IPSec结合,在RFC3193中定义了如何用IPSec封装L2TP。
 
Linux下有l2tpd的L2TP实现,将L2TP包封装在UDP1701端口数据中,防火墙作为服务器监听UDP1701端口。
 
L2TP/PPTP的应用环境相对简单,一般就是VPN设备作为服务器,然后由远程的客户端来连接,在Windows中自带了PPTP/L2TP客户端,比IPSec要容易实施,所以在某些不需要网关互连的环境下用PPTP/L2TP比IPSec要方便。
 
3.3 需求小结
 
除了具体的各种功能需求外,其实有个最常用的需求也是最难实现的需求,是要求VPN通道在任何情况下如果不是手工断开的话,都能一直保持稳定不断,不需要任何人工参与,这是一个实现起来非常难的需求,要求VPN设备能具备很强的鲁棒性,而open source的代码大都没有如此鲁棒,需要自己增加不少处理措施。
 
老实说,我对IPSec通信的可靠性还是有一点怀疑,AH、ESP包中只有序列号而没有确认号,NAT-T只是包装在UDP包而不是TCP包,因此没有重传机制,如果使用CBC模式的加密算法,只要一个包丢失后续的包就无法解析了,因此VPN通道可能需要经常重新建立。不过在目前实际应用看,好象通道自动重建不是很多,看来是现在的网络可靠性还是比较高,丢包的概率很小了。
 
4. NetScreen的IPSec
 
NetScreen的加密认证算法使用硬件实现,所以速度上比软件实现的要快很多。
 
4.1 证书
 
NS使用两种密钥创建机制创建VPN通道:手动密钥和具有预先共享密钥或证书的“自动密钥IKE”。
 
NS支持证书、PKCS#7、可通过LDAP或HTTP在线检索CRL。
 
NS证书处理过程是先在设备上生成证书请求,下载后发送给CA进行签发,将CA签发的证书再上载回设备,同时也需要上载CA的公钥证书和 CRL,也可以使用SCEP自动获取证书和自动更新证书,使用OCSP协议来检查证书状态。SCEP和OCSP是freeswan所不支持的。NS也可以自签证书,说明其内部也建了个CA,openssl可用来建CA。
 
4.2 加密选项
 
NS提供的加密选项很多,基本上在IPSec处理时只要有不同选择时都提供有选项,给用户的自由度比较大,但对用户的要求也就比较高了,不过一般情况下就用缺省配置就可以了。国内产品一般没提供那么多的选项配置,NS可配置的包括:
 
ESP/AH;通道模式/传输模式;自动IKE/手工密钥;main/aggressive; 证书/共享密钥;RSA/DSA;密钥长度512/768/1024/2048;DH组:1/2/5;加密算法:AES/DES/3DES;认证算法:MD5/SHA1;IKE ID:IP/U-FQDN/FQDN/ASN1-DN;PFS:Y/N;replay检测:Y/N;

4.2 基于路由和基于策略的通道
 
NS提供了基于路由和基于策略的VPN通道,由于IPSec是第三层实现的,SA定义中也没有上层协议的信息,所以基于路由应该是最自然和合理的,基于策略只是由于需求的提高而增加的,所以需要增加新的处理措施,所以一般基于策略的VPN应该是更消耗资源一些。
 
freeswan是只支持基于路由的VPN,如何在此基础上实现基于策略的VPN还没想清楚,或许由策略路由来辅助可能有帮助。
 
基于策略的VPN是在配置策略动作时指定为加密处理,CheckPoint也是这样作的;基于路由的VPN一般是先要配置VPN通道信息,NS还支持在VPN通道接口上使用动态路由协议,这样在大型网络中比较灵活。
 
个人感觉基于路由和基于策略的区别是在于通道的建立时机,基于路由的IPSec是事先建立的,以后两点间的通信就全走通道了;而基于策略的IPSec是动态的,有点象拨号中的“dial on demond”,在有数据需求是才去建立通道,数据通信完就结束。
 
4.3 站点到站点的VPN(网关到网关)
 
freeswan的VPN通道接口“ipsec*”是VPN配置文件中绑定到固定网卡上的,使用和该网卡相同的地址,VPN通道建立后,自动建立到达对方的路由,不需要另外配置。而NS的VPN通道接口可以自己单独定义,可以配也可以不配地址,VPN通道路由需要自己添加。
 
对于动态地址,NS使用FQDN来定义对方,建立通道前通过DNS解析获取对方实际地址,这点freeswan也可以作。不过这要求设备支持DDNS,在获取IP地址后自动通知DNS服务器自己的IP。
 
对于重叠地址的VPN通道连接,普通情况建立的VPN通道是无效的,因为当访问对方的IP时会认为是访问本地,这时需要对两边地址进行转换,数据在进入VPN通道前就要转换地址。不过NS支持得有限,只支持部分地址的点转换,好象不能实现网络对网络的全面转换。这种地址转换本身不属于 IPSec,只是IPSec的一个预处理过程,netfilter本身不支持这样的转换模式,但可以简单修改后支持,修改量不大,而且最终可以实现网络对网络的一对一转换,也就是可以访问对方网络内的任意一台机器,而不是有限的服务器。
 
透明模式VPN,是指防火墙运行在透明模式下,但防火墙上配地址,用该地址建立VPN通道保护防火墙内部到外部的通信。freeswan是可以支持的,使用前先启动桥,将ipsec网卡绑定到桥网卡就可以了。
 
4.4 拨号VPN
 
拨号VPN的特点就是启动VPN时还不知道对方地址,服务器端是处在监听状态等待对方来连接。在freeswan中称之为Road Warrior,配置时除了对方地址等为ANY外其他参数基本和网关到网关的类似。一般这种情况下会应用XAUTH来认证对方。NS是通过证书中的ID或共享密钥来识别对方,也可以启用XAUTH。从NS的配置实例看,NS可以通过对方子网来区分对方,这点在freeswan中作不到。
 
对于多个拨号对端,NS提供组IKE ID、共享IKE ID来通配对方。
 
freeswan是通过地址匹配来找连接信息的,所以只能配一个匹配任意IP地址的连接,匹配了第一条连接后就不会再去找第二条连接的信息。
 
4.5 高级VPN功能
 
NS支持NAT-T、VPN通道的监控、每个通道接口多个通道、冗余VPN网关、背对背VPN、星型VPN等。前3个freeswan都可以支持,在某些特定配置下也可以支持星型VPN。
 
不过不太理解背对背和星型有什么实际区别,NS中背对背用在不同区段,需要查找策略;星型用在同一区段,不需要查找策略,可本质上有什么区别呢?不都是从一个通道进来,VPN设备解密,再从另一个通道里发出去的过程么?查不查策略和IPSec本身有什么关系?
 
freeswan本身不支持冗余处理,需要自己定义相关的处理,因为这种多网关协商取最高优先权的处理模式不是RFC定义的,需要自己定义。不过NS也不能实现网关间的全部数据连接状态的冗余备份,切换后连接会重置,但可以以状态检测失效为代价来使连接不重置。
 
5. NetScreen的L2TP
 
NS的L2TP支持使用IPSec进行加密,而且只能使用传输模式,NS的L2TP本身的功能基本上Linux下的l2tpd都能提供,很容易实验通;不过和IPSec结合比较麻烦,没试成功过。不过以其那么麻烦地用L2TP+IPSec,还不如用PPTP,Linux下有完整的PPTP实现和相关MS-MPPE的补丁,可以提供128位的加密保护。

6. 小结
 
NS的VPN功能的确算比较完整的,尤其是IPSec部分,不过影响其在国内应用的不是技术而是法律因素,很多情况是禁止使用国外的VPN产品的。
 
国内的VPN厂家不算少,可大部分还是基于freeswan修改的,而且是靠软件实现加密和认证,国密办允许的加密卡速度都比较慢,好象都没有超过百兆的,还不如AES的软件加密来得快,硬件加速卡国内基本没有产的,都是美国或台湾产的,感觉国内还是比较落后。
 
对于常用的公开的加密算法如AES、3DES等,目前还没有公开的破解,但没人保证美国NSA已经能够破解,所以真正国内只允许使用国密办允许的加密算法,都是硬件化的,靠通过算法保密来提高可靠性,使用软加密的都是打擦边球;对于HASH算法,由于王小云教授的横空出世,MD5和SHA1相继被破解,感觉一下没有合适的HASH算法可用了,提出新的可靠HASH算法是密码界的最紧迫的任务了。

猜你喜欢

转载自cxw06023273.iteye.com/blog/866807