Republished with permission from WatchGuard Technologies, Inc.

12 Steps to Secure Remote Access  Using IPsec by Lisa Phifer and David Piscitello, Core Competence, Inc In the classes we teach at venues such as Networld+Interop, we discuss the Point-to-Point Tunneling Protocol (PPTP) because we're obliged to cover the spectrum of "secure" remote access alternatives. However, PPTP is far from what we'd consider the optimal way to secure remote access.  Many Small Offices/Home Offices experiment with PPTP because it's freely available in Windows and requires no user expertise. Using PPTP, any Windows PC can authenticate itself and tunnel encrypted data to a Windows NT/2000 RAS, Linux PoPToP, VPN access concentrator, or security gateway that speaks PPTP. But PPTP is a limited protocol designed for a specific mission, and it has serious security flaws, including weak password hashing, breakable keys, and unauthenticated control traffic. PPTP does not support forward secrecy -- once you figure out one key, you can figure them all. It also uses an easily reverse-engineered password to create keying material. If you are truly worried about preventing outsider access, or if you really care about message confidentiality and integrity, PPTP is a poor choice for secure remote access. The problem is that PPTP is such an easy way to provide Internet-based remote access, admins can be lured into using it, and then they are hooked. Yours can become a broken, vulnerable, miserable network -- because you gave in to temptation. Put Down that Protocol and Step Away There is a better way. But before you can truly secure your remote access, you have to admit your current remote access "lifestyle" hurts you, your network, your business, and your users. Think you're ready to make a change for a safer mobile user and teleworker environment? There is a 12-step program towards recovery. It begins here: First, you must admit you were powerless over Microsoft and that your network and RAS had become unmanageable and less than secure using PPTP. Admit also that you came to believe that a standard greater than Microsoft's could restore security to your remote access. Decide to turn your users and your networks over to an Internet Standard solution for remote access. Make a searching and fearless inventory of your remote access requirements. Admit on security mail lists, to your management, and to another network admin, the exact nature of your wrongs. Be entirely ready to have IPsec remove all the defects of remote access (well, some of them …) Humbly asked for assistance in configuring IPsec for a dial VPN. Made a list of all hosts and user accounts that had been compromised as a result of your RAS decisions :-) and willingly make amends to them all. Make direct amends to such e-partner networks also affected by your RAS decisions, wherever possible, except when to do so would injure them or others. Continue to take network inventory and, when your network is hacked, promptly admit it. Seek through education and online help to improve your conscious understanding of the IPsec standards, and FINALLY, Having had a spiritual awakening as the result of these steps, try to carry this message to other PPTP RAS admins, and to practice these principles in all your network deployments. You're now spiritually and mentally prepared to step up to a more secure remote access solution. Let the education continue (below), then get ongoing technical and moral support from your vendor. Implementing IPsec Remote Access: The Next 12 Steps Properly implemented and properly deployed, IPsec Remote Access can be better than PPTP. Moving to IPsec is moving in the right direction. The following 12-step program can help you deploy a more robust, more secure service. Define Your Security Requirements. No one enjoys doing this. Yes, it's tedious, but it's also essential. Do you require message integrity? Confidentiality? Are there government, regulatory or other business requirements for specific cryptographic algorithms, key lengths, key lifetimes? What about the security of the remote system itself; will you need desktop firewall in addition to VPN? It's best to find out up front. Identify Your Platforms. Enumerate operating systems you must support, now and in the future. Are IPsec clients available for all? What are the minimum system requirements for the client software? Does the client software support NICs and modems installed on your desktops and laptops? What license and support arrangements will you require from your vendor, from your helpdesk? Are there any prep tools you can run on desktops and laptops to identify potential issues? Know Your Network. Where will your remote access concentrator be located? Will changes be required to existing firewall policies to allow access to this server? Will you use statically or dynamically assigned addresses for remote access users? Do you use NAT/NAPT? Document how and where NAT is used, and what affects it may have on IPsec. Document your address, routing, and policy plans. Consider Legacy Authentication. If you offer remote access now, how do you authenticate users? Where is your user database and how can it be accessed? If you need to preserve this as you move to IPsec, you should specify the authentication method in any RFP and ask that vendors demonstrate interoperability with your authentication server vendor. Find out how your vendor extended IKE to permit legacy authentication and make sure you understand the security implications. Understand Application Requirements. What applications do your users need to access remotely? What are their performance requirements? Do they require access to network operating system services (fileshares, network printers)? Document port, protocol, and ACL requirements. Design a security policy database that provides required access instead of a wide-open "any IP" window in your network perimeter. Determine Dial Access Plan. Yes, you want to reduce cost by leveraging the public Internet for remote access. But how are your users getting to the Internet? Personal Internet accounts? A corporate dial account? If the latter, what geographic coverage do you need? If you have or intend to subscribe to a global roaming plan (e.g., iPass), ascertain that your vendor's VPN client is compatible. Assign Addresses. If the client cannot receive broadcasts, the user may not be able to browse the corporate "network neighborhood." When using a foreign address, corporate servers may not be accessible and new routes may be required to direct return traffic. To overcome these issues, you may need to dynamically assign an "inside" address to your clients. Does your vendor support this? Assign Credentials. How will you identify remote users and systems? Your choices for IKE authentication are pre-shared secret, raw public keys, or certificates. How will you create, document, and securely distribute these credentials? If you plan to also use legacy user authentication, create an integration plan with your existing authentication server to assign or apply user credentials for IPsec remote access. Distribute Software. How will you distribute and install VPN client software to remote user desktops and laptop? Depending upon the product you've selected, your choices may include transportable media, e-mail attachment, and download from a web page. How will you keep mobile and teleworker users informed about (and synchronized with) software updates? Distribute Security Policies. How will you configure VPN clients with the policies you've defined? How will you keep the policies themselves secure? Will you allow end user reconfiguration? Look for clients that support centrally generated configuration profiles and centrally-pushed policy updates. Create a Helpdesk. Problems will occur. Prepare for them by providing a knowledge base and staff to resolve problems. Provide online access to FAQs, example remote access situations, and user guides. Monitor Remote Access. You've opened a new avenue into your network. Keep an eye on the traffic passing through (and beyond) your remote access concentrators. The fact that traffic's coming from an authorized account and is encrypted isn't a guarantee that it's legitimate. Consider IDS here. Now that you've sworn off PPTP, these twelve steps should help you run a more secure remote access service for your company. Find a sponsor. Take it a day at a time. If things go badly, and you feel that temptation to return to your old habit, call your sponsor or share your frustrations on a RAS mail list. Renew your oath and stay the course.  ##  Resources  Update on weaknesses in Microsoft PPTP Version 2 Same paper, in French (L'analyse de Microsoft PPTP Version 2) About the Authors Lisa Phifer and David Piscitello have been partners at Core Competence for nearly eight years. Before partnering at Core Competence, they worked separately at Bellcore (ante Telcordia), and before that, they worked on network architectures together at Burroughs/Unisys. You can find their bios at http://www.tisc2001.com/faculty.html. Was this article helpful to you? Do you have a topic you wish we'd cover? Let us know at lsseditor@watchguard.com. Copyright© 2001, WatchGuard Technologies, Inc. All rights reserved. WatchGuard, LiveSecurity, Firebox and ServerLock are trademarks or registered trademarks of WatchGuard Technologies, Inc. in the United States and other countries.