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.