Traditional packet filtering firewalls use source and destination addresses and port numbers to control inbound and outbound access into and out of the corporate network. More advanced packet filtering firewalls examine connection state and determine its validity. Application layer aware firewalls can perform stateful inspection of application layer data and commands and block application specific attacks at the perimeter. A problem occurs when trying to protect secure SSL sites. Attackers can hide application layer attacks inside an SSL tunnel because the firewall is unable to statefully inspect commands and data hidden inside an encrypted tunnel. ISA Server 2000 firewalls can decrypt the encrypted packets, inspect them for valid commands and data, and then re-encrypt valid packets and send them to the secure SSL Web server on the corporate network. This SSL to SSL bridging allows ISA Server 2000 to provide a unique level of protection for secure Web servers located on the corporate network.

This document discusses traditional packet filtering firewalls and ISA Server 2000’s advanced SSL to SSL bridging feature that allows ISA Server 2000 to statefully inspect encrypted SSL connections. A complete step by step walkthrough is included that demonstrates how to configure ISA Server 2000 to perform SSL to SSL bridging.

The Problem: Attackers Hide Exploits and Users Hide Information Inside SSL Tunnels

Traditional firewalls use packet filtering to control inbound and outbound access to and from the corporate network. Traditional packet filtering typically uses the following information to determine whether to allow or deny a specific connection:

Source IP address
Destination IP address
Source TCP or UDP port
Destination TCP or UDP port
ICMP types and codes

Static packet filtering requires the firewall administrator to explicitly create a packet filter for each inbound connection, and then create a second packet filter to allow the outbound response. Some traditional packet filter based firewalls require you to create static packet filters for each interface handling the connection.

Let’s use Web server publishing as an example. A static packet filter is created to allow inbound connections from all high number TCP source ports (1023-65535) to TCP port 80 on the firewall. The firewall is configured to accept these connection requests directed to TCP port 80 and forward them to the Web server on the corporate network. The Web server responds to the external user’s request from its own TCP port 80 to the random high number port used by the client issuing the request. A second static packet filter must be created to allow the Web server to respond to the client. This packet filter opens all high number ports (1023-65535) outbound to all IP addresses.

Static packet filters are not very secure because, in order to allow the Web server to respond to the client request, you must allow outbound access to all high number ports for all Internet IP addresses. You can configure the packet filter to allow only the Web server’s IP address as the source of outbound connections to all these ports, but there still remains a very large number of ports open for outbound access. Internet intruders can take advantage of this situation and compromise your network.

Figure A shows inbound and outbound connections and packet filters.

More sophisticated packet filtering firewalls do not require an explicit packet filter for the Web server’s response. In addition, the more sophisticated packet filtering firewall keeps track of the state of a connection. The TCP protocol is a session based protocol that includes a number of connection states. The firewall can use session state information in the TCP packets to prevent Internet intruders from “hijacking” a legitimate connection to the firewall. The UDP protocol is a stateless protocol and depends on client and server applications to track session state. However, firewalls can use a number of methods to assign pseudo-statefulness for UDP connections.

Traditional packet filtering firewalls that track TCP session state and enforce a pseudo-statefulness for UDP connections are referred to as stateful packet filters. These stateful packet filtering firewalls perform stateful filtering. ISA Server 2000 is a multilayer firewall and performs stateful filtering via its dynamic packet filtering mechanism.

The problem with stateful filtering is that present day intruders aim attacks at known and unknown weaknesses of the server. A stateful filtering firewall is not aware of the application layer commands and data moving through it. As long as the source and destination IP addresses and port numbers are acceptable and the session state information is valid, the firewall passes the packets through. This allows attackers to create what appear to be valid connections with the firewall and pass attack code to the server on the corporate network.

Let’s return to the Web publishing scenario discussed earlier. An attacker sends a request to the Web server located on the corporate network. The source and destination addresses and ports in the request are valid and there is no abnormality in the session state. The firewall passes a Web request to the Web server on the corporate network. The attacker embeds attack commands in his request and disables or takes over the Web server. The attack was successful because the firewall was not able to check the HTTP application layer commands and data.

ISA Server 2000 can perform stateful inspection in addition to stateful filtering. Stateful inspection enables the firewall to examine application layer commands and data. A firewall like ISA Server 2000 can block the attack code passing through the stateful filtering mechanism because the packets are subsequently passed to the stateful inspection mechanism. ISA Server 2000’s stateful application layer filter examines HTTP commands and data and blocks packets from being passed to the Web server on the corporate network. This stops the attacks at the perimeter.

