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.