VPNs the Easy Way
Whoever said virtual private networks are difficult to set up and the potential weak link in your security hasn't looked closely at Microsoft's VPN solution.
- By Bill Heldman
In these times of economic downturns and companies searching for ways
to reduce costs, doubtless some organizations will look harder at providing
telecommuting options to employees. What we mean by telecommuting is that
an employee can obtain access to the corporate private network, including
all of the accoutrements therein such as e-mail, intranet/portal and applications
that he or she would be able to access as a normally connected Ethernet
or wireless client.
A strong telecommuting environment makes sense for corporations for many
- Employees who frequently travel are able to access e-mail, work files,
the intranet and applications in real time.
- Employees who really don't need to have a cubicle at the downtown
office can work from home via collaboration tools and can communicate
almost as effectively as any other employee. (Though there's nothing
like the occasional face-to-face meeting to get teams headed in the
right direction. But then there's nothing saying the company can't require
a mandatory biweekly team meeting in which all the members are physically
required to be present.)
- Vendors, contractors or other businesspersons who frequently do business
with the company can be granted access (the limitation of which is determined
by policy stakeholders) to the internal network to facilitate more seamless
- The intranet and Internet sites of a company can be linked together
so that intranet information can be attained from the corporate DMZ.
This way, even if someone doesn't necessarily need to gain access to
the entire private network, as long as he has a valid login he can access
(at least portions of) the company's intranet. This would be handy for
example for an employee using a wireless device and periodically needing
to upload batch information to a database, but not needing to be logged
in all the time such as a telecommuting employee might need to be.
But the implications of a telecommuting environment can be scary. You
have all those intrusion and virus threats to think about, not to mention
the possibility of someone who isn't an employee hacking into the
private network using a real employee's login and password. These are
real and serious concerns that have served in the past to drive some technology
managers to say "We will never allow remote access into our private
network. It's just too risky!"
I believe that these arguments are invalidated due to a fundamental error
in logic. Yes, your network is at risk when you begin offering a method
whereby non-internally-connected users can access the private network.
However, I see the risks being mitigated and nullified by good quality
administration at all levels. If you're going to offer telecommuting services
to your employees (you should) then you need to also be concerned with
the fundamental administrative considerations, some of which are described
- Your DMZ, Web and perimeter (intrusion detection, firewall, Web-filtering)
servers need to be exhaustively monitored and proactively protected
with the latest and greatest in security patches and lockdowns. Most
firewalls today perform a function called "stately inspection." What
this means is that the software examines every packet header that's
directed at a certain port to validate that it is a legitimate packet
for that port. The idea is that you temporarily open the "port door,"
examine the header, say yes or no, then close the door again. This activity
prevents guys with port sniffers from figuring out if you've got a bunch
of ports standing open at the perimeter, just waiting—inviting—them
to come on in and hunker down for awhile.
- Strong password policies need to be in place. If, for example, you
have a baseball nut for an employee and this employee isn't likely
to be one give to strong security for her personal working environment,
she's likely to have a password of baseball1 or dugout
or…you get the idea. Intrusion specialists who know people that work
within a company really don't have a hard time figuring this kind of
in Plain Sight
|I once worked with a server administrator
who had to get onto a server right away in order to solve
some difficulties associated with a financial application.
Unfortunately, this server was one that the administrator
did not have to often directly administer and the folks
that did had forgotten the administrative password!
This administrator was able to look around the area in
which this server [an AS/400 box] was sitting, and judging
by the pictures on the wall, successfully got on within
45 seconds! It amazed me and taught me a lesson about
people's lives and the passwords they keep.
So, it's to your benefit to implement and enforce strong passwords. For
example, you shouldn't allow the idea of what I call "faux-strong
passwords" such as password1, password2, password3.
While these passwords are mildly strong, i.e. password breaking software
might take 15 seconds instead of three to crack the password, it's really
not buying you anything in the long run. What you want is a combination
of capital and lowercase letters, numbers, and characters
in order to facilitate a really great password scheme. This is called
strong password protection. (The best password I ever saw of this
ilk was also profound in its hidden meaning: Mi$cr3ant.)
You should also insist on at least eight characters in a password.
Remember that someone who has a password of doggie11 isn't likely
to stand up under password cracking software very long, so you must couple
a password length requirement with strong passwords.
Administrators must pay very careful daily attention to the Microsoft
security Web site (http://www.microsoft.com/security)
as well as to the Web sites of their firewall, anti-virus, intrusion detection
and Web-filtering software vendors. You should have a test lab that roughly
mimics your production environment and be prepared to test and quickly
implement security patches as they are rolled out. Note: I know
security and perimeter administrators that also pay attention to the common
hacker Web sites in order to glean information regarding the next new
thing in hacking as well as to the International Computer Security Associate
(ICSA) Web site (http://www.icsalabs.com/index.shtml)
for information on computer security topics.
If you're being challenged by higher-ups that there is a fear-factor
regarding the allowance of telecommuting, then you should go to the table
prepared to defend the allegations by stipulating how you intend to carefully
and completely manage the new environment.
There are some really great telecommuting methods—all of which
fall under the high-security scrutiny (say that three times fast) banner:
- Dial-in—This technology, supported in Windows 2000 Server
software by what is called Routing and Remote Access (RRAS) allows you
to set up a dial-up infrastructure in which your clients can use dial-up
software (bundled with Windows) on their local PCs to access the network.
RRAS has the ability to provide you with good quality encryption and
security for those dialing in. Note that just because you have RRAS
available on your Windows 2000 server, you still must provide the
telecommuting infrastructure, i.e. the modems that will answer the
calls. Setting this infrastructure up can be time-consuming and require
the assistance of other folks in your company to get it going.
- Virtual-private network (VPN)—The idea here isn't necessarily
how the client gets to the private network (i.e. over the Web
or through dial-up) as much as how secure the client is at connection
time. We'll talk more about VPNs in the next section of this article.
- Wireless access—Clients with a wireless device (i.e. blackberry,
802.11 et al.) may need to get onto the private network. Generally this
accomplished either by allowing the user to set up a VPN connection
through the Internet or by setting up a Wireless Access Point (WAP)
for entry to the private network. Client encryption (the heftier the
better) is advisable in a wireless environment. (See my February column
Act" for more info.)
Virtual Private Networking
The idea behind a VPN is that your clients tunnel through
the Internet, using ordinary TCP/IP protocols, but encapsulate the data
within the packets in encrypted format. A VPN connection is a point-to-point
connection that allows your users to access your private network in secure
fashion utilizing widely available connection software. There are four
security elements that you'll be concerned with when you consider a VPN
solution for your telecommuting needs:
- Authorization—Will the user be utilizing ordinary logon
username and password or will he or she be granted a certificate through
your company's certificate authority (CA). Windows 2000 uses a new security
standard called IPSec that can be utilized over VPN connections. Today
you have the capability of setting up a CA within your Windows 2000
network. Note that the setup of a CA, depending on the size of the organization
can be a large rigorous project in and of itself. Further, managing
the CA hierarchy will be something that someone has to pay attention
to on a daily basis.
- Tunneling protocol—In the Windows 2000 world, there are
two tunneling protocols—two methods whereby the data can be burrowed
in the TCP/IP packets—Point to Point Tunneling Protocol (PPTP)
or Layer Two Tunneling Protocol (L2TP, the most recent of the two).
Certain clients (i.e. pre- or non-Windows 2000) may not be able to utilize
L2TP, so in a disparate client environment, your choice may be the earlier
PPTP. Understanding the client pool will allow you to make a good decision
regarding the tunneling protocol in use. You may recognize that you
need to use both, in which case the architecture of your VPN solution
gets more complicated and may require additional hardware and time to
- Encryption strength—You'll have to decide if you want
your clients to connect with 56-, 64- or 128-bit encryption. There's
a trade-off here: Larger encryption strength means eminently less hackable,
but requires more CPU time, both locally and at the server. This notion
comes heavily into play in the wireless arena where your users are already
probably slowed by the diminished bandwidth of wireless protocols such
as 802.11. I.e., a 100MB Ethernet-attached client won't see as much
performance degradation using 128-bit encryption as a Tablet PC user
will connecting at 11MB (or slower). (With each encryption level is
an associated encryption algorithm. Note that the algorithm in use,
while possibly technically interesting, isn't really important to you.)
- Connection method—In the Microsoft camp you can use an
RRAS server and Windows 2000 Connection Manager (see http://www.microsoft.com/technet/treeview/default.asp?
more info) or Microsoft Internet Security and Acceleration (ISA) Server
to facilitate your VPN. You can also use third-party VPN software or
hardware solutions to implement your VPN. Additionally, some ISPs offer
VPN hosting for companies, so this is a viable, though more costly,
option as well.
In terms of connection method, my preference is for ISA server. We have
it running where I work and I'm very happy with the way that it operates—its
connection speed and reliability, as well as the security and ease of
administration that it affords my perimeter admin. The thing I like most
about ISA is that it brings to the table a vast array of preconfigured
security options that are turned on via a wizard. ISA provides for stately
packet inspection and interfaces with Active Directory. Other ISA servers
can be put into an array for downstream operations in large environments.
Additionally, it uses the Real Secure intrusion detection (ID, http://www.iss.net)
for a basic ID shell plus you have the ability to snap in the full Real
Secure client to provide a robust ID gateway for your ISA box. ISA will
also work with Web-filtering software. ISA comes with preconfigured snap-ins
for PPTP or L2TP clients accessing the private network and makes the admin's
job quick and easy (once she understands the ISA interface and underlying
operation, of course). Smaller shops will find that ISA Server is a great
way to set up a firewall, ID and VPN host all in one box. Add anti-virus
and Web-filtering software and you've got a convenient one-box perimeter.
I also like the fact that ISA server can play in the sandbox with Microsoft
SharePoint Portal Server meaning that, with some configuration work, you
can provide a hearty extranet environment for both your telecommuting
users and B2B'ers.
That being said, I also think that Microsoft's RRAS software is sufficiently
mature enough to allow you to provide a very secure and robust VPN environment,
though you'll have to go through considerably more configuration than
if you had an ISA server and you'll have to think about other choices
if you're interested in ID, Web-filtering and firewall. The choice between
the two would boil down to the cost of the ISA software that, while affordable,
still increases the cost of the telecommuting project.
You should also note that there are some "soft" components to setting
up a VPN solution that you might overlook:
- End-user training—You'll have to provide some sort of
instructions whereby at-home users can figure out how to connect using
their VPN software. Keep in mind that the network connection software
varies by OS versions (i.e. Windows 95 connects differently than Windows
XP, while Mac clients are completely different from Windows,
etc.) so you're going to have to be prepared to cope with almost all
client connectivity scenarios. Where I work we created little instruction
booklets, complete with screenshots, that users can print out and take
home with them to configure their VPN client software.
- Name-server and NAT configurations—Because your VPN server
will live on the DMZ, you'll have to be able to successfully resolve
its name both outside and inside the private network as well as be able
to use network address translation (NAT) to mask internal IP addresses.
This is yet another reason why I prefer ISA server because it NATs out-of-box.
An RRAS solution requires you to also configure your Windows 2000 server
as a router for NATing, thus incorporating increased complexity and
processing cycles. Note that if you already have a well-established
perimeter, these things are already there so you don't have to worry
- Allowance of Internet surfing—By setting up a dial-up
VPN solution, you may inadvertently give your telecommuters a nice little
surprise you hadn't thought about—the Internet for free. If your
users dial in and connect as VPN clients, they have a valid IP address
thus allowing them to pull up their browser and access the Internet
on your company's dime. This may or may not be acceptable, depending
on how your management staff views it. It's possible to configure ISA
server so that this is not allowed.
Keeping the Connection Alive
Setting up a VPN isn't hard to do, but there's a lot of technical meat
to it and you'll need to devote some time for "discovery"—i.e. what
all the wrong methods are so that you employ the right ones. I recommend
setting up a VPN lab so that you can set up and try all this stuff out
first before you deploy it in production. A hack is not a nice way of
finding out about a hole in your deployment.
Additionally, you have to be sure that someone in the organization is
extremely protocol-knowledgeable relative to the protocols in use on your
VPN so that you have a security heartbeat going at all times. Remember
that the hacks involved in the telecommuting arena are stealthy and involve
things like discovering usernames and passwords, spoofing routers, denial-of-service
(DOS, the most popular method today, simply because it's the easiest to
implement quickly) attacks and port sniffing. If someone's able to access
your private network with a legitimate username and password, they have
all the time in the world to surf around to see what kind of goodies they
can steal. I would also recommend that, if someone's not already hooked
up, you designate a person to get involved with the International Computer
Security Association (ICSA) labs (http://www.icsalabs.com/index.shtml)
so that he or she is familiar with the complete context of computer security.