Figure B shows the ISA Server 2000 stateful application layer filtering firewall stopping the attack at the perimeter.

The application layer aware firewall must be able to read the contents of the HTTP packets as they move through the firewall. Problems arise when the remote user connects to the firewall using SSL protected HTTP connections. SSL encrypts the HTTP application layer information and prevents the firewall from performing stateful inspection on those packets. Stateful inspection firewalls configured to allow inbound SSL connections cannot inspect the commands and data inside the encrypted SSL packets and forward the connections through to the SSL Web site on the corporate network. Figure C shows the attack code moving through the firewall inside the SSL tunnel.

Figure C

Attackers can take advantage of this situation by connecting to SSL sites on the corporate network. The attacker is able to hide attack code from the stateful inspection firewall because the firewall can’t evaluate the content inside the SSL encrypted packets. The same attacks that work against non-stateful inspection firewalls will work against the stateful inspection firewall when an SSL connection to the protected Web site is allowed.

The Solution: ISA Server 2000 SSL to SSL Bridging

The solution to this problem is ISA Server 2000’s unique SSL to SSL bridging feature. SSL to SSL bridging allows the ISA Server 2000 firewall to statefully inspect SSL connections and prevent attackers from hiding exploits inside the SSL channel. The ISA Server 2000 firewall decrypts the packets, inspects them for attack code, and then re-encrypts them The re-encrypted packets are forwarded to the secure SSL Web server on the corporate network.

Figure C shows how the SSL to SSL bridging process begins. The Web browser client creates a secure SSL connection to the external interface of the ISA Server 2000 firewall. The Web browser computer has the root CA certificate of the Certification Authority that issued the Web site certificate (this allows the Web browser to trust the certificate presented by the ISA Server 2000 firewall when the SSL session request is made). The ISA Server 2000 firewall decrypts the packets and statefully inspects them for abnormal commands and attack code.

Figure C

If the ISA Server 2000 firewall determines that the packets contain attack code or illegal commands, then the firewall drops the connection and blocks the attack at the perimeter. The exploit against the secure SSL Web server on the corporate network is stopped at the network edge and never gets to the corporate network (figure D).

Figure D

If the ISA Server 2000 firewall determines that the connection is legitimate and that there are no exploits or attack code contained in the packets, then the firewall establishes a second new session with the Web server on the corporate network. The ISA Server 2000 firewall re-encrypts the packets and sends them to the secure SSL Web site on the corporate network. The inbound connection is protected “end to end” from the Web browser client to the secure Web server on the corporate network (figure E).

Figure E

The response from the secure SSL Web server moves along the same path as the incoming connection. The Web server encrypts the data and forwards the encrypted data over the secure SSL channel between the Web server and the internal interface of the ISA Server 2000 firewall. The ISA Server 2000 firewall then decrypts the encrypted packets and can then inspect them for abnormalities. If the packets are abnormal, then the ISA Server 2000 firewall can drop them. If the response passes inspection, then the ISA Server 2000 firewall re-encrypts the packets and forwards the response to the Web browser client.

Note:
This scenario details how SSL to SSL bridging works. You can also configure the ISA Server 2000 firewall to perform SSL to HTTP bridging. We recommend against this configuration because remote hosts expect an SSL secure connection from end to end. This implicit security agreement is broken when SSL to HTTP bridging is used.

Figure F

The ISA Server 2000 firewall impersonates the secure Web server on the corporate network. The browser client believes that it is communicating with the actual Web server because the ISA Server 2000 firewall presents a certificate that has the Web server’s name on it. This is the name used in the URL request made by the Web browser client. If the common name on the certificatematches the name in the URL when the Web browser client reads the Web server certificate presented by the ISA Server 2000 firewall during the SSL session initiation request, then the Web browser client assumes it is connecting to the actual Web server. This is how the ISA Server 2000 firewall is able to impersonate the actual Web server.

Figure G displays how this Web server impersonation works. For example, the Web browser client sends a request to www.domain.com. The ISA Server 2000 firewall receives the request and forwards the Web site certificate to the Web browser client. The Web browser client checks the common name on the certificate. If the common name on the Web site certificate presented by the ISA Server 2000 firewall is www.domain.com (and the Web browser client trusts the CA that issued the certificate), then the browser client will complete the SSL sessions negotiation and a secure SSL channel is established between the browser client and the ISA Server 2000 firewall’s external interface. The SSL session will not be completed if the name on the certificate is not the same as the name included in the client request.

