The Select Rule Action Page - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

next section where we focus on secure SSL Web Publishing Rules.

To start the Web Server Publishing Rule Wizard, open the Microsoft Internet Security and Acceleration Server 2004 management console, and expand the server name. Click the Firewall policy node, and click the Tasks tab. On the Tasks tab, click the Publish a Web Server link.

You'll first encounter the Welcome to the New Web Publishing Rule Wizard page. On this page, you'll enter a name for the rule in the Web publishing rule name text box. Click Next.

The Select Rule Action Page

On the Select Rule Action page, you have the option to Allow or Deny connections to the published Web server. Note that the default option on the Select Rule Action page is Allow. This is in contrast to the default action on the Access Rule Wizard, where the default action is Deny. Most Web Publishing Rules will allow access to Web sites and specific paths within those Web sites. However, you can create Web Publishing Rules that deny access to fine-tune Web Publishing Rules that allow access. Choose the Allow option and click Next. Figure 8.1 shows the default option on the Select Rule Action page.

Figure 8.1: The Select Rule Action Page

The Define Website to Publish Page

On the Define Website to Publish page, you provide information about the Web site on the ISA firewall Protected Network. As you'll see in Figure 8.2, you have the following options on this page:

Computer name or IP address

Forward the original host header instead of the actual one (specified above)

Path

Site

Figure 8.2: The Define Website to Publish Page

In the Computer name or IP address text box, enter either the IP address of the fully-qualified domain name of the Web server or the ISA firewall Protected Network. If you use a FQDN, make sure that the ISA firewall is able to resolve that name to the Web server's IP address on the corporate network and not the IP address on the external interface of the ISA firewall. This is a very common error among ISA firewall administrators.

You can ensure that the name is properly resolved to the private address of the Web server by creating a split DNS infrastructure or by using a HOSTS file entry on the ISA firewall.

One of the primary advantages of using a FQDN in the Computer name or IP address field is that the Web site name shows up in the URL field in the ISA firewall's Web Proxy log. If you use an IP address, only the IP address of the published server will appear in this field and make log analysis more difficult to perform efficiently.

We will discuss the virtues of the split DNS infrastructure and how to create one later in this chapter. Figure 8.2 shows the options on the Define Website to Publish page.

The Forward the original host header instead of the actual one (specified above) is an interesting option because its exact meaning is not entirely clear. What it's supposed to mean is that instead of the host header value in the Computer name or IP address text box being sent to the published server, the actual host header in the request sent by the external user is forwarded to the published Web server. This is an important issue if you are hosting multiple Web sites on a single Web server and differentiate the Web sites by using different host headers for each one.

You can see the effects of forwarding, or not forwarding, the original host headers in figures 8.3, 8.4, and 8.5. In Figure 8.3 you can see the host headers as seen on the external interface of the ISA firewall from a client connection request for www.msfirewall.org. The HTTP: Host =www.msfirewall.org host header appears in the network monitor trace.

Figure 8.3: HTTP Headers Seen on the External Interface of the ISA Firewall

When the Web Publishing Rule is configured to not forward the original Host header, and an IP address (or an alternate name) is used in the Computer name or IP address text box, you will see on the Network Monitor trace, in Figure 8.4, taken on the published Web server that the Host header entry is HTTP: Host =10.0.0.2, which isn't the Host header contained in the original client address. It's the entry we put in the Computer name or IP address text box. Figure 8.4 shows an example of HTTP headers seen on the Published Web Server when the original Host header is not forwarded.

Figure 8.4: HTTP Headers Seen on the Published Web Server when Original Host Header is not Forwarded

However, when we enable Forward the original host header instead of the actual one (specified above), Figure 8.5 shows what appears on the published Web server. In this case, the Network Monitor trace shows that the host header seen on the Web server is HTTP: Host =www.msfirewall.org. See Figure 8.5 for headers seen on the published Web server when the original Host header is forwarded.

