Are you looking for a way to significantly enhance security for your Internet-facing Microsoft applications and services? If so, take a look at Microsoft Internet and Security Acceleration (ISA) Server 2004, which makes a quantum leap beyond its predecessor, ISA Server 2000. ISA Server 2004 provides a network firewall that performs both stateful filtering (at the Open System Interconnection—OSI—model's transport layer 4 and below) and stateful application-layer (layer 7) filtering on all installed interfaces.
Many organizations have an existing firewall infrastructure but still want to obtain the security benefits that ISA Server 2004 provides. The ISA Server 2004 firewall is extremely flexible and has a number of viable deployment options. One of the most common and most secure of these options is a back-to-back firewall configuration, in which a traditional packet filterbased hardware firewall on the front end provides basic stateful filtering to protect the demilitarized zone (DMZ) between the firewall and the LAN interface, and an ISA Server 2004 firewall on the back end provides both stateful filtering and stateful application-layer inspection to protect core business resources.
Filtering remote access to Microsoft Exchange Server services is a popular ISA Server scenario, and several of the firewall's new technologies provide a unique level of protection for Internet-facing Exchange services, especially Microsoft Outlook Web Access (OWA). If you're interested in placing an ISA Server firewall behind an existing packet filterbased hardware firewall, this scenario provides a good example of the required procedures. Figure 1 shows a high-level view of the back-to-back firewall design. Key features of the network and firewall topology include the following:
A stateful packet-filtering (application-specific integrated circuit—ASIC—based) hardware firewall, which I'll call the hardware firewall, is placed on the front end. This rudimentary firewall provides layer 4 and below protection for hosts on the perimeter network between the hardware firewall and the ISA Server 2004 firewall, which I'll call the ISA firewall.
This DMZ segment is an unauthenticated segment: Whereas public servers in the DMZ might require local authentication at the server, no authentication is required to enter the segment.
- A stateful filtering and stateful application-layer (layer 7) filtering ISA firewall is placed on the back end. This firewall, which is closer to core business assets, must provide a higher level of protection than the hardware firewall. The ISA firewall achieves this goal by performing the same stateful filtering as the hardware firewall but exceeds the hardware firewall's protective ability by adding stateful application-layer inspection. In addition, strong user- and group-based authentication is required for all inbound and outbound connections through the ISA firewall.
- The ISA firewall has three network interfaces: an external interface that connects to the DMZ segment, an internal interface that connects to a network infrastructureservices segment containing core infrastructure servers (e.g., a domain controller—DC—and Global Catalog—GC—server, a front-end Exchange server, a back-end Exchange server), and another internal interface that connects to a network segment containing client systems. No unauthenticated connections are allowed from the external interface to the infrastructure-services segment, and no connections at all are allowed from the client segment except those necessary to use network services. This design protects the network infrastructure servers not only from external attacks but also from attacks launched by hosts on the client segment.
- The ISA Server system is a member of the internal network domain. Some experts suggest that domain membership can compromise internal network security in the event that the ISA Server system is compromised. However, if that happens, the server's domain membership has little effect on how much damage an attacker can accomplish. The protection you gain by making the ISA Server system a member of the domain far outweighs any theoretical advantages of not doing so.
- Secure Sockets Layer (SSL)to-SSL bridging on the ISA firewall is used to prevent exploits from hiding inside SSL tunnels. The remote Web client tunnels through the hardware firewall and terminates its SSL session with the ISA firewall's external interface. The ISA firewall decrypts the packets, performs stateful application-layer filtering on the communications, and re-encrypts the packets to send them along a second SSL link established between the ISA firewall's internal interface and the front-end Exchange server.
- The ISA firewall is configured to require that a client certificate be presented to the front-end Exchange server's OWA Web site. This requirement protects the front-end Exchange server in the event that an attacker tries to use another machine (e.g., through a spoofed IP address) to impersonate the ISA firewall and forward connections to the front-end Exchange server. Because such an attacker won't have a valid client certificate, the connection attempt will fail even if the attacker has valid OWA user credentials. Note that the Web client doesn't present a client certificate to the Exchange server or ISA firewall; only the ISA firewall presents a client certificate when establishing the SSL link between itself and the front-end Exchange server.
Of course, you can configure your firewall and network infrastructure in many other ways. For example, many firewall administrators demand that there be no Internet-facing servers on a network that contains the DC and other key network-infrastructure servers. In that case, you could add a fourth network interface to the ISA firewall; place the front-end Exchange server on a dedicated, authenticated, access-only perimeter network segment; and use the ISA firewall's access rules to allow only the required protocols from the front-end Exchange server to the back-end Exchange server and the DC/GC server in the infrastructure-services segment.
Let's continue this discussion using our sample configuration, though. This configuration assumes that your enterprise CA is in the same domain as your Exchange servers. The following procedures are required to publish your front-end Exchange server's OWA site to remote users on the Internet:
1.Configure the public DNS to forward incoming OWA connections to the correct address.
2.Configure the hardware firewall to forward incoming TCP port 443 connections to the ISA firewall.
3.Request and bind a Web site certificate to the OWA Web site on the front-end Exchange server.
4.Export the Web site certificate to a file.
5.Configure the OWA directories to use Basic authentication, force SSL connections, and require a client certificate from the ISA firewall.
6.Create a user account for the ISA firewall.
7.Request a client certificate for the ISA firewall's Web proxy.
8.Import the Web site certificate into the ISA firewall's machine certificate store.
9.Import the ISA firewall's client certificate into the ISA firewall service's personal certificate store.
10.Create the OWA Web publishing rule on the ISA firewall.
11.Harden the OWA Web publishing rule by configuring the HTTP security filter.
12.Create a HOSTS file on the ISA firewall that maps the fully qualified domain name (FQDN) of the OWA site to the OWA site's internal IP address.
13.Request and install the root CA certificate on the Web browser client.
Let's go through the first five of these steps. I'll examine the other steps in a follow-up article.
1. Configure the Public DNS
The first step in an OWA publishing project is to get your DNS house in order. The ideal configuration is a split DNS infrastructure, in which the same name resolves to different IP addresses, depending on the user's location. For example, when the user is located on the corporate network, the name owa.domain.com resolves to the IP address of the front-end Exchange server on the corporate network. When a user is situated in a remote location, the name owa.domain.com resolves to an IP address that's accessible from the Internet.
The DNS host record depends on the IP addressing schemes you use on the DMZ and the infrastructure-services segment. If you use Network Address Translation (NAT) between the Internet and the DMZ, register the IP address of the hardware firewall's WAN interface as the FQDN that remote users use to access the OWA site. If you use public addresses on the DMZ and on the hardware-firewall routes between the Internet and the DMZ, use the IP address of the ISA firewall's external interface.
2. Configure the Hardware Firewall
This firewall doesn't perform stateful application-layer filtering, so it can't evaluate HTTP host headers to determine an incoming request's destination URL. Thus, you need to configure this firewall to forward to the IP address of the ISA firewall's external interface all incoming connections for the OWA site. The procedures for doing so vary for different firewalls, but all simple, stateful-filtering firewalls support routing or reverse NAT to a specific socket (i.e., IP address, protocol, and port).
3. Request and Bind a Web Site Certificate to the OWA Web Site
The ISA firewall impersonates the OWA Web site when you configure SSL-to-SSL bridging so that remote Web browser clients establish a connection to the ISA firewall's external interface. The ISA firewall impersonates the OWA Web site by presenting a Web site certificate that contains the same name as the OWA Web site. For example, if your OWA Web site has the address https://owa.domain.com/exchange/, when establishing an SSL session with a user, the ISA firewall presents a certificate that has the common name owa.domain.com. Because you're using an enterprise CA in the same domain as your Exchange servers, you can use the Microsoft IISintegrated Web Site Certificate Request Wizard to request and bind a certificate to the OWA Web site.
At the front-end Exchange server, open the Microsoft Management Console (MMC) Internet Information Services (IIS) Manager console, right-click the Default Web Site, and select Properties from the context menu. Go to the Directory Security tab, then click Server Certificate to launch the Web Site Certificate Request Wizard.
On the Server Certificate page, select Create a new certificate if you don't already have a Web site certificate for the OWA site. If you already have a certificate (perhaps from a commercial CA), click Assign an existing certificate. For this example, I'll assume that you're creating a new certificate.
Because you have an online enterprise CA, choose Send the request immediately to an online certification authority. (If you had a standalone CA, the only option would be to prepare an offline request and manually submit that request by using the CA's Web enrollment site.) Follow the wizard's instructions until you reach the Your Site's Common Name page, which Web Figure 1 shows.
This page is the wizard's most crucial page. Your entry here determines the Web site certificate's common name (CN). The CN must match both the name that remote users use to access the OWA Web site and the name you use in the redirect when you create the Web publishing rule on the ISA firewall. This example uses the name owa.domain.com. In your production environment, you'd use the name that your remote users use to access the OWA Web site.
Continue through the wizard; click Finish when you reach the last page. At this point, notice that the View Certificate button is now available on the Directory Security tab.
4. Export the Web Site Certificate to a File
You can now export the Web site certificate to a file. You'll use this file later to import the Web site certificate and its private key into the ISA firewall's machine certificate store.
Click View Certificate on the Directory Security tab. Go to the Certificate dialog box's Certification Path tab. Notice that the root CA and the Web site certificates are included in the hierarchy. If you see a red x next to the name of the Root CA, the root CA certificate isn't contained in the front-end Exchange server's Trusted Root Certification Authorities machine certificate store. However, when you use an enterprise CA, its root certificate is automatically placed in the Trusted Root Certification Authorities machine certificate store.
Go to the Details tab and click Copy to File to launch the Certificate Export Wizard. On the Export Private Key page, select Yes, export the private key. Failure to select this option is one of the most common causes of failure in SSL-to-SSL bridging scenarios.
On the Export File Format page, select Personal Information Exchange-PKCS #12 (.PFX) and clear the Enable strong protection check box. You must disable this option because it requires user intervention and our publishing scenario has no mechanism to support the required interaction. Select the Include all certificates in the certificate path if possible check box.
Enter a strong password on the Password page. You want to ensure that the private key won't be stolen if an intruder steals the file. A strong password goes a long way toward achieving this goal.
Enter a complete path with filename on the File to Export page. In this example, we'll use C:\owacert. You don't need to include the file extension; it will be entered automatically.
Click Finish to complete the wizard. Click OK in the Default Web Site Properties dialog box.
Copy the file to removable storage. You'll copy the file to the ISA firewall system later.
5. Configure the OWA Directories
You need to configure your OWA-specific directories—ExchWeb, Exchange, and Public—to force SSL connections, require a client certificate, and require Basic authentication. Using only Basic authentication provides the greatest level of compatibility and the most transparent access for remote OWA users, but if you plan to support Exchange ActiveSync (as in our example), you'll also need to enable Integrated authentication on the Exchange directory.
In the Internet Information Services (IIS) Manager console's left pane, right-click the ExchWeb directory and select Properties from the context menu. Go to the Directory Security tab. Click Edit in the Authentication and access control section to open the Authentication Methods dialog box. Be sure that the Enable anonymous access check box is cleared. You don't want to entertain the possibility of an unauthenticated connection from remote users to any directory on the OWA server. Select the Basic authentication check box and enter the default domain's NetBIOS name in the Default domain text box. In this example we enter DOMAIN as the NetBIOS name for our default domain. Click OK.
While still on the ExchWeb Properties dialog box's Directory Security tab, click Edit in the Secure Communications section. In the Secure Communications dialog box, which Web Figure 2 shows, select the Require secure channel (SSL) and Require 128-bit encryption check boxes and the Require client certificates option. Click OK to save the secure communications options, then click OK to save the ExchWeb directory's configuration. In the Inheritance Overrides dialog box, click Select All, then click OK.
To connect to the OWA Web site, the ISA firewall must present a client certificate, but that certificate controls only the establishment of the SSL connection between the ISA firewall's internal interface and the front-end Exchange server. The user credentials that the remote user presents control mailbox access. The client certificate requirement doesn't have any influence over user mailbox access; rather, it controls only which device can make a direct connection to the front-end Exchange server. Later, you'll request a client certificate for the ISA firewall's Firewall Service and configure the ISA firewall to present this client certificate to the OWA Web site.
In the Internet Information Services (IIS) Manager console's left pane, right-click the Exchange directory and select Properties. Go directly to the Directory Security tab, open the Secure Communications dialog box as I explained earlier, and select the same check boxes and option that you selected for the ExchWeb directory. Click OK.
While still on the Directory Security tab, click Edit in the Authentication and access control section. This time, select the Integrated Windows authentication and Basic authentication check boxes, then enter a NetBIOS name for the default domain name in the Default domain text box. Enabling Integrated authentication for the Exchange directory keeps your options open for publishing ActiveSync access. Click OK to save the authentication settings, then click OK to save the Exchange directory's configuration.
Repeat the process for the Public directory, enabling only Basic authentication in the Authentication Methods dialog box.
Well Begun
Next time, we'll continue through the process with Steps 6 through 13. When we're finished, you'll have an excellent example of how ISA Server 2004 can improve the security of network-facing applications and services such as OWA. (In the meantime, you can learn more about ISA Server 2004 in the Windows IT Pro article " Improving on ISA Server," May 15, 2004, InstantDoc ID 42409.)