The Web Publishing Rule on the ISA Server 2000 firewall then redirects the connection to the secure SSL Web server on the internal network. The request the ISA Server 2000 firewall sends to the secure Web site on the internal network must be for the name included on the Web site certificate. In this example, the request the ISA Server 2000 firewall sends must be to www.domain.com. The Web Publishing Rule should be configured to redirect to www.domain.com and forward the request to the IP address of the secure Web site on the corporate network. This can be accomplished by using a split DNS or HOSTS file on the ISA Server 2000 firewall.

Note:
We will go into the specifics of this configuration later in this document.

Figure G

Placing the ISA Server 2000 Firewall on Your Network

The ISA Server 2000 firewall can be the only firewall on your network, or you can integrate ISA Server 2000’s powerful application layer filtering protection with your existing firewall infrastructure. Some of the common ISA Server 2000 network topologies are:

ISA Server 2000 acting as front-end firewall
ISA Server 2000 acting as back-end firewall
ISA Server 2000 acting as front-end and back-end firewalls
ISA Server 2000 acting as application layer filtering gateway in a perimeter network

ISA Server 2000 Front-end Firewall Topology

Smaller organizations or organizations that do not already have a large investment in a current firewall infrastructure may prefer to make the ISA Server 2000 firewall a front-end firewall. The front-end firewall has a network interface on the corporate network and a network interface directly connected to the Internet. All communications into and out of the corporate network are exposed to ISA Server 2000’s deep application layer inspection.

The advantages of this configuration include:

All communications into and out of the corporate network are exposed to firewall policy
You only need to learn how to configure the ISA Server 2000 firewall software; this avoids the potential for firewall misconfiguration when multiple vendor firewalls are used
All inbound and outbound access can be controlled on a granular user or group basis. Users only access the content and servers you want them to access, based on the rules you configure
This configuration is easy to set up and maintain

Figure D shows the network topology for the ISA Server 2000 front-end firewall placement.

ISA Server 2000 Back-end Firewall Topology

Organizations that already have an existing firewall infrastructure may prefer to leave the current firewalls in place and put the ISA Server 2000 firewall behind the current firewalls. This topology allows third party firewalls to provide high speed packet filtering (stateful filtering) before forwarding the remaining packets to the application aware ISA Server 2004 firewall. The network between the third party front-end firewalls is a perimeter network where publicly accessible services can be placed.

The third-party packet filtering firewalls have an interface directly connected to the Internet and an interface connected to a perimeter network between the third-party packet filtering firewalls and the ISA Server 2000 application layer aware firewall. The ISA Server 2000 firewall has an interface on the perimeter network and an interface on the protected, corporate LAN.

Advantages of this configuration include:

Organizations do not need to perform a major redesign of their current firewall infrastructures
Third party hardware-based firewalls can perform high-speed packet filtering. This offloads packet filtering overhead from the ISA Server 2000 firewall and increases the resources available on the ISA Server 2000 firewall to perform deep application layer inspection
Resources located on the corporate network are protected by the ISA Server 2000 firewall’s enhanced application layer inspection mechanisms
Granular inbound and outbound access control can be done on a user/group basis

Figure E shows the topology of the ISA Server 2000 back-end firewall topology.

ISA Server 2000 Front-end and Back-end Firewalls

The ISA Server 2000 front-end and back-end firewall configuration uses two ISA Server 2000 machines, one as the Internet edge firewall and the other as the corporate LAN edge firewall. The front-end ISA Server 2000 firewall has an interface directly connected to the Internet and an interface on the perimeter network between the firewalls. The back-end ISA Server 2000 firewall has an interface on the perimeter network and an interface on the protected, corporate LAN.

The advantages of this configuration include:

A single firewall system; this reduces the training overhead and the probability of a configuration error
Sophisticated application layer filtering protects hosts on the perimeter network and the corporate network
You can leverage Web Proxy chaining and firewall chaining to significantly increase access control from perimeter network servers and users on the internal network. This prevents attackers from using compromised servers on the perimeter network as a launch point for outbound attacks from the perimeter network
Granular outbound user/group based access control for hosts on both the corporate network and the perimeter network
Excellent support for highly secure VPN passthrough, allowing access to protected resources on the corporate network

