TISC Insight, Volume 3, Issue 7

Welcome to Volume 3, Issue 7 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.

June and The Internet Security Conference are approaching fast! We'll be covering many of the topics on TISC's agenda in the next 5 issues of Insight, including Anti-hacking, VPNs, Secure Remote Access, penetration testing. These complement but are no substitute for attending TISC, so check out the agenda and register now!

TISC is about sharing clue. So is the newsletter. We promise to provide something useful each issue. If we don't, flame me.

Enjoy, and be safe,

Dave

In today's column, my business partner Lisa Phifer and I discuss the problems security admins face when dealing with Secure Remote Access.

There's a dark side to every human endeavor, and temptation everywhere. Despite the most noble of intentions, any of us, when pushed too far, when stressed to the max, can make poor choices. A succession of these can ruin us *and* our networks.

Read on...

Secure Remote Access With IPsec

Lisa Phifer and David Piscitello

Many SOHOs experiment with PPTP because it 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. 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.

PPTP is a limited protocol designed for a specific mission. PPTP has serious security flaws, including weak password hashing, breakable keys, and unauthenticated control traffic (see http://www.counterpane.com/pptp.html). 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.

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 are ready to make a change for a safer mobile user and teleworker environment? There is a 12-step program towards recovery, and it begins here:

1. First, you must admit you were powerless over Microsoft and that your network and RAS had become unmanageable and less than secure using PPTP.

2. Admit also that you came to believe that a standard greater than Microsoft's could restore security to your remote access.

3. Decide to turn your users and your networks over to an Internet Standard solution for remote access.

4. Make a searching and fearless inventory of your remote access requirements.

5. Admit on security mail lists, to your management, and to another network admin, the exact nature of your wrongs.

6. Be entirely ready to have IPsec remove all the defects of remote access (well, some of themÖ)

7. Humbly asked for assistance in configuring IPsec for a dial VPN.

8. 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.

9. 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.

10. Continue to take network inventory and, when your network is hacked, promptly admit it.

11. Seek through education and online help to improve your conscious understanding of the IPsec standards, and FINALLY,

12. 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.

1. Define Your Security Requirements. No one enjoys doing this. Yes, it's tedious. 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 remote system itself; will you need desktop firewall in addition to VPN?

2. 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, helpdesk? Are there any prep tools you can run on desktops and laptops to identify potential issues?

3. 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 (see http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html). Document your address, routing, and policy plans.

4. 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.

5. Understand Application Requirements. What applications do your users need to access remotely? What are there 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.

6. 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.

7. 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?

8. 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.

9. 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, email attachment, and download from a web page. How will you keep mobile and teleworker users informed about (and synchronized wit) software updates?

10. 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.

11. Create a Helpdesk. No matter how automated, 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.

12. 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 facts 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.