- 浏览: 1486608 次
- 性别:
- 来自: 郑州
-
文章分类
最新评论
-
getelephantbyid:
make 无法通过.....
php-5.3,php-5.4的thttpd2.25b补丁,及编译方法 -
getelephantbyid:
patch -p1 ../php-5.4.7_thttpd-2 ...
php-5.3,php-5.4的thttpd2.25b补丁,及编译方法 -
zander:
zander 写道c 语言是静态类型语言还是动态类型语言阅读理 ...
什么是动态语言和静态语言? -
zander:
c 语言是静态类型语言还是动态类型语言
什么是动态语言和静态语言? -
lunajiayou:
很有道理,赞一个
跟着苍蝇会找到厕所,跟着蜜蜂会找到花朵
This article is part of the Identity and Access Management Security School lesson on VPNs and remote access. Visit the VPNs and remote access lesson page for more learning resources.
IPsec VPNs extend a network's security perimeter by connecting individual hosts or entire networks. A secure VPN starts with verifying the identity of those tunnel endpoints, but poor authentication choices can cause interoperability issues or network compromise. This tip explores common IPsec VPN identity and authentication options, and their security and deployment implications.
Standard IPsec VPN features
IPsec VPN tunnels can be configured statically ("nailed up") or established dynamically using messages defined by the Internet Key Exchange (IKE) standard. IKE lets two VPN gateways (or two VPN hosts, or a gateway and host) authenticate each other, negotiate security parameters, and generate keys for data encryption and integrity.
Authentication is critical to avoid establishing tunnels with unauthorized parties. In a site-to-site VPN, it lets us spot an attacker masquerading as a peer VPN gateway. In a remote access VPN, it lets us deny access to intruders who pose as legitimate users. To enable authentication, IKE peers identify themselves using standard Identity Types: an IPv4 or IPv6 address, a hostname (Fully Qualified Domain Name, FQDN ), an email address (User FQDN) or an X.500 Distinguished Name (DN). IKE peers can use different ID Types; for example, user@mycorp.com (User FQDN) can tunnel into vpn.mycorp.com (FQDN).
To defeat ID spoofing, we require proof of claim using an IKE standard Authentication Method: a Pre-Shared Key (PSK), an RSA or DSS digital signature , or an encrypted public key . To use PSKs, the same secret value must be configured into both peers before they can authenticate each other. To use digital signatures, each peer must be issued a certificate by a Certificate Authority (CA) that the other trusts. To use encrypted public keys, each peer must generate its own RSA key pair, and then configure its public key into every IKE peer with whom it plans to communicate. IKE peers must use the same Authentication Method; for example, user@mycorp.com and vpn.mycorp.com might both use the shared PSK "opensesame." Or they might both use RSA signatures, each generated with the sender's own certificate.
Because these messages cross untrusted networks where eavesdropping may occur, IKE uses cryptography to protect credentials. For example, IKE PSKs are never transmitted; peers just exchange signed hashes that prove they known the same PSK. But the same cannot be said for IKE IDs. IKE operates in two modes: a 5-message Main Mode that prevents ID sniffing, or a 3-message Aggressive Mode that sends the initiator's ID "in the clear." Both Modes support any IKE standard ID Type and Authentication Method, with one exception: if Main Mode is used with PSK, the ID must be an IP address. This makes Main Mode/PSK impractical for remote access VPNs, because mobile users rarely connect from static IP addresses.
Facilitating remote access
The mutual authentication methods supported by IKE are a good fit for site-to-site VPNs, but IKE does not support asymmetric user authentication methods like passwords, challenge/response exchanges and two-factor tokens, which are commonly used for remote access. To overcome this, many vendors implement non-standard enhancements like Extended Authentication (XAUTH ).
XAUTH is an Internet Draft that supports asymmetric authentication by inserting a new message exchange after Main/Aggressive Mode (IKE Phase 1) and before IPsec parameter negotiation (IKE Phase 2). VPN gateways that use XAUTH can prompt remote users for a secondary login. If user login succeeds, IPsec setup continues; otherwise, setup is abandoned. XAUTH -- and an improvement called Hybrid -- are widely implemented by VPN concentrators and clients to enable user authentication with "legacy" credentials like Windows logins or SecurID tokens.
Although many vendors implement the same XAUTH draft, this extension was not approved as an Internet standard because it is vulnerable to man-in-the-middle attacks . In particular, using weak credentials to complete IKE Phase 1 makes it too easy for an attacker to masquerade as a VPN gateway, prompting other users for their credentials. To reduce this risk, the XAUTH draft strongly discourages using IKE with the same (group) PSK for all users. Unfortunately, many remote access VPNs are configured in precisely this manner! To learn more, consult the XAUTH draft and these references:
- http://www.cisco.com/warp/public/707/cisco-sn-20030422-ike.html
- http://www.ernw.de/download/pskattack.pdf
Another legacy user authentication option is to run the Layer 2 Tunneling Protocol (L2TP ) over IPsec. This approach was originally used by the VPN client built into Windows 2000/XP, and is now also supported by many other VPN vendors. L2TP authentication occurs after IPsec is completely established.
Selecting an authentication mode for your IPsec VPN
Given this collection of ID Types and standard/extended Authentication Methods, how can you make the best choices for your own VPN? There are many factors to consider, including the number and type of endpoints involved, existing credentials and authentication databases (if any), interoperability needs, corporate security policies, and risk tolerance.
PSKs are the easiest VPN credentials to generate -- and the easiest to compromise. PSKs, like passwords, are vulnerable to social engineering, and valid ID and PSK values are easy to share with those who should not have them. PSKs that are too short or simple are relatively easy to guess, and tools like ikecrack can automate this attack. Clearly, authenticating every user with the same PSK is a high-risk scenario. Authenticating a single gateway pair with a very long, random PSK known only to one admin presents less risk. If you must use PSKs, avoid disclosing associated IDs with Aggressive Mode.
Raw public keys are not hard to generate and configure into a small set of endpoints, like a site-to-site VPN of modest size. The security afforded by encrypted public keys is far stronger than PSKs, but this method doesn't scale well and can pose interoperability problems in multi-vendor VPNs. In fact, RFC 4109 downgraded this method from "SHOULD" to "MAY" implement due to its lack of deployment.
Digital signatures use certificates to bind a subject's identity to its public key, vouched for by a trusted CA. This strengthens security without requiring every endpoint to be configured with every other endpoint's public key. Instead, endpoints need only be configured with one CA's certificate. RSA signatures are widely supported by VPN products; DSS is less common. Digital signatures scale well in companies that already have a Public Key Infrastructure. However, companies without an established platform for issuing certificates -- especially to remote users -- may consider this method too costly. Some VPN products have a built-in CA (or offer an online CA service) to make certificate management easier.
Even companies that bite the bullet and issue certificates to VPN gateways can be reluctant to part with legacy user authentication. As we have explained, there are cases where XAUTH poses high risk and cannot be recommended. However, there are ways to reduce XAUTH's man-in-the-middle risk while leveraging the added value of two-factor user authentication. For example, use IKE Main Mode with Certificates, issuing unique certificates to each VPN gateway, and a group certificate to your users. Follow this with SecurID authentication to verify individual user identity. This combo deters VPN gateway spoofing and PSK cracking, without requiring per-user certificate management. L2TP-over-IPsec is another option, if supported by your VPN Gateway and all clients.
ID Type depends on endpoint type, IKE Mode and Authentication Mode. VPN gateways often use IP address or (for more flexibility) FQDN. VPN hosts often use User FQDN, except for Main Mode/PSK, which requires the initiator's IP address. Depending on the product, remote access VPNs with a group PSK may treat a range of IP addresses as one ID, or use a group ID (FQDN) in Aggressive Mode. X.500 DNs are typically used only with Digital Certificate authentication. Alternatively, an IP address, hostname or email address can be included in a certificate's altSubjectName attribute.
On the horizon: IKEv2
After completing the original IKE standard, the IETF began work on a major revision that was published as RFC 4306 in December 2005. This new standard, IKEv2 , is not interoperable with IKEv1. IKEv2 is a new, streamlined key management protocol for use with IPsec. IKEv2 supports similar-but-different peer authentication options, with built-in support for asymmetric user authentication through the Extensible Authentication Protocol (EAP). ICSA Labs is now accepting applications for VPN products that wish to be tested for IKEv2 certification. Any company kicking off a new IPsec VPN from scratch should take a close look at IKEv2 vendor support and deployment timeframe. Those with deployed VPNs should keep an eye on IKEv2 progress and consider the business benefits of future migration. In any case, consider your authentication options carefully to make best use of today's mature, widely-deployed IKEv1 products.
About the author
Lisa
Phifer owns Core Competence Inc., a consulting firm specializing in
network security and management technology. Lisa has been involved in
the design, implementation and evaluation of data communications,
internetworking, security and network management products for over 20
years. At Core Competence, she has advised large and small companies
regarding security needs, product assessment and the use of emerging
technologies and best practices. Before joining Core Competence, Lisa
was a Member of Technical Staff at Bell Communications Research where
she won a president's award for her work on ATM Network Management.
发表评论
-
使用strongswan建立基于ikev2 eap-mschapv2的ipsec服务器
2017-04-17 23:14 3265sudo apt-get install strongsw ... -
使用strongswan/xl2tpd建立ipsec/l2tp服务器
2017-04-17 22:32 6220sudo apt-get install strongsw ... -
SecureFX中文件名乱码的解决
2014-08-28 03:23 3386原始贴子:https://forums.vandyke.c ... -
为Linux编译atheros ar1111(设备ID:168c:0037,AW-NB100H – AR5B225 Atheros half size)网卡驱动
2012-07-15 22:57 4684买了个zotac h61itx-a-e wifi主板,从zot ... -
PHY管理接口(MDIO)
2012-01-17 17:01 4250对吉比特以太网而言,串行通信总线称为管理数据输入输出 (MDI ... -
netfiletr和iptables的状态和连接跟踪机制
2012-01-11 15:38 3365Como se lleva a cabo el rastreo ... -
编译安装iw
2011-11-09 13:31 2401ubuntu安装build-essentials libnl- ... -
从ip addr add和ifconfig的区别看linux网卡ip地址的结构
2011-09-24 13:06 1723转至:http://blog.csdn.net/dog25 ... -
DLNA中的UPnP技术浅析
2011-09-22 18:39 5141说到DLNA,UPn ... -
Linux 用户态与内核态的交互——netlink 篇
2011-09-19 01:39 3559转至:http://bbs.chinaunix.net/thr ... -
netlink与rtnetlink(二)
2011-09-19 01:36 16079转至:http://blogold.chinaunix.net ... -
netlink和rtnetlink(一)
2011-09-19 01:35 5284转到:http://blogold.chinaunix.net ... -
Linux——Netlink
2011-09-19 01:24 9731转载:http://blog.csdn.net/firo_ba ... -
linux notification chains
2011-08-13 00:26 1083linux内核由各个不同的子系统构成,比如网络子系统、存储 ... -
内核中的notification chain浅析
2011-08-13 00:25 1397内核中的很多子系统都是联系很紧密的,因此有可能某个子系统的某些 ... -
Linux Notification chains
2011-08-13 00:24 2899Notifier是Linux 中提供一种在内核子系统 中共 ... -
printk 使用方法
2011-08-12 22:28 9929内核通过 printk() 输出的信息具有日志级别,日志级 ... -
WEXT/mac80211/nl80211/cfg80211
2011-07-29 02:32 11317Wireless-Extensions--旧的无 ... -
fedora上wpa_supplicant上网配置
2011-07-29 01:28 35761,vi /etc/sysconfig/wpa_supplic ... -
vi替换命令用法详解
2011-07-19 01:06 2224vi替换命令用法详解 : ranges /pat1/ ...
相关推荐
4. IP协议数据包格式:包含了版本、首部长度、服务类型(TOS)、总长度、标识、标志、片转移、生存时间(TTL)、协议、首部校验和、源IP地址、目的IP地址,以及可变的选项字段和填充数据。 5. TCP/IP协议簇的主要...
IPv6扩展头是IPv6协议族中的一个重要组成部分,它的设计目的是为了提高网络处理能力和灵活性,同时简化IPv4中复杂选项的处理方式。...了解和掌握这些扩展头的使用对于理解和优化IPv6网络通信至关重要。
IPSec(互联网协议安全)、SSL/TLS(安全套接层/传输层安全)是用于建立加密通信和身份验证的网络协议,用于保障数据传输的安全。 SIP(会话初始化协议)是用于建立、修改和终止多媒体会话的信令协议,通常用于VoIP...
- **内置安全功能**:IPv6支持IPsec(Internet Protocol Security),可实现数据包加密和身份验证,提高网络安全性。 - **更好的QoS(服务质量)支持**:IPv6设计了更强大的服务质量控制机制,有助于优先处理关键...
在网络层,可以通过IPsec(IP Security)协议提供安全服务,包括数据加密、身份认证和完整性保护。 总结起来,网络层协议是TCP/IP通信的基础,它处理网络间的路由和数据传输,确保数据能够准确地从源主机传递到...