Figure F shows the topology for the ISA Server 2000 front-end back-end firewall configuration.

Figure F:

ISA Server 2000 Application Layer Filtering Web Proxy in the Perimeter Network

Some organizations already have an existing firewall infrastructure that includes front-end and back-end firewalls. These organizations have a large investment in their current firewall infrastructures and prefer to leave them intact. You can still leverage ISA Server 2000’s application layer filtering features by making the ISA Server an application layer filtering proxy. This ISA Server 2000 proxy can be placed on the perimeter network between the front-end and back-end third party packet filtering firewalls or you can place the ISA Server 2000 application layer proxy on the corporate network.

Advantages of the application layer filtering proxy configuration include:

The ability to leave the current firewall infrastructure intact; you can “drop in” the ISA Server 2000 application layer filtering proxy virtually anywhere
The third party front-end and back-end packet filtering firewalls can pass packets at high speed while allowing the ISA Server 2000 to provide a very high level of security for communications passed through its application layer inspection mechanisms
A hardened ISA Server 2000 proxy can be placed on the perimeter network segment to reduce the attack surface
In reverse Web Proxy scenarios, the ISA Server 2000 application layer filtering proxy can forward user credentials across the back-end firewall to pre-authenticate remote users

Figure G shows the topology of the application layer filtering proxy configuration.

Any of these ISA Server 2000 network topologies can be used to support SSL to SSL bridging.

Configuring ISA Server 2000 to Perform SSL to SSL Bridging

You can configure a Web site to use SSL to SSL bridging without purchasing additional software. Microsoft Windows 2000 Servers and Windows Server 2003 include Microsoft Certificate Services, which allows you to deploy certificates required to create the SSL to SSL bridging configuration.

In the following walkthrough, we assume you have the following already configured on your network:

An Active Directory domain controller
An enterprise Certification Authority (enterprise CA)
A Windows 2000 or Windows Server 2003 machine running ISA Server 2000 with Service Pack 1 and Feature Pack 1 installed
The ISA Server 2000 machine is a member of the same Active Directory domain as the enterprise CA

We will perform the following procedures to publish a Web site using SSL to SSL bridging:

Obtain a Web Site Certificate
Export the Certificate to a File
Copy the Certificate to the ISA Server 2000 Firewall and import it into the ISA Server 2000 firewall’s machine certificate store
Configure the Incoming Web Requests Listener
Create the Web Publishing Rule
Create the HOSTS file entry

Note:

The procedures demonstrated use a mix of Windows 2000 and Windows Server 2003 machines to highlight the interoperability of these operating systems in creating an SSL to SSL solution. The procedures are virtually the same for both operating systems.

Obtain a Web Site Certificate

The Web site certificate can be bound to any IIS or Exchange Server service supporting SSL/TLS encryption. In the following example, we will request a Web site certificate for the default Web site. You can use the same procedures when obtaining a certificate for any other IIS or Exchange mail service (NNTP, SMTP, IMAP4 and POP3). The only difference is that you access the Certificate Request Wizard from a different service’s Properties dialog box.

The following procedure describes how to submit a request to an online certification authority. The online certification authority is an enterprise CA belonging to the same domain as the machine requesting the certificate, or a domain that the machine trusts.

After completing the certificate request, a Web site certificate is placed into the machine’s Personal\Certificates certificate store and the certificate is bound to the Web site. Any certificate located in the machine’s Personal/Certificates certificate store that is able to provide server authentication can be bound to the IIS or Exchange service. This is also the certificate you will bind to the ISA Server 2000 Incoming Web Requests Listener, which allows the ISA Server 2000 firewall to impersonate the Web server on the internal network.

Perform the following steps to create the online request and install the certificate:

1. In the Internet Information Service (IIS) Manager console, the Default Web Site and click the Properties command (figure 1).

Figure 1

2. In the Default Web Site Properties dialog box, click on the Directory Security tab. On the Directory Security tab, click on the Server Certificate button in the Secure communication frame (figure 2).

Figure 2

3. Read the information on the Welcome to the Web Server Certificate Wizard page and click Next (figure 3).

Figure 3

4. On the Server Certificate page, select the option that fits your requirements (figure 4). You have the following options:

Create a new certificate

This allows you to request a new certificate for the SMTP virtual server. If you do not already have a certificate, this is the option you should select.

Assign an existing certificate

