Network World
Thursday, January 8, 2009
DNSstuff.com
Get information about your IP
IP Information
50+ On-demand DNS and network tools

Mark Lewis: Best practices from a roving CCIE

Cisco Subnet

Navigation

Preventing IPsec VPN failures: recommendations (part 1)

Well, based on a number of emails I have received, some people were quite surprised to learn in my first blog post that poorly designed and configured IPsec VPNs are vulnerable not only to the NSA and GCHQ, but also to pretty much anyone with minimal technical skills and the ability to read instructions.

So I thought I'd follow up over the next couple of blogs posts with a few recommendations to help you avoid the pitfalls that I described in my previous post.

1. Use of weak pre-shared keys:

Number one in my top ten of reasons that IPsec VPNs fail was the use of weak pre-shared keys. But what exactly constitutes a weak pre-shared key? It's really anything that can be cracked within a relatively short period of time using brute-force techniques.

If your IPsec VPN is poorly configured, a short pre-shared key consisting, for example, of just letters may be crackable in minutes or at most hours (depending on its length and the computing power dedicated to cracking it).

If you use pre-shared keys, make them at least 10 characters long, and make them a random combination of upper and lower case letters, numbers, and punctuation - that way they will be much more difficult to crack. So, for example, the pre-shared key '1m&Hf0eQ!4s7M/,' would be more difficult to crack than 'cisco', 'password', or 'cIsCo12345'.

2. Inappropriate use of IKE/ISAKMP aggressive mode (with weak pre-shared keys):

During Internet Key Exchange v1 (IKEv1) phase 1, among other things, IPsec peers negotiate IKE/Internet Security Association and Key Management Protocol (ISAKMP) cryptographic algorithms/parameters and authenticate each other.

There are two ways that phase 1 negotiation can be performed - using main mode or using aggressive mode.

Aggressive mode is very slightly quicker to negotiate than main mode, but is less secure because certain information is unencrypted. The use of aggressive mode makes it is easier to crack weak pre-shared keys.

So, it is a very good idea to avoid the use of aggressive mode altogether and use main mode instead.

There's one other thing to be aware of with regard to aggressive mode - some IPsec VPN gateways (such as Cisco routers) use main mode by default, but will fall back to using aggressive mode if a remote IPsec peer initiates aggressive mode negotiation. So, you may have to explicitly disable the use of aggressive mode on some platforms (use 'crypto isakmp aggressive-mode disable' on Cisco routers).

3. Inappropriate method of authentication (pre-shared keys when digital signature [certificate] based authentication might be more appropriate):

By now, you know that pre-shared key authentication may be vulnerable to cracking. So, what are the alternatives? Well, there's authentication using encrypted nonces and authentication using digital signatures (certificates).

Without going into details, configuring encrypted nonce authentication can be very time consuming and is not very scalable. So that leaves digital signature authentication. This involves the use of digital certificates, and that in turn requires the deployment of a Public Key Infrastructure (PKI) including one or more certificate authorities (CAs).

The deployment of the PKI required by digital certificate authentication is more involved than the simple configuration of pre-shared keys. But, if you want good security, then digital signature authentication is the way to go because it is just not anywhere near as vulnerable to cracking as pre-shared key authentication.

4. Inappropriate use of wildcard or group pre-shared keys (where use of alternatives might be more appropriate/possible):

Number 4 on my top ten of ways to undermine IPsec VPN security is the unnecessarily use of wildcard or group pre-shared keys.

When using wildcard or group pre-shared keys, you can have one pre-shared key for any and all remote peers that connect to a IPsec VPN gateway. This means, in effect, that the VPN gateway doesn't care who or what is connecting, as long as it knows (or has cracked!) the pre-shared key.

So, wildcard or group pre-shared keys just make it easier for a hacker to crack your IPsec VPN. Try to avoid using them, if at all possible.

5. Use of identical pre-shared key with multiple peers (similar to #4):

Number 5 is very similar to number 4.

While wildcard or group pre-shared keys can be used to associate a single pre-shared key with any remote IPsec peer, number 5 refers to the use of the same pre-shared key with more than one (though perhaps not all) remote peers. Again, this just makes life easier for the hacker.

So, if you use pre-shared key authentication, have a unique pre-shared key per remote peer/user, if at all possible.

Of course, if there are a large number of remote peers/users that connect to your VPN gateway, the configuration and management of a unique pre-shared key per remote peer/user may be very time-consuming. This is another reason to use digital signature authentication instead.

In summary:

1. Don't use pre-shared key authentication - use digital signature (certificate) authentication.

2. If you must use pre-shared keys, make them strong.

3. If you must use pre-shared key authentication, don't use wildcard or group pre-shared keys.

4. If you must use pre-shared key authentication, use a unique pre-shared key per remote peer/user.

5. Use main mode rather than aggressive mode IKEv1 phase 1 negotiation.

Next time I'll finish up on this topic by taking a look at preventing the IPsec VPN failures described in numbers 6 to 10 in my top ten.

Mark

PGPNet

Useful answer?
0

The instructions about testing the VPN (see link "ability to read instructions")would be awesome if it only told where to get the application PGPNet. From looking aroung on the net, looks like it was part of older versions of PGP. Does it still exist? Perhaps I do not have the "ability to read instructions" properly.

You don't need that specific client...

Useful answer?
0

Hi Unabilitized,

Actually, you don't need the PGPNet VPN client at all - you just need one with plenty of configuration options (ie. the ability to control all IKE/ISAKMP phase 1 parameters/etc.).

There are a number that will do the job, but here is one that has a trial download:

http://www.thegreenbow.com/vpn.html

Now, I haven't tested that VPN client in a while, but a quick flick through the docs shows that it will allow you to (importantly) specify IKE aggressive mode, and it seems pretty much every other phase 1 parameter & option.

So, perhaps try that client and if it isn't up to the job, perhaps a little more digging on the web....

Mark

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

About Mark Lewis

Mark Lewis (CCIE#6280) is an independent consultant who helps service provider and large enterprise clients design and implement leading-edge technologies. Over the last couple of years, Mark has designed and implemented a variety of large-scale technology solutions including VPN, MPLS, QoS, data center, and IP telephony. Mark is the author of three books for Cisco Press: Comparing, Designing, and Deploying VPNs, Troubleshooting Virtual Private Networks, and CCIE Voice Exam Quick Reference Sheets.

Contact Mark.

RSS feed XML feed

Mark Lewis archive.

Cisco Subnet

RSS feed Cisco news RSS feed

The opinions expressed in this Weblog are those of the writer and may not represent the opinions of Network World.

Advertisement: