Today, VPNs are commonplace in businesses of all sizes, no longer limited to large enterprises. They're popular because they let users—typically mobile and home workers—access internal network resources that aren't available to users outside the firewall. VPNs tunnel through that firewall, effectively extending your corporate network to remote users. However, VPNs have a downside. Unless you take strict precautions, malicious users can exploit a VPN to gain access to your corporate network. The VPN can also be a gateway through which a worm or other malware can enter and wreak havoc behind your firewall.
VPNs will always have a place in some companies, but many businesses can do away with them. In this article, I describe two scenarios that VPNs are traditionally used for—corporate email and internal Web sites—then talk about effective alternatives.
Corporate Email
Email was once the killer application for businesses. Although its status might have diminished, it's probably still the primary justification for implementing a VPN. Typically, remote users dial in to a special toll-free number provided by a VPN supplier or ISP, supply special credentials, then connect to a VPN gateway, supplying their usual username and password. Once connected, users can launch their email client (e.g., Microsoft Outlook) and access their email server. This scenario is a bit cumbersome, and fortunately, there are now alternatives to consider.
RPC over HTTP. With Windows Server 2003, Windows XP Service Pack 1 (SP1) or later, Exchange Server 2003, and Outlook 2003, Microsoft introduced the concept of Remote Procedure Call over HTTP (RPC over HTTP). RPC is the underlying protocol in effect between Exchange and Outlook clients. By tunneling RPC through firewalls in an HTTP connection, it's now possible to access Exchange servers from outside the firewall. Users still must connect to the Internet, but that's an increasingly simple task given the ubiquity of broadband connections for teleworkers and Wi-Fi hotspots in coffee shops, convention centers, and airport lounges, as well as broadband-quality connections in hotel rooms. Once connected to the Internet, users can open Outlook 2003 and have access to their Inbox and other folders as though they were on their corporate LAN or the VPN.
There are many RPC over HTTP deployment scenarios. The simplest method, which I describe here, assumes that you have a single Exchange domain-member server running Exchange 2003 SP1 or later. If you have multiple Exchange servers, or one or more of your Exchange servers is also a domain controller (DC), I recommend that you don't follow these instructions but rather consult the Microsoft TechNet article "Exchange Server 2003 RPC over HTTP Deployment Scenarios" (http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/ex2k3rpc.mspx).
On the Exchange server, open the Microsoft Management Console (MMC) System Manager snap-in, select the Exchange server from the Servers node, right-click it, select Properties from the context menu, then go to the RPC-HTTP tab, which Figure 1 shows. Select RPC-HTTP back-end server. A warning message will pop up, stating that there are no front-end Exchange servers configured. You can safely ignore this warning for this single-server configuration, so click OK to dismiss it. Click Apply to effect the setting, then click OK to close the Properties dialog box.
If you have no front-end Exchange servers acting as RPC over HTTP proxy servers, you need to further configure your Exchange server. The first step is to install the RPC over HTTP Proxy (for Windows 2003) onto your Exchange server. To do so, open the Control Panel Add or Remove Programs applet, click Add/Remove Windows Components, scroll down the list of components until you reach Networking Services, click the Details button, select RPC over HTTP Proxy, click OK, click Next, then click Finish.
The second step is to configure authentication methods for the RPC over HTTP Proxy. Launch the MMC IIS snap-in by selecting Start, Administrative Tools, Internet Information Server (IIS) Manager. In the snap-in, navigate to Default Web Site, expand it, select the RPC virtual directory, and right-click it. From the context menu, select Properties. In the RPC Properties dialog box, go to the Directory Security tab and click the Edit button in the Authentication and access control section. In the resulting Authentication Methods dialog box, ensure that the Enable anonymous access check box is cleared. RPC over HTTP requires users to authenticate themselves. You can choose Integrated Windows authentication or Basic authentication, or both. I recommend that you select Basic authentication for RPC over HTTP. Although doing so means that usernames and passwords will flow through your network in clear text, you can use Secure Sockets Layer (SSL) to encrypt RPC over HTTP traffic. The use of Integrated Windows authentication will work in some scenarios but can be problematic, and problems are difficult to troubleshoot. If you select Basic authentication, the system will display a warning message. Click Yes to proceed with your selection, then click OK, Apply, and OK.
The third step is to configure ports that the RPC over HTTP Proxy will use. On your Exchange server, from the command line, run the command Ipconfig/all and record the host name and domain name. Next, launch a registry editor and navigate to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy subkey. Double-click the ValidPorts value, and edit it so that it reads
<hostname>:6001-6002;<hostname>. <domainname>:6001-6002; <hostname>:6004;<hostname> .<domainname>:6004;
where hostname and domainname are the values you recorded when you ran Ipconfig/all. The usual caveat applies: Editing the registry can cause your system to become unstable. Record the existing values for any entries and be prepared to reapply those should you encounter stability problems.
To allow Outlook 2003 clients to connect to Exchange 2003 servers through RPC over HTTP, you need to perform some configuration on the client, too. In Outlook 2003, select Tools from the menu bar, then Email Accounts. Select View or change existing e-mail accounts, click Next, select the email account of type Exchange, click the Change button, then click More Settings. In the Microsoft Exchange Server dialog box, go to the Connection tab, select Connect to my Exchange mailbox using HTTP, then click Exchange Proxy Settings. In the Exchange Proxy Settings dialog box, which Figure 2 shows, enter the URL for the Exchange proxy server and select the connection settings. Once the client and server are configured, Outlook 2003 will be able to communicate with Exchange 2003 without the need for a VPN.
OWA. If you don't want to install RPC over HTTP, or your users are running an older version of Outlook, or you're running Windows 2000 or Exchange 2000, users can still access email remotely through Outlook Web Access. OWA is extremely convenient and provides access to users' Inboxes and online folders from a simple Web browser. To access OWA from a browser, users simply type the name of their Exchange server and append /exchange (e.g., https://mail.contoso.com/exchange).
To enable access to email through OWA from outside the firewall, you'll need to publish your Exchange server—that is, make it available to Internet users. The simplest way to do so is to use ISA Server 2006 or a similar application-level firewall that can inspect OWA traffic for malicious traffic. ISA Server contains step-by-step wizards that make it easy to publish OWA sites. I recommend that if you use OWA, always use an SSL certificate to maintain confidentiality of email between your Exchange server and your users' browsers. I also recommend that you disable account lockout. If account lockout is enabled, a malicious user might be able to carry out a Denial of Service (DoS) attack against any user whose username they know.
Finally, to keep Help desk calls to a minimum, I recommend that you configure your firewall to direct any traffic addressed to the Fully Qualified Domain Name (FQDN) of the OWA server to the \exchange virtual directory on your Exchange server. That way, users won't have to remember to append /exchange to the URL they type into their browser. I also recommend that you redirect any user who forgets to type https:// or types just http:// to the SSL-protected site.
Internal Web Sites
Many businesses create intranet Web sites to share information (e.g., vacation days, internal phone directories) among team members or as internal reference sites for documenting policy, listing prices for products and services, and so on. Often, these Web sites are open to all users, with little or no access-control security. Although unrestricted access is fine for Web sites accessible only from inside the LAN, it's clearly unacceptable for such sites to be published to the Internet without establishing access control— particularly if the data might be considered confidential or sensitive. For this reason, businesses might turn to a VPN as the solution. Users must authenticate themselves to establish a VPN connection, at which point they're trusted and can be granted anonymous access to internal Web sites. There are, however, alternatives.
If the Web sites are hosted on IIS 6.0 Web servers that are member servers in the same domain or forest as the users, the Web server administrator can disable anonymous authentication and require users to authenticate. If the preferred authentication method for a Web site is Integrated Windows authentication, the Web site can be published to the Internet through a firewall. If the firewall is an application-level firewall (e.g., ISA Server 2006), you can configure access rules so that only certain parts or directories of a Web site are accessible from the Internet, and HTTP traffic can be scanned for malicious Web traffic.When a user attempts to connect to the Web site, he or she will be prompted for credentials.
I recommend using an SSL certificate to ensure confidentiality of data exchanged between the Web site and the user's browser. With ISA Server, it's possible to terminate the SSL session at the firewall, then proxy the connection to the Web site. The SSL certificate for the Web site is installed in ISA Server, which impersonates the Web site to the user's browser. This beneficial configuration lets ISA Server analyze traffic to the Web site, enforce access restrictions based on paths, and scan for malicious content.
With an SSL certificate in place, you can also enable Basic authentication to Web sites. Although you can configure Basic authentication without an SSL certificate, I don't recommend it because users' credentials will be transmitted in clear text between their browser and the Web site. Basic authentication is useful because it lets users who have a non-Windows client or browsers other than Microsoft Internet Explorer (IE) connect to Web sites. The downside of Basic authentication is that if the SSL connection is terminated at the firewall, the connection between the firewall and the Web site on the internal network isn't encrypted, so a malicious user with a network monitor (or even a malicious internal user) will be able to capture credentials unless the firewall can establish an SSL connection between itself and the Web site.
One of the problems of configuring a Web site to require authentication is that users might be prompted continuously for credentials. When the Web site is configured to use Windows Integrated authentication, and if users are using IE, it's possible to configure IE to send the user's credentials with each HTTP connection. By default, this configuration is in effect for sites in the local intranet zone, as you see in Figure 3. Simply add the public URL of each published Web site to users' local intranet zone in IE. Although this scenario might appear to be a security risk, it isn't: As with Windows Integrated authentication, NTLM hashes are used and clear-text credentials aren't exchanged between browser and Web site. If you're concerned that an NTLM hash sent over the network in an HTTP connection attempt might be used to obtain a user's password, you can use SSL to prevent eavesdropping of the NTLM hash.
If the SSL connection isn't terminated at the firewall but rather at the Web site itself, you can configure the Web site to require users to authenticate by using a Transport Layer Security (TLS) client certificate. In this scenario, a user must have an X.509v3 certificate issued by a Certification Authority (CA) trusted by the Web site. This certificate can be used for client authentication. If you don't have a Public Key Infrastructure (PKI) that can issue certificates to users, I recommend looking at Microsoft's own Certificate Services, which comes with Windows 2003 and Win2K. It's extremely easy to deploy and use. For more information about using Certificate Services for client authentication, see "Certificates and Exchange, Part 1" (InstantDoc ID 93440).
There are several advantages to using SSL with TLS. The first is that users aren't required to enter their credentials—they use a certificate instead. Second, most browsers on nearly every client platform support SSL with TLS. Third, certificates can be used to authenticate using SSL/TLS with Web servers other than IIS 6.0 (e.g., Apache). Fourth, it's possible to map certificates issued by third-party CAs to user accounts, obviating the need for you to establish and maintain a PKI. Finally, a certificate on a smart card or token (e.g., a Rainbow iKey) can be used, letting users use any machine without needing to enter credentials that might be recorded by a keylogger or other spyware. (Use of a smart card would require the machine to have a smart card reader, whereas a token such as iKey would simply plug into a free USB port.)
Further Considerations
When you've published your Exchange server using RPC over HTTP Proxy, and your Web sites, to do away with a requirement for a VPN, there are still some considerations to keep in mind. The first is users' tendency to include, in email messages, links to intranet Web sites that can't be resolved unless a user is on the corporate LAN (e.g., https://hr, http://sales). You can't expect users to remember the Internet FQDN for intranet Web sites, especially if you have many Web sites.
Another problem is that when users do use the full Internet FQDN in email messages to refer to Web sites, the URLs can't be resolved on the corporate LAN or intranet because the DNS namespaces are different. For example, the internal DNS namespace might be corp.contoso.com, but the Internet namespace is simply contoso.com, and the Internet site might be sales .contoso.com, but the intranet namespace is actually sales.corp.contoso.com. A related problem is the use of hostnames on Web sites to link to other Web sites. When a Web site is published to the Internet and contains a link with a hostname rather than a FQDN, or an internal FQDN that can't be resolved from the Internet, the link appears broken. With ISA 2006, Microsoft offers a solution to these problems. You can use ISA 2006 to dynamically change links and help do away with the requirement for a VPN, thanks to some cool features I don't have room to delve into here, including a portal that prompts users for credentials and from which they can access internal Web sites with Single Sign-On (SSO).
Reduce the Risk
VPNs are a useful and flexible means of allowing remote and mobile users access to your corporate resources, such as email and intranet Web sites. However, they can represent a security risk because they allow VPN clients unrestricted access. The solutions I've outlined might be more appropriate for remote and mobile users, permitting full, secure access to necessary business resources while reducing the risk to the enterprise.