If you already have a certificate for this virtual server, you can bind the certificate to the SMTP virtual server using this option. The certificate must already be installed into the machine’s certificate store

Import a certificate from a Key Manager backup file

If you have a certificate from an IIS 4.0 site, you can import the certificate from a Key Manager backup file using this option

We do not yet have a certificate for the Default Web Site, so we will request a new certificate. Select the Create a new certificate option and click Next.

Figure 4

5. Select the Send the request immediately to an online certificate authority option on the Delayed or Immediate Request page (figure 5). This allows the Wizard to automatically forward the request to the enterprise CA. The Prepare the request now, but send it later option creates a text file you can submit to any CA and obtain a certificate. You must then manually install the certificate after receiving it. Click Next.

Figure 5

6. Enter a “friendly name” in the Name text box on the Name and Security Settings page (figure 6). This is a descriptive name only and does not affect functionality of the certificate. Chose a bit length for the encryption key. The longer the bit length, the more processor intensive the encryption process will be. Use a value of 1024. Click Next.

Figure 6

7. Type an Organization and Organizational unit name in the text boxes provided on the Organizational Information page (figure 7). Click Next.

Figure 7

8. The Your Site’s Common Name page is very important and the correct Common name must be entered into the text box (figure 8). The common name is the name the client application uses to connect to the site. For example, if the common name on the certificate is www.domain.com, then the client must connect to the service using this name.

This name must resolve to the IP address listening for the service using this certificate. In our current example, the SMTP service is listening on 131.107.0.3. The fully qualified domain name www.domain.com must resolve to 131.107.0.3 so that the client can send the request to the correct IP address on which the virtual SMTP server is listening.

Note that the client software must be configured to use the FQDN of the service and not the IP address. The client needs to match the name on the certificate the service presents to it with the name you configured the client to connect to. You will see an error message on the client if these names do not match.

Enter the correct FQDN in the Common name text box and click Next.

Figure 8

9. Enter the State/province and City/locality on the Geographical Information page (figure 9). Use the drop down list box to select a Country/Region. Click Next.

Figure 9

10. Your enterprise CA appears in the Certification authorities drop down list box on the Choose a Certification Authority page (figure 10). If you have more than a single enterprise CA on the network, you can choose one of them from the list. In this example we have a single enterprise CA, so we will go with the default. Click Next.

Figure 10

11. Review the information on the Certificate Request Submission page (figure 11). Confirm that the Common Name (listed as the Issued To entry on this page) matches the name users will use to access this virtual SMTP server. Click Next.

Figure 11

12. Click Finish on the Completing the Web Server Certificate Wizard page (figure 12).

Figure 12

13. Click OK in the Default Web Site Properties dialog box.

The service now has a server certificate bound to it and can be configured to use TLS to protect credentials and data between itself and the mail or Web client.

Export the Certificate to a File

The ISA Server 2000 firewall performs SSL to SSL bridging and protects the connection from the remote OWA client end to end. End to end protection is important because the implicit assumption made by the remote host is that if the initial connection requires a secure link, then the entire transaction is protected by an encrypted link.

SSL to SSL bridging allows the external Web browser to create an encrypted SSL link with the external interface of the ISA Server 2000 firewall. The ISA Server firewall decrypts the packets and inspects them for validity and drops invalid packets. The ISA Server 2000 firewall then establishes a second SSL session between its own internal interface and Published Web site or Exchange Server, re-encrypts the packets and forwards them to the Exchange server.

The ISA Server 2000 firewall impersonates the Web site by presenting the Web site’s certificate to the remote Web browser client. The name of the Web site is contained in the certificate; this is the mechanism of impersonation.

Perform the following steps to export the Web site certificate from the OWA server:

Click Start, point to Administrative Tools and click on Internet Information Services. In the Internet Information Services (IIS) Manager console (figure 13), expand the Web Sites node and click on the Default Web Site entry. Right click on Default Web Site and click Properties.

Figure 13

Click on the Directory Security tab in the Default Web Site Properties dialog box (figure 14). Click on the View Certificate button.

Figure 14

In the Certificate dialog box, click on the Details tab (figure 15). Click on the Copy to File button.

Figure 15

Click Next on the Welcome to the Certificate Export Wizard page (figure 16).

Figure 16

Select the Yes, export the private key option on the Export Private Key page (figure 17). Click Next.

Figure 17

