[ Go to September 1997 Table of Contents ]|
-- by Tom Henderson
A nervous client called recently to say his company feared its remote-access server had become insecure. A former employee bragged that he could break in via the modem pool, and-not surprisingly-the company's brass became concerned that its network's security might be cracked and compromised. Putting a focused watch on modem connections would have overtaxed an already frenzied IT department, so the order came down to pull the plug on the modem pool for a while-possibly forever.
There's never a good excuse for bad security policy enforcement, but the client said getting the entire executive staff to change all of its passwords would cause a revolt. So he was forced to take the modem pool offline until he could implement another "secure" solution. In the interim, offsite users were screaming for access. Not only were the dozen or so remote users out of luck, but the backup route for two branch offices that had low-speed dedicated circuits was also down.
My first thought was to use modem dial-back. This means that users would dial in and log on to the modem pool, and a modem would dial back to a short list of specific phone numbers. Although the modems in the pool supported this, the setup wouldn't work for hotel-bound road warriors. Users based at home and fixed remote sites okayed the dial-back idea, but the mobile sales department quashed it.
That's when I thought about a Virtual Private Network (VPN). I realized that all the users could gain access through the Internet-if I could convince both myself and the client that it was foolproof, accessible by all participants and relatively easy to deploy. The client had a T1 connection to a local ISP and an additional T1 backup route through a second ISP. Both T1s sat on the same side of a BorderWare 4.1 firewall (from Secure Computing Corp.). Secure Computing offered VPN server-to-server secure network options, but my client wanted even more security.
Just the thought of creating a VPN is enough to send many network administrators running for the aspirin bottle. They fear security breaches, of course, but that's not the only potential problem. How do you manage users? Can crackers attack, hijack, spoof or replay sessions? Do protocol limitations exist? Are firewalls that permit VPNs suddenly vulnerable? Can you successfully explain the concept to a nontechnical superior? None of these questions are trivial.
But connecting via a VPN provides the best means of access for mobile users to hook up with a notebook PC and remote-access software. The other options for an out-of-town user include placing a toll phone call with a modem to a remote-access system or settling for a single service such as e-mail forwarded to AOL, CompuServe or another nationwide service.
Direct dialing to a remote-access modem pool or server is expensive. Hotels charge a premium for direct-dial phone calls, and some even charge for dialing toll-free numbers. To get around the cost, a mobile worker can forward e-mail to AOL, Netcom, UUNet, CompuServe or another ISP. But this could lead to message and attachment translation problems, like CompuServe's on-again, off-again MIME attachment support. And in some cases, the dial-up service posts messages so slowly that they don't appear until the user has already returned to the office.
For network resources beyond simple e-mail and e-mail attachments, the mobile user must make a toll call when outside the local calling area. Although Windows 95 and NT Workstation 4.0 have provisions for credit-card information, the available configurations can't handle all the access providers and the strings needed to complete a call.
VPN connections remove the modem pool and router board or box from the equation. A VPN also eliminates the cost of the phone lines connected to the modem pool. It can also eliminate management and support overhead costs associated with the remote access system.
The VPN choices
For this client, our search narrowed to three possible VPN access methods for remote users. Because my client's an NT shop, we first considered Microsoft products. Microsoft's Point-to-Point Tunneling Protocol (PPTP) works on Windows 95 and NT, but currently does not support other clients. PPTP's chief benefits are that it's a free component of the RAS and router software formerly known as Steelhead, it's somewhat protocol independent (it supports IPX and NetBIOS as well as TCP/IP), and it has a low-level protocol you can use with other security methods. However, PPTP is new, parochial in client support and not yet complete. My client rejected it because of its version 1.0 status.
We next considered IPSec, an ambitious encryption method. IPSec is currently found largely in network-to-network installations and may become a part of the Internet Engineering Task Force's (IETF's) IPv6 extensions to TCP/IP. My client rejected IPSec because it seemed too difficult for dial-up users to manage. We viewed IPSec as an 80-ton truck, when all my client needed was a small, safe car.
We decided on the SOCKS or SOCKetS protocol, now in version 5. SOCKS is the progeny of NEC and its licensees/friends. Aventail Corp. makes a version called AutoSOCKS that works with 16- and 32-bit Windows programs to perform a secure link to network resources. SOCKS5 can use a proxy through a firewall. Proxies are common in firewalls; they make services like the SMTP, RealAudio and other bidirectional links through firewalls possible.
We set up AutoSOCKS on an NT server, then poked a single hole (the proxy) through their BorderWare firewall and pointed the hole to the now "sockified" server. After a minor amount of massaging, a Dial-Up Network client using a PPP connection via CompuServe could successfully see the Socks server.
Installing AutoSOCKS takes a few moments on the client side and not much longer on the server side. The SOCKS server sits on the intranet or secure side of a firewall. Proxies to other network resources are set, but the SOCKS server is the agent for these resources, even if they reside on the SOCKS server itself.
Offsite users see AutoSOCKS load during system startup (an option), then call up resources by either their TCP/IP address or by their DNS name. Microsoft Exchange doesn't work well yet: Exchange's Internet POP3 support mail client can be configured with Exchange Server and will work, but without the popular shared folder access. With an FTP client, the server system's resources are shown as they would be on a normal Internet-access server.
AutoSOCKS client software sits close to the WINSOCK.DLL. AutoSOCKS listens to TCP/IP calls made to Winsock and intercepts those meant as SOCKS transactions. My client now has CompuServe and Netcom as its North American ISPs for calls made by mobile users. These carriers have points of presence in a huge number of cities. AutoSOCKS uses password authentication, and the users can optionally cache their passwords for reuse of services without constant password reentry.
The AutoSOCKS client software has a configuration file that you can distribute to everyone on the network. AutoSOCKS uses the SOCKS5 and SOCKS4 protocols to create secure connections to the AutoSOCKS server, which then proxies other select network resources. You can add Secure Socket Layer protection by using Netscape Navigator 3.0 or Internet Explorer 3.0 to access resources on the target network.
We proxied Citrix client software through the firewall to gain access to the Citrix WinFrame Enterprise server where all applications reside. That way, we could give users e-mail and file access. We then used the WinFrame Web Client and a separate TCP/IP network card to monitor the Citrix SOCKS-secured access.
The only thing missing in the final analysis was something as simple as an icon in the My Computer or Network Neighborhood and Exchange public folders. According to Aventail's Evan Kaplan, that's the Holy Grail of the VPN industry. Soon, he feels, we'll be logging on through industry-wide protocols from any Internet POP to our network resources in a way that would be extremely difficult to hack. And with luck, security software makers will be one or two steps ahead of the hackers.
Contributing Editor Tom Henderson is senior vice president of engineering for Indianapolis-based Unitel. Contact Tom care of the editor at the addresses on page 20.