Bear in mind that not all suggestions may be applicable to your environment. You may have a specific need that precludes a certain tip, or, since VPN capabilities and management is different on the various Cisco platforms, your particular VPN solution may not support every tip. Also note that these tips are not in any particular order.
Avoid split tunneling, unless absolutely necessary
Split tunneling, a method by which you can allow traffic destined for a public network (such as the Internet), effectively bypassing the VPN, can pose significant security risks for your organization's network. When you use a split tunnel configuration, all non-VPN traffic is communicated directly with a public network. When you disable split tunneling, all client network traffic is redirected through the VPN, including Internet traffic (if such traffic is allowed at all while a VPN connection is established).
While a split tunnel configuration can avoid network traffic bottlenecks at the VPN server side, such a configuration can also open up the VPN to attack since it becomes accessible to the public Internet. However, there may be some cases in which split tunneling is appropriate. For example, if you implement a site-to-site hardware-based VPN with enterprise-level firewalls at both ends, split tunneling may not negatively impact network security enough to offset the additional bandwidth that would be otherwise required to funnel all traffic through to the main site.
Configure a Cisco VPN Concentrator to require the use of a firewall on every client system
An unpatched or unprotected client computer can have serious repercussions for your entire network, particularly when you allow unfiltered Internet traffic to a client machine that is also connected to your VPN. The Cisco VPN client includes a stateful firewall, called the Cisco Integrated Client, that incorporates technology used in ZoneLabs firewall software.
Between this client software and a Centralized Protection Policy—a policy defining what is allowed and disallowed on the VPN pushed to the client upon initiation of a connection to the VPN—configured on your Cisco VPN Concentrator, you can restrict as much as you like what types of activities a clients undertakes while connected to your network. You can also configure a policy that requires that a third party personal firewall is up and running on a connected client. This is accomplished with a capability known as "Are You There", a feature that allows the VPN client to poll the third party firewall product to make sure it is running.
Cisco supports the following third party firewalls: BlackIce Defender, Cisco Security Agent, Sygate Personal Firewall (and the Pro version), Sygate Security Agent, ZoneAlarm (and the Pro version). Other firewalls may also be supported. Check with your vendor to find out.
Use the right kind of VPN and understand the differences.
There are two basic VPN scenarios: (1) You are attempting to support a workforce of hundreds of mobile users all connecting from different locations; (2) You are connecting all of the users in a remote site to a parent site.
The VPN covering the first scenario is commonly called a remote-access VPN while the VPN for the second scenario is known as a site-to-site VPN. Each scenario requires a different set of rules and generally require different hardware—or at least work better when the appropriate hardware is used. For example, for a remote-access VPN, the typical connection point is a Cisco VPN Concentrator, and clients generally need to be more thoroughly scanned and security policies more strongly enforced since such clients often connect from random, untrusted networks.
For a remote-site VPN, on the other hand, you might accomplish the site-to-site connectivity with a PIX firewall or even just with a router. In these cases, while you still want clients to be safe and secure, your worries about what is on each client are somewhat mitigated since the clients remain in a controlled environment under the purview of your corporate desktop policy.
Understand the client side of the VPN as much as the server side, particularly with remote user VPNs using Network Address Translation (NAT)
Many companies have made great strides in supporting NAT at both the server and the client side. This is particularly important as more and more homes and businesses acquire faster connections to the Internet and start connecting multiple devices behind small routers that use NAT to allow this multi-device connectivity. For a long time, NAT basically dashed people's plans for a secure IPSec-based VPN connection because NAT, by design, makes modifications to the data inside each packet, meaning that IPSec used to think that the packet had been tampered with. Not any longer.
Now, with just a few steps, you can configure your Cisco-based VPN to support NAT-Transparency (also called NAT-Traversal). Follow this link for complete instructions on enabling NAT-Transparent mode on a Cisco Series 3000 VPN Concentrator. On the client side, you may also have to take steps (or tell your users how to take steps) to allow VPN connections to pass through their home routers. On newer Linksys routers, for example, there is an option called VPN Passthrough that can be changed to allow or disallow this type of activity.
When possible, use centralized authentication.
Many of Cisco's various VPN solutions allow you to create users right on the device using built-in commands (i.e. "username bobsmith password bobspw" on a PIX) and by going through the process that enables local authentication for your device.
However, especially for larger VPN rollouts, this can add some complexity and security issues to your environment. First, you now have multiple locations in which you need to manage users. Second, unless you're careful, you could forget to disable the account for a user that has left the organization.
For this reason, try to use a centralized authentication scheme, such as RADIUS or TACACS on your Cisco VPN hardware. The Cisco Series 3000 VPN Concentrator and PIX firewall software supports both authentication methods. TACACS is Cisco's proprietary solution and offers some advantages over RADIUS, but RADIUS is widely supported and able to be quickly established in most organizations. For example, in Windows Active Directory environments, you can add RADIUS authentication capabilities to your Active Directory environment using software that comes bundled with Windows.
For a complete discussion of the differences between TACACS and RADIUS, visit this link. The information there will help you make a more informed decision regarding your authentication method. If you do opt for RADIUS, make sure your RADIUS server is on a protected network (such as your inside network) to protect it from being compromised.
Choose the right VPN option for your security needs.
There are four common VPN options:
- PPTP (Point-to-point tunneling protocol)
- L2TP (Layer 2 tunneling protocol)
- SSL (Secure Sockets Layer)
SSL-based VPNs are fairly new are have some issues to be worked out, so I don't yet recommend their use, unless your VPN client users use 100% web-based applications. If they need to use a client/server product, an SSL VPN may require custom programming to be able to work the way you want.
On the security scale, PPTP VPNs are the least secure, but, when set up appropriately, can actually be pretty good for many organizations that don't need FBI style protection. PPTP VPNs also happen to be easy to use from the client perspective since most modern operating systems include a PPTP client. On the server side of the equation, since PPTP does not require a complete certificate architecture (PKI) to get up and running, these VPN types are easier to get working. For the most secure PPTP, disable any encryption method below 128-bit and use a reasonable authentication method, such as EAP or MS-CHAPv2 (which supports rotating keys). Further, make sure your users are always using strong passwords.
The current favorite, the IPSec VPN also requires a client on the end user machine, but, with IPSec, what the client does can be somewhat controlled. IPSec at its most secure requires the development of a pubic key infrastructure for authentication, but, if you want to avoid this complexity, can also be configured to use the somewhat less-secure "shared key" authentication method.
Use the maximum encryption level possible.
By "possible", I mean use the maximum encryption level that works for your organization and doesn't provide undue stress on your hardware. Sure, 1,024-bit encryption is great, but requires a decent amount of processing power at both the client and the server to support, resulting in fewer overall users able to use your VPN hardware. In general, I recommend using 128-bit encryption for PPTP-based VPNs and 168-bit 3DES encryption for IPSec-based VPNs.
If, for some terrible reason, you need to continue to support older operating systems on the VPN client using PPTP and can't use the Cisco VPN client, be aware that Microsoft has upgraded the 40-bit encryption max on these clients to 128-bit as well. You can download version 1.4 of the Dial-Up Networking software from here
For maximum security, separate functions.
There's a lot of debate on whether it's better to maintain separate devices, or combine functionality (i.e. using a PIX or a router for VPN or using separate devices for all functions). The devices would include your outside router, a firewall, and a VPN concentrator. Of course, this is most appropriate for medium-to-large organizations. If one device is compromised, you don't lose your entire security infrastructure.
Obviously, with tight budgets, this is not always practical but if you do have the resources to separate functions, the best traffic path for maximum security is router à firewall à VPN server (VPN concentrator). As I mentioned before, place any infrastructure support services, such as RADIUS servers on the inside network as well.
Know when to use a VPN—and when not to.
This might seem like a strange tip in an article about securing VPNs, but I am a firm believer in user the right tool for the right job. While most organizations can probably benefit from some kind of VPN, be careful about taking on the "when you have a hammer, everything looks like a nail" approach with your VPN.
By way of example: Do you need to, for example, provide the full Outlook client to your remote users? Is that the only reason they're connecting to the VPN? Or, are you providing a VPN just to allow certain users to do updates to your web site? In these kinds of cases, by providing users with VPN access, you're basically extending your network perimeter to include their locations, just for these limited tasks. And, when you extend your network perimeter, you still need to protect it. Find other ways to handle these limited tasks.
Instead of providing Exchange/Outlook users with VPN access, consider allowing RPC-over-HTTP instead (of course, only works if you're using Outlook 2003 and Exchange 2003, but the point here is that there is another way to accomplish a goal). In the web site update example, provide a secure area on the web site to which these users can provide and provide credentials to handle web updates instead.
Keep up with updates for both the VPN server and client software
You see this tip in a lot of the things I write. Why? Because the number one solution cited in many newsgroups and support forums is "try the latest version of the software—the problem is fixed in the update". In this case, make sure you keep your VPN Concentrator, PIX, or router at the most recent code revisions. Subscribe to any groups or listservs that publish vulnerabilities related to your hardware and apply the fixes as soon as they are available. This is also true for the client side of the equation. Keeping the client software current will go a long way toward helping you keep your VPN from becoming a major security issue for your organization.