On the Export File Format page (figure 18), select the Personal Information Exchange – PKCS #12 (.PFX) option. Put a checkmark in the Include all certificates in the certification path if possible checkbox. Remove the checkmarks from the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) and Delete the private key if the export is successful checkboxes.

The enable strong protection option requires user intervention before the certificate can be used to establish a connection. The server on which the certificate is installed cannot perform the required actions. That is why you must not select that option. You do not want to delete the private key from the OWA site, because you want to keep the key there for backup and the private key is required so that you can perform SSL to SSL bridging.

Click Next.

Figure 18

On the Password page, type a password and confirm the password. This password protects the private key from being stolen by anyone who might obtain the exported file (figure 19).

Figure 19

On the File to Export page (figure 20), type a path and file name for the certificate file. Remember where you stored the file because you will need to copy it to the ISA Server machine in the DMZ. Click Next.

Figure 20

Review your settings on the Completing the Certificate Export Wizard page (figure 21) and click Finish.

Figure 21

Click OK on the Certificate Export Wizard dialog box that informs you the export was successful (figure 22).

Figure 22

Close the Certificate dialog box (figure 23).

Figure 23

Close the Default Web Site Properties dialog box (figure 24).

Figure 24

Copy the Certificate to the ISA Server 2000 Firewall and Import it into the ISA Server 2000 Firewall’s Machine Certificate Store

The next step is to copy the Web site certificate file from the Web server to the ISA Server 2000 firewall. The Web site certificate is imported into the ISA firewall’s machine certificate store. Next, the imported certificate is bound to the Incoming Web Requests listener.

Perform the following steps to import the OWA server’s Web site certificate into the ISA Server’s machine certificate store:

1. Click Start and click the Run command. Type mmc in the Open text box and click OK. In the Console 1 console, click the File menu and click the Add/Remove Snap-in command (figure 25).

Figure 25

2. Click the Add button in the Add/Remove Snap-in dialog box (figure 26).

Figure 26

3. Click on the Certificates entry in the Available Standalone Snap-in list on the Add Standalone Snap-in dialog box (figure 27). Click Add.

Figure 27

4. Select the Computer account option on the Certificates snap-in page (figure 28). Click Next.

Figure 28

5. On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish (figure 29).

Figure 29

6. Click Close on the Add Standalone Snap-in page (figure 30).

Figure 30

7. Click OK on the Add/Remove Snap-in dialog box (figure 31).

Figure 31

8. Right click on the Personal node in the left pane of the console, point to All Tasks and click Import (figure 32).

Figure 32

9. Click Next on the Welcome to the Certificate Import Wizard (figure 33).

Figure 33

10. Click the Browse button and locate the certificate file. Click Next after the file path and name appear in the File name text box (figure 34).

Figure 34

11. On the Password page, type the password for the file (figure 35). Do not put a checkmark in the Mark this key as exportable. This will allow you to back up or transport your keys at a later time checkbox. You should not do this because this machine is a bastion host with an interface in a DMZ or on the Internet and thus could be compromised. The compromiser might then be able to steal the private key from this machine if it is marked as exportable.

Click Next.

Figure 35

12. On the Certificate Store page (figure 36), confirm that the Place all certificates in the following store option is selected and that it says Personal in the Certificate store box. Click Next.

Figure 36

13. Review the settings on the Completing the Certificate Import page and click Finish (figure 37).

Figure 37

14. Click OK on the Certificate Import Wizard dialog box informing you the import was successful (figure 38).

Figure 38

15. You will see the Web site certificate and the CA certificate in the right pane of the console. The Web site certificate has the FQDN assigned to the Web site. This is the name external users use to access the OWA site. The CA certificate must be placed into the Trusted Root Certification Authorities\Certificates store so that this machine will trust the Web site certificate installed on it.

Double click on the Web site certificate in the right pane of the console (figure 39).

Figure 39

16. Click on the Certification Path tab on the Certificate dialog box (figure 40). You might notice the red “x” on the CA certificate node. This indicates that this machine does not trust the CA issuing the Web site certificate. You will only see this happen when the ISA Server 2000 firewall is not a member of the same domain as the enterprise CA issuing the certificate. In order to use this certificate to perform SSL to SSL bridging, this machine must trust the CA that issued the Web site certificate.

If the ISA Server 2000 firewall is not a member of the same domain as the enterprise CA issuing the certificate, then perform the following steps to import the root CA certificate into the ISA Server 2000 firewall’s Trusted Root Certification Authorities Store. You can move to the next section if the ISA Server 2000 firewall belongs to the same domain as the enterprise CA issuing the Web site certificate.

