Preventing IPsec VPN failures: recommendations (part 2)

In my last blog post, I recommended a number of ways to avoid the first five of my top ten reasons why IPsec VPNs fail. As promised, in this blog post, I'll finish this particular topic by explaining how to avoid the final five in my top ten, as well as describing one or two other things to look out for.

So, straight to it:

6. Inappropriate use of Extended Authentication (XAuth, which may be vulnerable when used with weak pre-shared keys and aggressive mode IKE/ISAKMP).

IKE is used in an IPsec VPN to dynamically exchange keying material, negotiate cryptographic parameters, and to authenticate IPsec devices (peers) to each other.

IPsec device authentication alone is sufficient in a site-to-site VPN, but in a remote access VPN, it is also necessary to authenticate the (human) VPN user.

This VPN user authentication ensures that if, for example, a user's laptop is stolen, the thief will not be able to connect to the VPN gateway because even if IPsec device authentication succeeds, user authentication will fail.

There are three main ways that an IPsec VPN gateway can authenticate VPN users:

* Extended Authentication with IKE (Xauth).

* Hybrid Authentication Mode for IKE ("Hybrid Authentication").

* IKE Challenge/Response for Authenticated Cryptographic Keys (CRACK).

Xauth can be vulnerable if a weak preshared key is used to authenticate IPsec devices in IKE phase 1, especially if aggressive mode is used.

When using Hybrid Authentication, IKE phase 1 authenticates the VPN gateway using RSA/DSA digital signature authentication. Once IKE phase 1 is complete, a Transaction exchange begins, and this exchange consists of ISAKMP Xauth which authenticates the VPN client.

Hybrid Authentication addresses potential weaknesses of regular Xauth, as well as problems with group authentication using preshared keys (described last time).

IKE CRACK modifies IKE phase 1 negotiation to include user authentication (which is not included in regular IKE phase 1). When using CRACK, the VPN client authenticates using a secret key type user authentication method, and the VPN gateway authenticates uses public-key authentication.

So, the upshot is that Xauth can be vulnerable. This is yet another reason for not using pre-shared keys and aggressive mode.

If you have the option, such as on the Cisco VPN 3000 concentrators and Cisco ASA 5500s, you might like to use Hybrid Authentication.

7. Vulnerability of NTP and/or CRLs/OCSP used by PKI to DoS attack (relevant when using digital signature authentication).

As you already know, digital signature authentication is much better than pre-shared key authentication. But the PKI that you need to deploy in support of digital signature authentication can itself be vulnerable to attack if you don't protect it properly.

Elements used with a PKI include NTP servers that provide an accurate clock, and Certificate Revocation List (CRL) Distribution Points (CDP) or Online Certificate Status Protocol (OCSP) responders that ensure that certificates used for authentication are valid and have not been suspended or revoked.

So, when you deploy digital signature authentication and a PKI, make sure that elements such as NTP servers, CDPs, and OCSP responders are properly protected against DoS attacks that could otherwise affect your IPsec VPN.

8. Relatively weakly secured CA private key storage.

The strong security that is offered by digital signature authentication can be completely undermined if an attacker manages to obtain the private key of a Certificate Authority (CA), particularly the root CA.

This is because CAs issue the certificates that are the basis for digital signature authentication. Possession of the private key of a CA will allow an attacker to issue certificates to him/herself and therefore authenticate with the VPN gateway.

So, make sure that the private keys of the CAs are strongly protected, perhaps using a Hardware Security Module (HSM).

9. Storage of IPsec VPN gateway configuration files containing paintext pre-shared keys.

If you have decided to stick with pre-shared key authentication, don't overlook the possibility that an attacker might be able to gain access to the configuration files of your VPN gateways. If he can obtain configuration files, and the pre-shared keys are shown in plaintext (unencrypted) then the game's up - your VPN is now wide-open.

You can avoid this possibility on Cisco routers by encrypting the pre-shared keys.

10. Use of encryption without authentication.

The final method of undermining an IPsec VPN in my top ten is using encryption without authentication.

In certain circumstances, using encryption without authentication can make your VPN vulnerable to cut-and-paste attacks. Cut-and-paste attacks can allow an attacker to recover unencrypted messages.

So, make sure that you always use authentication with encryption in your VPN.

In summary:

1. When using pre-shared keys, particularly with aggressive mode, avoid using regular XAuth, and use Hybrid Authentication or CRACK instead.

2. When using digital signature authentication, don't forget to protect elements of your PKI from attack.

3. When using digital signature authentication, make sure that your CA's private keys are strongly protected.

4. Make sure that attackers cannot gain access to VPN gateway configuration files containing unencrypted pre-shared keys.

5. Never use encryption without authentication.

Phew! That's it - if you implement these recommendations, your VPN should be secure, shouldn't it? Er, sorry, no - that's just my top ten vulnerabilities.

Other things to do when confirming that your IPsec VPN is properly designed and configured:

1. Make sure that your IPsec VPN gateway is not configured to use IKE policies and IPsec transforms that specify strong cryptographic algorithms first, but allow fallback to weaker algorithms. This means that your IPsec VPN gateway should specify stronger algorithms such as AES and HMAC-SHA, and not allow fallback to connections using weak algorithms such as 56-bit DES.

2. Don't allow IPsec connections using authentication without encryption, unless you are absolutely sure you don't need encryption.

3. Ensure that any pre-shared keys are properly stored by your IPsec VPN client software. Some IPsec VPN software may, for example, store pre-shared keys in the Windows registry completely unhidden and unencrypted, or perhaps just ‘hidden' but not actually encrypted. Also, be careful that your IPsec VPN client software doesn't decrypt pre-shared keys into memory when it is started.

4. Don't use manual IPsec. Manual IPsec is rare, but if it is used then there is no possibility of re-keying, and your IPsec VPN is therefore more vulnerable to attack.

5. Use Perfect Forward Secrecy (PFS). If you use PFS then your IPsec keys may remain secure even if an attacker manages to undermine IKE.

6. Once you are sure that your IPsec VPN tunnel is secure, have a look at how your network is protected from the possibility of remote IPsec peers being compromised. So, for example, ensure that your network is protected even if a remote user's laptop is compromised, or a hacker gains access to a remote site. Network Access Control (NAC) and firewalls can help with this, as well as disallowing split-tunnelling.

7. When deploying a firewall to inspect traffic received over an IPsec VPN, ensure that the firewall is properly positioned to inspect the traffic after all IPsec protection has been removed, and it is not just inspecting encrypted traffic.

Well, that's it. If any previous idea that IPsec is always secure no matter how it is configured has been shattered, and you now think that IPsec is a bit of a kludge, you're are not alone.

Just remember that IPsec VPNs can be very secure - they just need to be properly designed and configured.


Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2007 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)