Figure 8.5: HTTP Headers Seen on the Published Web Server when Forwarding the Original Host Header

In the Path text box, you enter the paths you want accessible on the published Web server. You can enter a name of a specific file or folder, or you can allow access to all files and folders within a folder by using the /* wildcard. This option allows you to restrict access to specified files and folders. Although this wizard page only allows you to enter a single path, we'll see later that we can enter the Properties dialog box of the Web Publishing Rule and create additional paths and even path redirections.

The Site box isn't a text box, so you can't enter anything in it. Instead, it shows you the URL that will be accessible on the published Web site..

In this example, we entered 10.0.0.2 for the Computer name or IP address and chose to forward the original host header. We entered a path of /*. Click Next.

The Public Name Details Page

On the Public Name Details page, you enter information about what FQDNs or IP addresses users will use to connect to the published Web site via this Web Publishing Rule. You have the following options on this page:

Accept requests for

Path (optional)

Site

The Accept requests for drop-down list provides you with two choices: Any domain name and This domain name (type below). If you choose Any domain name, any requests for a domain name or IP address are accepted by the Web listener for this rule. This is a very poor selection because it can potentially expose you to viruses or worm attacks, or attacks from malicious users.

For example, some prevalent worms will send requests to the TCP port 80 or to bogus domain names (such as www.worm.com) to the IP address used by the Web listener for this rule. If you select Any domain name, then the Web listener will accept these as valid requests and continue processing them. This is in spite of the fact that you are not hosting any resources for the bogus domain name the worm or the malicious user uses to access the IP address the Web listener is using on the external interface of the ISA firewall.

A better option, and the one we recommend that you always use for your Web Publishing Rules, is This domain name (type below). When you choose this option, you enter the exact domain name that must be included in the users request to the Web listener. If you want to accept requests only for the www.msfirewall.org domain, then incoming requests for http://1.1.1.1 or http://www.worm.com will be dropped because they do not match the domain name you want this rule to apply to.

When you select This domain name (type below), you must enter the domain name you want this rule to accept in the Public name text box. In this example, we entered the FQDN www.msfirewall.org. The Public Name Details Wizard page allows you to enter only a single domain name, but you can add more domain names after the wizard is completed. However, we highly recommend that you use a single domain name per Web publishing rule.

The Path (optional) text box allows you to restrict the path(s) that users can access via this Web Publishing Rules. You might want to allow users access to only specific directories on your Web site and not to the entire site. Although you can only enter a single path on the Public Name Details page (Figure 8.6), you can enter additional paths after the wizard is completed, in the Properties dialog box for this rule.

Figure 8.6: The Public Name Details Page

The Select Web Listener Page and Creating an HTTP Web Listener

You assign a Web listener to the Web Publishing Rule on the Select Web Listener page. A Web listener is a Network Object you use in Web Publishing Rules. The Web listener 'listens' on an interface or IP address that you choose for incoming connections to the port you define. For example, if you create a Web publishing rule that allows HTTP public access to the www.msfirewall.org site, you would create a Web listener that listens on the external interface of the ISA firewall using the IP address that external users resolve www.msfirewall.org.

You have two options on the Select Web Listener page if there are listeners already configured on the ISA firewall:

Edit

New

Edit allows you to configure existing Web listeners, and New allows you to create a new Web listener. In this example, there are no listeners yet created on the ISA firewall, so we click New.

On the Welcome to the New Web Listener Wizard page, enter a name for the Web listener in the Web listener name text box. In this example, we'll name the Web listener HTTP Listener (since we only have a single IP address bound to the external interface; if there were multiple addresses, we could add the number in the last octet to the listener definition to make it easier to identify). Click Next.

On the IP Addresses page, select the Networks and IP addresses on those Networks that you want the listener to listen on. Recall that each interface on the ISA firewall represents a Network, and all IP addresses reachable from that interface are considered part of that Network. The Web listener can listen on any Network defined on the ISA firewall.

In this example, we want to accept incoming connections from Internet users, so we'll select the External network by putting a checkmark in its checkbox. At this point, the Web listener will accept connection requests to all IP addresses bound to the external interface of the ISA firewall. We recommend that if you have multiple IP addresses bound to an interface that you configure the Web listener to use only one of those addresses. This provides you greater flexibility because you can customize the properties of each listener. If you allow the listener to listen on all IP addresses on the interface, then a single set of listener properties will be assigned to it.

Click Addresses on the IP Addresses page, as shown in Figure 8.7.

Figure 8.7: The IP Addresses Page

On the Network Listener IP Selection page (Figure 8.8) you have three options:

All IP addresses on the ISA Server computer that are in the selected network

The default IP address on the ISA Server computer in the selected network

Specified IP addresses on the ISA Server computer in the selected network

Figure 8.8: The External Network Listener IP Selection Dialog Box

All IP addresses on the ISA Server computer that are in the selected network is the default and is the same as checking the checkbox on the previous page without making any customizations. This option allows the listener to listen on all addresses bound to the interface representing the Network(s) you select. When you select more than one Network, the Web listener will listen on IP addresses bound to each of the Networks you select.

The default IP address on the ISA Server computer in the selected network allows the listener to accept connections to the primary IP address bound to the Network interface. The primary address is the first address on the list of addresses bound to the Network interface. This is also the interface that is used for connections leaving that interface.

Specified IP addresses on the ISA Server computer in the selected network allows you to select the specific IP addresses you want the listener to use. The available IP addresses for the Network appear in the Available IP addresses section. You select the IP address you want the Web listener to use, and click Add; it then appears in the Selected IP Addresses section.

The example in Figure 8.8 demonstrates the Network centric nature of the ISA firewall. Before we selected an address, both 172.16.0.1 and 192.168.1.70 were in the Available IP Addresses list. These two addresses are actually bound to two different adapters. The 192.168.1.70 address is bound to the external interface (the one with the default gateway configured on it), and the 172.16.0.1 address is bound to a DMZ interface on the ISA firewall. The reason why both these addresses are included is that the default External Network includes all IP addresses that are not defined as part of a Network. Since we haven't defined the DMZ Network, the address bound to the DMZ interface is part of the default External network.

In Figure 8.8, we've selected the IP address bound to the external interface of the ISA firewall. Click OK. Then click Next on the IP Addresses page.

The Port Specification page in Figure 8.9 allows you to define the TCP port on which the Web listener accepts incoming connections. The default port is TCP port 80.

Figure 8.9: The Port Specification Page

You can change this port to any port you like, as long as it does not collide with a socket already in use on the ISA firewall.

You also have the option to enable an SSL listening port on the Web listener. We recommend that you configure your HTTP and SSL listeners separately. This is a new feature in the 2004 ISA firewall. We will cover the details of configuring SSL listeners in the next section of this chapter.

In the example in Figure 8.9, we use the default port, and click Next.

Click Finish on Completing the New Web Listener Wizard page. The details of the Web listener appears on the Listener properties page. We can now click Edit to customize several aspects of the Web listener.

Click Edit, and then click the Preferences tab (Figure 8.10). Here you can configure the Authentication and Advanced properties for the listener.

Figure 8.10: The Preferences Tab

Click Authentication, and you'll see the authentication options available for the Web listener in the Authentication dialog box (Figure 8.11). The default authentication method is Integrated. Table 8.1 describes each of the authentication methods available for Web listeners and a short description of the important characteristics of each method.

Figure 8.11: The Authentication Dialog Box

Authentication options are shown in Figure 8.11.

The authentication option you select applies only if you limit access to the Web Publishing Rule to a user or group. If you allow All Users access to the Web Publishing Rule, then the authentication option is ignored. These authentication options apply only to authentication performed by the ISA firewall itself, not to authentication that may be required by the published Web site.

All authentication methods except RADIUS require that the ISA firewall be a member of a domain. This is not a significant issue unless you have a back-to-back firewall configuration where the front-end firewall is an ISA firewall (the back-end firewall can be any kind of firewall you like, including ISA firewalls). If the ISA firewall is on the front-end and you want to authenticate users at the front-end server, we recommend that you use only RADIUS authentication. When the ISA firewall is on the back-end, we always recommend that you make the firewall a member of the Active Directory domain so that you can leverage the many security advantages inherent in domain membership. However, if there are political reasons why the back-end ISA firewall cannot be made a member of the domain, you can still leverage RADIUS authentication in the scenario, too.

Put a checkmark in the Require all users to authenticate checkbox if you require authentication for all Web Publishing Rules that will use this listener.

Click RADIUS Servers to select or add a RADIUS server for RADIUS authentication.

Click Select Domain to set a default domain if you wish to choose Basic authentication.

Click Configure, to the right of Configure OWA forms-based authentication, to customize the cookie parameters for the OWA connection. We will discuss this issue in more detail later in this chapter.

Click OK to close the Authentication dialog box. Click Advanced, in the HTTP Listener Properties dialog box. This brings up the Advanced Settings dialog box, as shown in Advanced Settings dialog box, you can set the Number of connections you want to support on the listener and the idle connection timeout for the listener. Click OK to close the Advanced Settings dialog box.

Figure 8.12: Tthe Advanced Settings Dialog Box

Click OK to close the HTTP Listener Properties dialog box and click Next on the Select Web Listener page.

The User Sets Page

On the User Sets page (Figure 8.13) you configure whether authentication is required to access the Web server published by this Web Publishing Rule. The default settings is All Users, which means that authentication is not required to access the Web server published by this Web Publishing Rule. Click the Add button if you want to require authentication. You will be presented with the Add Users dialog box where you can select the User Set representing the users you want the rule to apply to.

Figure 8.13: The User Sets Page

Note that the All Users option only means that authentication is not required when the Web listener is not configured to require authentication. To configure the Web Publishing Rule to allow the user of anonymous credentials, use the All Users user set.

We will discuss User Sets, how to create them and how to use them in Chapter 10. Click Next on the User Sets page and then click Finish on the Completing the New Web Publishing Rule Wizard page.

The Web Publishing Rule Properties Dialog Box

The new Web Publishing Rule appears in the Firewall Policy list. Right click the Web Publishing Rule and click Properties. The Web Publishing Rules Properties dialog box has twelve tabs:

General

Action

From

To

Traffic

Listener

Public Name

Paths

Bridging

Users

Schedule

Link Translation

Let's look at the options in each of these tabs. You'll find that there are many options on these tabs that were not exposed in the Web Publishing Rule Wizard.

The General Tab

On this tab you can change the name of the Web Publishing Rule by entering a name in the Name text box. You can also enter a description for the rule in the Description (optional) text box. You can enable or disable the Web Publishing Rule by enabling or disabling the Enable checkbox, as shown in Figure 8.14.

Figure 8.14: The General Tab.

Action

On the Action tab (Figure 8.15) you either Allow or Deny access to the site configured in the Web Publishing Rule. You also have the option to Log requests matching this rule. If you find that your log files are getting too large, and the site being accessed by the rule isn't of any particular interest to you, then you might consider not logging requests handled by this rule. However, we do not recommend that you disable logging for any publishing rules because most of these rules represent connections from untrusted Networks.

Figure 8.15: The Action Tab

Click Apply to save the changes you make on this tab.

From

On the From tab, configure locations where you want the Web Publishing Rule to accept connections for the Published Site. The default location is Anywhere, which means that any host that can reach the IP address or addresses used for the Web listener can access this Web Publishing Rule.

You can limit access to this Web Publishing Rule by clicking Anywhere and then clicking Remove. After removing the Anywhere entry, click Add. In the Add Network Entities dialog box, click the folder that contains the Network Object you want to allow access to the Web Publishing Rule.

There is also the option to fine-tune access to the rule by setting exceptions in the Exceptions frame. For example, you might want to allow access to the Web Publishing Rule to all Networks except for hosts on the Network where the published server is located. This is generally a good idea because you do not want corporate network hosts looping back through the ISA firewall to connect to resources located on the corporate network.

Click Apply on the From page, Figure 8.16, after making your changes.

Figure 8.16: The From Tab

To

The To tab is one of the most important tabs in the Properties dialog box. The reason for this is that the entry you put in the Server text box defines the host name in the URL that Web Publishing Rule sends to the published Web site. The entry you put in the Server text box replaces the host header that was included in the original client request sent to the ISA firewall. If you don't want the ISA firewall to replace the entry in the host header with the entry in the Server text box, then put a checkmark in the Forward the original host header instead of the actual one (specified above) checkbox.

Another important option on the To tab is the ability to specify how the ISA firewall proxies the requests to the server listed in the Server text box. You have two options:

Requests appear to come from the ISA Server computer

Requests appear to come from the original client

Requests appear to come from the ISA Server computer is useful when you don't want to make the published Web server a SecureNAT client. One of the primary disadvantages of the SecureNAT client configuration is that the entire routing infrastructure must be aware that the ISA firewall should be the gateway to the Internet. Many organizations have an established routing infrastructure, and they don't want to make the ISA firewall the route of last resort for all hosts on the network. You can get around this problem by allowing the ISA firewall to replace the remote host's IP address with its own. When the published server returns its response, it only needs to know the route to the local interface on the ISA firewall. It doesn't need a route to the Internet and doesn't need to make the ISA firewall its default gateway.

Requests appear to come from the original client allows the ISA firewall to preserve the IP address of the remote host sending the request for published Web site resources. The advantage to this approach is that if you have log-reporting software on the Web server itself, you will be able to report on the actual IP addresses of the hosts connecting to the Web site. If you don't select this option, it will appear in the Web site's log files that all connections are coming from the ISA firewall's IP address.

One issue with this approach is that if you enable reverse proxy for the published Web site, you will notice a number of requests sourcing from the ISA firewall itself, and you might misinterpret this as the ISA firewall failing to preserve the IP address of the requesting host. This is not true, and there is no bug or problem with this ISA firewall software in this regard. The issue is that when performing reverse proxy, the ISA firewall serves the responses from its cache. However, the ISA firewall, in its role as reverse Proxy server, needs to check on the status of the objects on the Web site, and this status check generates requests from the ISA firewall's address to the published Web site, which subsequently appears in the Web site's logs.

For this reason and more, we prefer to perform Web site activity analysis on the ISA firewall's Web Proxy service logs instead of the Web site logs themselves. There are exceptions to this rule, but for sites that are public sites only and not accessed by internal users, the Web Proxy logs on the ISA firewall provide the most rich and most accurate information.

Options for the To tab are shown in Figure 8.17.

Figure 8.17: The To Tab

Traffic

On the Traffic tab, you'll see a list of protocols allowed by this Web Publishing Rule. The protocols are not configurable on this tab. Instead, the allowed protocols are determined by the protocol support set on the Web listener configured for this publishing rule.

Notify HTTP users to use HTTPS instead is disabled in this example because we are not using an SSL listener. When this option is available, it allows the ISA firewall to return an error page to the user accessing the Web site through the Web Publishing Rule showing that HTTPS, instead of HTTP, should be used. It's a common error for users to enter HTTP, instead of HTTPS, when accessing secure Web sites. Fortunately, it takes less than three seconds to resubmit the request by adding an 's' to the protocol in the request. Forcing users to enter the correct protocol also encourages users to use correct Internet hygiene.

Require 128-bit encryption for HTTPS traffic is also not available because this rule doesn't apply to SSL publishing. This option allows you to control the level of encryption security for SSL connections to the published Web site. All modern Windows clients support 128-bit encryption right out of the box, but there are outdated Windows clients and non-Windows clients that do not support 128-bit encryption, and you might want to block connections from these relatively unsecure clients.

Click Apply to save the changes you made on the traffic tab, as shown in Figure 8.18.

Figure 8.18: The Traffic Tab

Listener

On the Listener tab, you can view the characteristics of the listener currently in use by the Web Publishing Rule, and you can change the properties of the listener here, as well, by clicking Properties. You can also create a new Web listener by clicking New and then applying the new listener to this Web Publishing Rule.

If you have already created multiple Web listeners on this ISA firewall, you can change the listener used by the Web Publishing Rule by clicking the down arrow on the This rule applies to requests received on the following listener drop-down box.

Click Apply after you make changes on the Listener tab (Figure 8.19).

Figure 8.19: The Listener Tab

Public Name

The Public Name tab allows you to view and configure the names that can be used to access the Web server published via this Web Publishing Rule. In the Web Publishing Rule we created in this example, we chose the name www.msfirewall.org for the public name that can be used to access the Web server. If a request comes in on the Web listener used by this Web Publishing Rule for a FQDN that is different from this one, this rule will ignore the connection request. Note that if this Web listener is used by other Web Publishing Rules, the incoming request will be compared to the Public Name entries in those other Web Publishing Rules. If no Web Publishing Rule includes a Public Name that matches that in the Host header of the incoming Web request, the connection will be dropped.

Also, note that a single Web Publishing Rule can be used for multiple host names. The key to success is to make sure that each of these host names resolves to the IP address or addresses that the Web listener bound to this rule is listening on. For example, the Web listener for this rule might be listening on an IP address that resolves to both www.msfirewall.org and www.tacteam.net. If that is the case, then we could add www.tacteam.net to the Public Name list. However, this also means that the same Paths, Bridging, Users, Schedule, and other settings would be applied to the connections coming in to the www.tacteam.net Web site. This might not always be the case, and this is why we recommend that you create separate Web Publishing Rules for each site that you publish.

You can Add a new Public name to the list by clicking Add, and you can Remove or Edit a selected public name by clicking Edit and Remove.

Click Apply when you have made your desired changes to the Public Name tab, as shown in Figure 8.20.

Figure 8.20: The Public Name Tab

Paths

The Paths tab allows you to control how requests to different paths included in the requests are handled by the Web Publishing Rule. You'll notice in the path list that there are two columns: the External Path and the Internal Path column.

The External Path is the path in the request made by the user accessing the Web site through this Web Publishing Rule. For example, if a user enters the URL http://www.msfirewall.org/docs into the browser, then the external path is /docs. If a user enters the URL http://www.tacteam.net/graphics into the browser, then the external path is /graphics.

The Internal path is the path that the ISA firewall will forward the request to based on the entry for the External path. For example, suppose we set the External Path as /docs and the Internal Path as /publicdocuments. When the user enters the URL http://www.msfirewall.org/docs into the browser, and the ISA firewall's Web listener for this rule accepts the connection for the request, then the ISA firewall will forward the request to the site listed in the To tab to the path /publicdocuments. If the entry in the To tab is 10.0.0.2, then the ISA firewall forwards the request to the published Web server as http://10.0.0.2/publicdocuments.

Path redirection provides you a lot of flexibility in your Web publishing rules and allows you to simplify the paths external users use to access published resources without requiring you to change directory names on the published Web server.

If you want access to all the folders and files under a particular directory, enter the path using the /path/* format. If you want to allow access to a single file in a path, enter the path in the /path format. For example, if you want to allow access to all the files in the documents directory on the Web server, enter for the Internal path /documents/*. If you want to allow access to only the names file in the documents directory, then enter the path as /documents/names. An example of the Paths tab is shown in Figure 8.21.

Figure 8.21: The Paths Tab

Click Add to add a new path. In the Path mapping dialog box, enter an internal path for Specify the folder on the Web site that you want to publish. To publish the entire Web site, leave this field blank text box. Next, select either the Same as published folder or The following folder option, as shown in Figure 8.22. If external users enter the same path, select the Same as published folder. If the users will enter a different path, select The following folder and enter the alternate path in the text box.

Figure 8.22: The Path Mapping Dialog Box

A common desire among ISA firewall administrators is to redirect connections to the root of a Web site to the /Exchange folder on Outlook Web Access (OWA) Web sites. This is easy to do by using a path redirection on the Path tab. In this case, the external path is /* and the internal path is /Exchange\. Notice that you must use a backslash at the end of the path because there is already an entry for /Exchange/ after running the Mail Server Publishing Wizard (we'll talk more about the Mail Server Publishing Wizard later in this chapter). The Paths tab with this type of OWA configuration would look like that seen in Figure 8.24.

Figure 8.24: Mapping the OWA Web Site Root to the Exchange Folder

The reason why this works is because the OWA Web site is kind enough to help hapless users who don't understand the difference between UNC and HTTP paths. The OWA Web site will accept the backslash as a valid request and convert it on the fly to a forward slash. This allows you to use the Internal Path statement /Exchange\ and /exchange/* in the Path tab, where it would, otherwise, not be possible to do this if you had to enter forward slashes for both entries because the ISA firewall will not allow you to enter multiple path mappings that use the same path prefix. The OWA configuration is shown in Figure 8.24.

Another thing you can do with path statements is redirect to different servers. For example, take the following URLs:

www.msfirewall.org/scripts

www.msfirewall.org/articles

www.msfirewall.org/ids-ips

All three URLs point to the same FQDN and only differ in the path. You can create three Web Publishing Rules, each one using the same Public Name and each one including a different path configuration and a different server on the To tab. When a user makes a request using one of these three URLs, the request will be forwarded to the appropriate server based on the settings on the Public Name, Paths, and To tabs.

Bridging

The Bridging tab, as shown in Figure 8.25, allows you to configure port or protocol redirection for the Web Publishing Rule. You have the following options:

Web Server

Redirect requests to HTTP port

Redirect requests to SSL port

Use a certificate to authenticate to the SSL Web server

FTP server

Use this port when redirecting FTP requests

Figure 8.25: The Bridging Tab

The Web Server option configures the Web Publishing Rule to forward HTTP or HTTPS requests. There is no protocol redirection with this option.

The Redirect requests to HTTP port option when checked allows you to redirect incoming HTTP requests for this Web Publishing Rule and Web listener to the published Web server using the port in the text box to the right of this option. The default port is TCP port 80. You can choose any other port you like for the redirect. This allows you to use alternate port numbers on the published Web sites while still accepting requests on the default HTTP port used by the Web listener (although you do not need to use the default HTTP port on the Web listener if you have configured the Web listener to listen on an alternate port).

Redirect requests to SSL port allows you to redirect requests to the specified SSL port. Note that you can select both the HTTP and SSL checkboxes. When this is the case, incoming traffic is routed through its corresponding protocol and port. For example, if the incoming request is HTTP, then the request is forwarded to the HTTP port. If the incoming request is SSL, the request is forwarded to the SSL port. You can change the SSL port the request is forwarded to, which is helpful if you have SSL sites published on alternate ports.

One of the most misunderstood options in the ISA firewall's user interface is Use a certificate to authenticate to the SSL Web server. This option is not used by the ISA firewall to accept incoming SSL connections from users connecting to the published Web server. This option allows you to configure the ISA firewall to present a user certificate to the published Web site when the Web site requires user certificate authentication. The user certificate is bound to the Firewall service on the ISA firewall and enables the ISA firewall to present a user certificate for authentication to the Web site.

The FTP server option allows the Web Publishing Rule to perform protocol redirection. The incoming request can be either HTTP or HTTPS, and the connection is redirected as an FTP GET request to the published FTP site. Using SSL-to-FTP bridging is useful when providing remote access to FTP sites requiring authentication. Since FTP sites support only Basic authentication, you can protect user credentials by using an SSL link to the external interface of the ISA firewall. The Bridging tab is shown in Figure 8.25.

Users

The Users tab allows you to configure which users can access the published Web site via the Web Publishing Rule. Anyone can access the Web site through the ISA firewall when All Users are allowed access. However, this means that all users can get through the ISA firewall and have the unauthenticated requests forwarded to the published Web site. The Web site itself may require authentication. The user will still need to successfully authenticate with the Web site if the Web site requires authentication.

You can require authentication at the ISA firewall by removing the All Users group and adding any other user group via the Add button. The default groups included with the ISA firewall are All Users, All Authenticated Users, and System and Network Service. You can add your own firewall groups and fine-tune your authentication scheme. We'll talk more about firewall groups and how to use them in Chapter 7 on Creating and Configuring Firewall Policy for Outbound Access. See how to configure the Users tab in Figure 8.26.

Figure 8.26: The Users Tab

The ability to authenticate users at the ISA firewall provides a significant security advantage. Authenticating at the ISA firewall prevents unauthenticated connections from ever reaching the published Web server. Attackers and other malicious users and code can potentially leverage the unauthenticated connection to attack the published server. Authenticating at the firewall first removes the potential security risk.

Note that you can also require authentication at the Web site, so that users are required to authenticate at both the ISA firewall and at the Web site. In some circumstances, users will be presented with two log-on dialog boxes: the first authentication request is made by the ISA firewall, and the second authentication request is made by the published Web site.

You can avoid a dual authentication prompt by taking advantage of the single-sign feature provided by the ISA firewall's delegation of Basic authentication. This feature can be enabled when you select Forward Basic authentication credentials (Basic delegation) on the Users tab.

Delegation of Basic authentication allows users to authenticate with the ISA firewall using Basic authentication. The ISA firewall authenticates the user. If the authentication attempt is successful, the request is forwarded to the published Web site. If the published Web site requests credentials, then the ISA firewall forwards the credentials the user provided when it successfully authenticated with the firewall.

You will need to enable Basic authentication on the Web listener used by the Web Publishing Rule, and the Web site the user authenticates with will also need to use Basic authentication.

Schedule

On the Schedule tab (Figure 8.27) you can configure schedules that control when users can connect to the published Web site. There are three default schedules:

Always The Web site is always available through the Web Publishing Rule.

Weekends All day Saturday and Sunday

Work hours Monday through Friday 9:00

A.M. to 5:00

P.M.

Figure 8.27: The Schedule Tab

You can also create your own custom schedules. We cover this issue in Chapter 7 on outbound access policies.

Link Translation

The ISA firewall's Link Translation feature allows you to rewrite the URLs returned by the published Web servers. URL rewriting is useful when you publish Web sites that hard code links in Web pages they return to users, and those links are not reachable from external locations.

For example, suppose we visit a Web site using the URL www.msfirewall.org. The www.msfirewall.org home page contains hard-coded links in the form of http://server1/users and http://server1/computers. When the Internet user clicks on one of these links, the connection fails because the Internet user isn't able to correctly resolve the name server1 to the IP address on the external interface of the ISA firewall.

The ISA firewall's Link Translation feature allows you to rewrite the links containing server1 to www.msfirewall.org. When the Web server returns the home page of the www.msfirewall.org site, the external user no longer sees the URLs with server1 in them because the ISA firewall rewrote those URLs to include www.msfirewall.org instead of server1. The external user is now able to click on the links and access the content on the Web server. See Figure 8.28.

Figure 8.28: The Link Translation Tab

We go into more detail in about the ISA firewall's Link Translator in Chapter 10.