Close the Certificate dialog box.

Figure 40

17. Right click on the CA certificate in the right pane of the console and click the Copy command (figure 41).

Figure 41

18. Expand the Trusted Root Certification Authorities node and click the Certificates node (figure 42). Right click on the Certificates node and click the Paste command. This pastes the CA certificate into the Trusted Root Certificate Authorities\Certificates store and allows this machine to trust certificates issued by this CA.

Figure 42

19. Click the Refresh button refresh the display. You should see the certificate appear in the right pane of the console (figure 43). If you do not see the CA certificate in the right pane of the console, repeat the procedure

Figure 43

20. Return to the Personal\Certificates node in the left pane of the console and double click on the Web site certificate. In the Web site certificate’s Certificate dialog box, click on the Certification Path tab (figure 44). Notice that the red “x” no longer appears on the CA certificate. Click OK on the Certificate dialog box.

Figure 44

21. Close the mmc console (figure 45). You may want to save this console with the name of certificates and store it in the Administrative Tools menu.

Figure 45

Configure the Incoming Web Requests Listener

The next step is to configure the Incoming Web Requests listener to use this certificate to impersonate the Web site. The Incoming Web Requests listener listens for inbound requests on TCP port 80 and TCP port 443 (for secure SSL connections) and forwards these to the Web Proxy service. The Web Proxy service then compares the elements of the request with settings in Web Publishing Rules. If one of the Web Publishing Rules matches parameters in the request, then the Web Proxy service forwards it to the published Web server on the internal network.

You must bind the Web site certificate to the Incoming Web Requests listener before creating the Web Publishing Rule. Perform the following steps to create the binding:

Open the ISA Management console. Click on the server name in the left pane of the console and then right click it. Click the Properties command.
In the server Properties dialog box, click on the Incoming Web Requests tab. Select the Configure listeners individually per IP address option and click Add (figure 46).

Figure 46

Set the following options in the Add/Edit Listeners dialog box (figure 47),:

Server

Select your server name from the list. If this ISA Server is not a member of an enterprise array, your only choice will be the name of the local server

IP Address

Select the IP address on which you want the listener to listen. Make sure this address resolves to the IP address used by the FQDN listed in the common name on the certificate. This is also the FQDN the external users will use to access the Web site from external network locations

Display Name

Give a name to the listener. In this example we call it primary ext since this is the primary address on the external interface of the ISA Server 2000 firewall.

Use a server certificate to authenticate to web clients

Place a checkmark in this checkbox to assign the Web site certificate to the listener.

Click the Select button to select the Web site certificate.

Figure 47

Select the Web site certificate from the list in the Select Certificate dialog box (figure 48). In this example we have a single certificate to choose. This is the Web site certificate that we imported into the ISA Server firewall’s machine certificate store. Click on the certificate and then click OK.

Figure 48

In the Add/Edit Listeners dialog box, put a checkmark in the Basic with this domain checkbox. An ISA Server Configuration dialog box appears, warning that you should use SSL to protect user credentials when using basic authentication because the credentials are passed in clear text. Click Yes to affirm your understanding.

Figure 49

Click the Select domain button. In the Select Domain dialog box, type the name of your user domain and click OK.

Figure 50

Click OK in the Add/Edit Listeners dialog box.

On the server Properties dialog box, put a checkmark in the Enable SSL listeners check box. Click OK in the SSL Listeners dialog box that informs you that you must bind a certificate to the listener before it will accept inbound SSL connections.

Figure 51

Click Apply. Select the Save the changes and restart the service(s) option and click OK.
Click OK in the server Properties dialog box.

Configure the Destination Set for the Web Publishing Rule

Your next task is to configure a Destination Set to use in the OWA Web Publishing Rule. This Destination Set includes the FQDN used by the external users to access the OWA Web site. This is also the common name used in the OWA Web site certificate. This Destination Set will contain three entries, one for each of the folders required to access the OWA Web site.

Perform the following steps to create the Destination Set:

Open the ISA Management Console, expand your server name and then expand the Policy Elements node. Click on the Destination Sets node and then right click on it. Point to New and click on Set (figure 52).

Figure 52

In the New Destination Set dialog box, type a name for the Destination Set in the Name text box. In this example we’ll name it Web Site. Type a description in the Description text box. In this example we’ll use the description Published Web Site Destination Set. Click Add.

