Creating and Configuring Non-SSL Web Publishing Rules (Part 3)

If you would like to read the other parts in this article series please go to:

In the first two parts of this three part series on how to publish non-SSL Web sites, we began by starting up the Web Publishing Rule wizard and continued with configuring the Web listener. In this, the last part of the series, we’ll finish up the Web Publishing Rule Wizard and then examine the properties of the Web Publishing Rule. By the time you finish this article, you will have all the tools you’ll need to publish non-SSL Web sites.

Discuss this article

The User Sets Page

On the User Sets page 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 1: The User Sets page

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.


Figure 2: The General tab

The Action Tab

On the Action tab 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.

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


Figure 3: The Action tab

The From Tab

On the From tab you configure the 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 the Anywhere entry and then clicking the Remove button. After removing the Anywhere entry, click the Add button. 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 that the published server is located on. This is generally a very 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 after making your changes.


Figure 4: The From tab

The To Tab

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.

It is important to note that there are some significant improvements in ISA 2006 which reduce the complexity of the configuration on the To tab.

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 form the ISA Server computer
  • Requests appear to come from the original client

The 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 it 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.

The Request appear to come from the original client option 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 appears 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 appear in the Web site’s logs.

For this reason and more, we always 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.


Figure 5:  The To tab

The Traffic Tab

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 you set on the Web listener you configured for this Web Publishing Rule.

The Notify HTTP users to use HTTPS instead checkbox is disabled in this example because we are not using an SSL listener. When this option is available, it will allow the ISA firewall to return an error page to the user accessing the Web site through the Web Publishing Rule 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 3 seconds to resubmit the request by adding an “s” to the protocol in the request. Forcing users to enter the correct protocol also encourages the users to use correct Internet hygiene.

The Require 128-bit encryption for HTTPS traffic option 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.

It is important to note here that the options on this page work a bit differently in ISA 2006. Please refer to Stefaan Pouseele’s blog at http://blogs.isaserver.org/ for more information on this problem.

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


Figure 6: The Traffic tab

The Listener Tab

On the Listener tab you can view the characteristic 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 the Properties button. You can also create a new Web listener by clicking the New button and then applying the new listener to this Web Publishing Rule.

If you have already created multiple Web listeners on this ISA firewall, then 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 7: The Listener tab

The Public Name Tab

The Public Name tab allows you to view and configure the publish 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 choose the name www.msfirewall.org for the public name that can be used to access the Web server published by this Web Publishing Rule. If a request comes in on the Web listener used by this Web Publishing Rule is for a FQDN that is different from this one, then 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.

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 resolve 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 the Add button, and you can Remove or Edit a selected public name by clicking the Edit and Remove buttons.

Click Apply when you have made your desired changes to the Public Name tab.


Figure 8: The Public Name tab

Discuss this article

The Paths Tab

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 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, then enter the path using the /path/* format. If you want to allow access to a single file in a path, then 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.htm file in the documents directory, then enter the path as /documents/names.htm.


Figure 9: The Paths tab

Click the Add button to add a new path. In the Path mapping dialog box, enter an internal path in the 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. If the same path is used by external users, then select the Same as published folder. If the users will enter a different path, the select the The following folder option and enter the alternate path in the The following folder text box.


Figure 10: The Path mapping dialog box

ISA FIREWALL TIP:
Many ISA firewall administrators wish to redirect to the root of the Web site based on the path entered by the user. For example, if the user enters the URL http://www.msfirewall.org/firewalldocs, then the request should be forwarded to the root of internal Web server at 10.0.0.2. You can do this by entering the external path as /firewalldocs/* and the internal path as / as seen in figure 11. All connections made to the firewalldocs directory are now redirected to the root of the server listed in the To tab, which in this case is 10.0.0.2.


Figure 11: Redirecting to the Web root using a path

A common desire among ISA firewall administrators is to redirect connections to the root 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. The paths tab with this type of OWA configuration would look like that seen in figure 12.

WARNING: This “trick” does not work with ISA 2006 and you should use a Deny Web Publishing Rule with a redirect to get your OWA redirection working correctly.

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, wher eit 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 she the same path prefix.


Figure 12: Mapping the OWA Web site root to the Exchange folder

Another thing you can do with path statements is redirect to different servers based on a path statement. 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 from 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 users 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.

The Bridging Tab

The Bridging tab 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

The Web Server option configures the Web Publishing Rule to forward HTTP or HTTPS requests as 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 forward connections 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 accepts 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).

The Redirect requests to SSL port option 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 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 the Use a certificate to authenticate to the SSL Web server option. 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 then 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 the user credentials by using an SSL link to the external interface of the ISA firewall.


Figure 13: The Bridging tab

The Users Tab

The Users tab allows you to configure what 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 mean that all users can get through the ISA firewall and have the unauthenticated request 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 itself 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.


Figure 14: 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 user 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 dual authentication prompt by taking advantage of the single-sign feature provided by the ISA firewall’s delegation of Basic authentication feature. This feature can be enabled when you select the Forward Basic authentication credentials (Basic delegation) checkbox 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.

WARNING: In order for delegation of basic authentication to work, the ISA Firewall must be a domain member. In most circumstances, the more secure and more flexible ISA Firewall configuration is when the ISA Firewall is a domain member. There are very few scenarios where the ISA Firewall should not be made a domain member. While this might defy some readers concept of “common sense”, keep in mind that “common sense” once held that the world was flat.

The Schedule Tab

On the Schedule tab 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 9AM to 5PM

You can also create your own custom schedules.


Figure 15: The Schedule Tab

The Link Translation Tab

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 web 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 users 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.


Figure 16: The Link Translation tab

Discuss this article

Summary

In this, the last part of a three part series on how to create non-SSL Web Publishing Rules, we finished up the Web Publishing Rule Wizard and looked at the Properties of the Web Publishing Rule. With the information you gained for reading all three parts of this series, you should be able to create just about any type of non-SSL Web Publishing Rule. If there’s something in this article series that you don’t understand, then make sure to click the discussion link in this article and ask a question on the Web boards. I’ll be notified of your question and will try to answer it as quickly as possible. Thanks! –Tom

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top