Windows Foundation

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
• 03/01/2003

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 reasons:

• 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 business-to-business transactions.
• 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 here:

• 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 thing out.

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

Telecommuting Methods
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, Ricochet (http://www.richochet.com), 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 "Hi-Wireless 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 implement.
• 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?
  url=/technet/itsolutions/network/deploy/depovg/vpndeply.asp for more info) or Microsoft Internet Security and Acceleration (ISA) Server (http://www.microsoft.com/isaserver) 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 about it.
• 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.