In the Add/Edit Destination dialog box, select the Destination option and type in the FQDN for the Web site. In this example, the FQDN used to access the OWA Web site is www.domain.com. Click OK.

Figure 53

Click OK in the New Destination Set dialog box.

Figure 54

Create the Web Publishing Rule

Perform the following steps to create the Web Publishing Rule:

Open the ISA Management console, expand your server name and expand the Publishing node in the left pane of the console. Click on the Web Publishing Rules node and then right click on it. Point to New and click on Rule.

Figure 55

Give the rule a name on the Welcome to the New Web Publishing Rule Wizard page. In this example, we’ll call the rule Web Server. Click Next.

On the Destination Sets page, select the Specified destination set option on the Apply this rule to drop down list. Select the Web Site destination set from the Name drop down list box. Click Next.

Figure 56

On the Client Type page you can control who can use this rule. Select the Any request option. Click Next.

On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option. In the text box under this option, type the FQDN of the Web site that is the same as the FQDN listed in the common name of the certificate and the name the external users use to access the site.

This prevents you from receiving sever error 500 messages and certificate mismatch problems. The critical component to making the redirect work is a split DNS infrastructure or a HOSTS file entry for the FQDN of the Web site resolving to the internal address of the Web site.

Do not change any of the entries for HTTP, SSL or FTP bridging. Click Next.

Figure 57

Review your settings on the Completing the New Web Publishing Rule Wizard page and click Finish.

Double click on the new Web Publishing Rule in the right pane of the console. In the Web Server Properties dialog box, click on the Action tab. On the Action tab, put a checkmark in the Allow delegation of basic authentication credentials checkbox if your Web site requires authentication. Click Apply.

Figure 58

Click the Bridging tab in the Web Server Properties dialog box. Confirm that the Redirect SSL requests as option is set to SSL requests (establish a new secure channel to the site). This allows SSL to SSL bridging.

Place a checkmark in the Require secure channel (SSL) for published site checkbox. This forces the external client connecting to the Web site to use SSL. If the external Web client does not use SSL, the request will be denied by the Web Publishing Rule.

Place a checkmark in the Require 128-bit encryption checkbox. This forces all OWA Web site clients to use 128-bit encryption. All Microsoft clients support 128-bit encryption, so you should enable this option.

Click Apply, and then click OK.

Note:
Do not enable the Use a certificate to authenticate to the SSL Web server option. This option is used only if you require certificate-based user authentication at the Web site.

Figure 59

Create the HOSTS file entry

There are two methods you can use so that the ISA Server firewall redirects www.domain.com to the internal network. You can create a split DNS or you can use a HOSTS file located on the firewall. The HOSTS file is simple to create and you can use it to support your Web publishing rule while putting your split DNS infrastructure together.

Perform the following steps to create the HOSTS file on the ISA Server:

Open Windows Explorer and navigate to \WINDOWS\system32\drivers\etc directory and open the hosts file.
In the Open With dialog box, select Notepad and click OK.
The hosts file is opened in Notepad. Put a line at the end of the hosts file that resolves the name in the redirect to the IP address that can reach the OWA server on the internal network. For example, if the firewall in front of the OWA server on the internal network is performing reverse NAT to publish the internal OWA site, and the redirect is owa.internal.net, then you would put in the following entry:

10.0.0.2 www.domain.com

Where “10.0.0.2” is the IP address of the OWA server machine on the internal network. Make sure you press ENTER after you put this line into the hosts file so that there is an empty line at the end of the file.

Close Notepad and click OK to save the changes made to the file.

Summary

Traditional packet filtering firewalls use source and destination addresses and port numbers to control inbound and outbound access into and out of the corporate network. Most advanced packet filtering firewalls can examine the state of a connection to determine its validity. Application layer aware firewalls can perform stateful inspection of application layer data and commands and block application specific attacks at the perimeter. Attackers can still hide application layer attacks inside an SSL tunnel because the firewall is unable to statefully inspect commands and data hidden inside an encrypted SSL tunnel. ISA Server 2000 firewalls are able to decrypt the encrypted packets, inspect them for valid commands and data, and then re-encrypt valid packets and send them to the secure SSL Web server on the corporate network. This SSL to SSL bridging allows ISA Server 2000 to provide a unique level of protection for secure Web servers located on the corporate network.