的使用IPsec.在整个网络行业普遍存在。但是，许多组织正在使用IPSec，以较弱的连接安全性导致的次优配置。许多组织使用具有预共享密钥和弱加密算法的IPSec，无需身份验证。组织应重新考虑如何使用IPSec，以确保其为其组织的私人通信提供最大的安全性。
几乎所有网络专业人员都熟悉互联网协议安全性（IPsec.） 标准。互联网工程工作组（IETF.）通过为数据提供机密性，真实性和完整性来创建IPSec作为一种方法来保护端到端的IP通信。最初，IPSec是一种验证和加密IPv6数据包的方法。但是，这是一个如此伟大的想法，它也适用于IPv4。
许多组织依赖IPsec来保证外部通信的安全，以防止嵌入式应用程序数据被窃听。IPsec可以提供数据源认证、重放保护、机密性、无连接完整性和访问控制。IPsec可以防止窃听、重放、欺骗报文攻击、MITM (man -in- middle)攻击和DoS (Denial of Service)攻击。IPsec可以执行所有这些功能，因为IPsec已经被制造商正确地实现，并且管理员已经在他们的设备和软件中正确地配置了。然而，不幸的事实是，许多组织没有使用行业最佳实践建立他们的IPsec部署。
几年前，Mark Lewis还写了一篇关于“IPsec vpn失败的十大原因“涵盖了关于IPSec配置选项的相同概念。
预共享秘密的问题
关于加密的第一件事之一是安全性是密钥的保密而不是算法的保密。加密算法是公共的，以便行业可以验证数学以确保算法是安全的。在公共/私钥加密中，通过保持私钥安全保证安全性。
IPsec部署以相同的方式运行。但是，许多组织坚持配置在连接的两端相同的预共享秘密。不是花时间设置证书颁发机构（CA）并向每个IPSec端点发出单个键，管理员们在每个IPSec端点上使用相同的键并使用相同的键。因此，如果一个端点受到损害或物理上被盗，则所有其他IPSec链接都很脆弱。
许多隧道模式的IPsec连接可以使用相同的密钥保持多年的运行。随着IT人员的来来去去，预共享密钥的保密性会随着时间的推移而受到侵蚀。证书要强大得多，但是需要做一点额外的配置工作。但是，如果您的组织坚持使用预共享密钥，那么您应该有一个过程，每隔几个月更改它们，并在不同的连接上使用不同的密钥。
NAT的问题
困扰IPSec部署的其他重要问题是许多组织都大量使用网络地址解读（NAT）（或者相当端口地址转换（PAT））。由于他们的地址隐藏属性及其感知的安全福利，Nats在企业组织中普遍存在。当外部标题中的源IP地址随着数据包从数据源传输，通过NAT和目的地接收时，这会影响IPsec。这会导致困难验证标题（啊）因为它保留了经过身份验证的标题内的原始IP标题。如果外部标题以任何方式更改，则内部数据包验证失败，因为内部数据包的源地址不再匹配外包分组的源地址，并且丢弃数据包。
这就是许多组织转向使用的原因NAT遍历解决这个问题。NAT遍历技术封装UDP端口号4500中的IPSec报文（尽管可以选择其他端口）并在UDP端口500中封装IKE消息。然后，随着数据包从源发送到目的地，内部IPSec数据包保留在粘性中仅使用NAT修改外部IP标头。这些问题是，即使使用NAT遍历，许多组织仍然无法使用或不使用啊，所以他们的实现只使用封装安全有效载荷(ESP)和ESP-HMAC。
随着IPv6部署，组织将使用聚合全球单播地址。这些公共地址不需要使用任何NAT功能。因此,所有节点开始使用全球单播IPv6地址然后将不需要NAT。没有NAT之后我们可以肯定的是,内部和外部的IPv6地址数据包将匹配,我们可以使用啊结合ESP higher-integrity IPsec连接。
在IPv6网络中，不需要NAT来提供额外的IP地址。IETFRFC 4864.提供了很好的覆盖范围，“对IPv6”周围的“本地网络保护”并描述了IPv6中不需要NAT的原因。
但是，除了我写这个，我们现在有一个新的IETFRFC 6296.已出版《ipv6到ipv6网络前缀转换》。这里的区别是，这种方法提供了IPv6地址的1:1映射，不需要pat类型的函数来处理IPv6地址短缺的问题，就像我们在IPv4中遇到的那样。
由于IPv6要求IPv6授权使用IPSec，存在误解IPv6比IPv4更安全。IETF.RFC 2460.指出要“全面实现IPv6”，那么节点必须支持AH和ESP扩展标题。IETF.RFC 4294.第8节中的状态，IPv6节点必须支持啊，尤其是。但是，这实际上是错误的，因为我们知道在“现实世界”中，并非所有IPv6设备都具有执行加密数学所需的CPU资源。IPv6网络可能具有小型传感器，具有有限的CPU和电池资源，因此它们希望最小化他们发送的数据包，它们不会使用IPSec。
如果你还没有看到它，有一个非常有趣的话你管视频可悲的是，在我们的职业生涯中，我们都遇到过“我喜欢我的NAT，他们让我感到安全”的人。
弱加密和散列算法的问题
随着时间的推移，处理器变得越来越先进，攻击者通过暴力破解加密数据的能力也越来越强。年复一年，我们使用的加密算法变得越来越弱，因为密码分析师能力的进步。例如，几年前电子前沿基础（eff）和分布式网子能够使用他们的DES."深度破解"在22小时内破解56位密钥。如今，在现代计算机或分布式系统上，破解速度甚至更快。
至此，IETF发布了RFC 4722.，“使用DES的安全含义”建议不使用DES高级加密标准(AES)。
消息摘要5（MD5）和安全哈希算法1（SHA-1）是散列消息认证代码（HMAC）技术，其产生数据包内容的校验和，以确保数据包尚未被传输篡改。SHA-1通常被认为是比MD5更强的，但SHA-1需要更多计算周期来计算，因此SHA-1用于需要卓越整体安全性的环境中。
人们普遍认为，40位和56位对称密钥加密很容易通过适当的计算能力破解。甚至128位的MD4(相当于64位)也被破解了，人们一直在研究如何破解128位的MD5。由于这些弱点，IETF发布了RFC 6151“MD5和HMAC-MD5安全考虑”，建议不要使用MD5支持SHA-1和AES-CMAC（RFC 4493.）.作为比较，SHA-1的幂是2^80,RSA-1024的强度也是2^80。
在IPsec中，协议的不同部分使用了几种不同类型的加密技术。IPsec使用加密算法、数字签名、密钥交换算法和散列函数。因此，您必须考虑在您的IPsec实现中使用的这些算法中的每一个，并看看您现在如何配置这些东西是否能做得更好。最近我看到许多组织使用较弱的加密算法，我不希望您犯同样的错误。
套件B加密算法
IETF发表了一个RFC 4308这为推荐的“IPSEC加密套件”提供了行业指导。IETF还建议使用“适用于IPsec”的“套房B Cryptographic Suites”RFC 4869.。国家安全局（NSA）还建议使用“套件B作为其密码现代化计划的一部分。几年前Bill Lattin在《网络世界》上写了一篇文章有个足球雷竞技app升级到Suite B安全算法“这加强了使用更好的加密算法的需要。因此，您应该参加这些专家的建议，并有利于在IPSec配置中使用套件B算法。
美国政府加密标准
政府组织对可以使用的加密类型有特定的任务。NIST推荐逐步淘汰这些较旧的加密技术，以满足新的钥匙尺寸。如果您的组织有必要通过Internet传输敏感但未分类（SBU）数据，并且您使用IPSec然后您必须遵守NSA和NIST的指导，以使用更强大的加密算法。事实上，美国联邦组织必须遵循IPsec算法的各种标准。
联邦信息处理标准(FIPS.）标准由国家标准与技术研究所（NIST）是1996年“信息技术改革法”和2002年联邦信息安全管理法的一部分。FIPS 197.提供有关使用带键大小的AES的信息，为128和256位。FIPS 186-3提供有关数字签名标准（DSS）的信息，并建议使用椭圆曲线数字签名算法，该曲线具有具有256和384位序号的曲线。FIPS 180-4提供有关使用SHA-256和SHA-384的安全哈希标准（SHS）的信息。FIPS-140-2提供了加密模块安全要求的准则以及提供这些功能的产品的安全性。该标准正在修改为FIPS 140-3。NISTSP 800-77.是一个很好的“IPSec VPN指南”。nist.SP 800-56B.（即将要SP 800-56C.）提供有关关键协议和谈判建议建议椭圆曲线Diffie-Hellman（DH）的建议，其中曲线具有256和384位序列。国家安全局（国家安全局）还发布有关使用套件B算法的信息。
互联网关键字（IKE）
组织运行和最终配置较弱的IPsec部署的另一个问题涉及用于执行键交换的方法。这因特网密钥交换IKE (IKE)协议用于促进系统之间的密钥安全交换。Internet Key Exchange (IKE)最初是在IETF中定义的RFC 2409.。
IKE用于在IPSec端点之间创建安全关联（SAS）。有两个选项管理员可以选择：阶段1，主模式或具有快速模式的主模式或攻击模式和阶段2。第1阶段进程是建立一个安全通道，第二阶段可以使用阶段1中协商的共享密钥来协商IPSec参数。一些组织使用阶段1具有攻击模式，这是一个3包交换而不是6个数据包。交换主模式。但是，当使用攻击模式时，我们存在显着的漏洞，我们建议使用具有主模式的阶段1。
尽管IKE被广泛使用，但是可以对协议进行改进。2005年12月，IETF发表了RFC 4306“互联网密钥交换（IKEv2）协议”。ISAKMP RFC和IKE RFC都已被IETF RFC 4306淘汰。IETF还发表了RFC 4718.“IKEv2澄清和实现指南”许多产品现在开始支持IKEv2因此，如果您有能力配置IKEv2，那么您应该选择更强大的选项。
供应商更新
尽管IPsec标准已经稳定了很多年，但供应商在其IPsec协议的实现方面仍在进行改进。例如，更新的微软操作系统，如Windows Server 2008和Windows 7中的Vista Service Pack 1，现在有了支持套房B.算法。思科发布了A.64位版本他们去年的IPsec客户端软件。因此，如果您使用的旧版本的Cisco IPsec客户端，那么您将要升级到最新版本，以便您的组织可以保持最新状态。
思科和其他供应商没有支持IKEv2多年，但现在他们开始支持它。思科iOS 15.1（1）T支持IKEv2 SHA-2和套件B算法。最新的ASA固件释放8.4支持ikev2.现在SHA-2。请务必与您的供应商联系，看看最新版本中提供的选项。升级软件并配置更强大的IPSec方法。
出口控制