Steps to Secure
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
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:
you must admit you were powerless over Microsoft and that your network and
RAS had become unmanageable and less than secure using PPTP.
also that you came to believe that a standard greater than Microsoft's could
restore security to your remote access.
to turn your users and your networks over to an Internet Standard solution
for remote access.
a searching and fearless inventory of your remote access requirements.
on security mail lists, to your management, and to another network admin,
the exact nature of your wrongs.
entirely ready to have IPsec remove all the defects of remote access (well, some
of them …)
asked for assistance in configuring IPsec for a dial VPN.
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.
direct amends to such e-partner networks also affected by your RAS
decisions, wherever possible, except when to do so would injure them or
to take network inventory and, when your network is hacked, promptly admit
through education and online help to improve your conscious understanding of
the IPsec standards, and FINALLY,
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
- 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.
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
- 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.
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
- 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. ##
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 firstname.lastname@example.org.
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.