If you would like to read the other parts in this article series please go to:
- Creating and Configuring Non-SSL Web Publishing Rules (Part 2)
- Creating and Configuring Non-SSL Web Publishing Rules (Part 3)
Web Publishing Rules allow you to make Web servers on your internal networks or on DMZ networks available to external users. Web Publishing Rules are superior to Server Publishing Rules in many ways, in that they leverage the security features built into the Web proxy filter and Web proxy filter add-ons, such as the HTTP Security Filter. For that reason, you should always use Web Publishing Rules when publishing Web services to the Internet.
For the most part, Web Publishing Rules work the same in both the 2004 and 2006 ISA Firewalls. However, there are some significant differences in terms of Web Farm Load Balancing, authentication, and certificate support. In this article, which focuses on generic HTTP (non-SSL) Web Publishing Rules, the differences are not as profound, so we’ll focus on the 2004 ISA Firewall this time since many more of you are using 2004 than 2006. In the future I’ll describe the Web Publishing Process using SSL in ISA 2006.
You can create Web Publishing Rules by using the ISA firewall Web Publishing Rule Wizard. The Web Publishing Rule wizard walks you through the steps of creating a Web Publishing rule that allows you to publish Web servers and services on any ISA firewall Protected Network.
In this section we’ll focus on Web Publishing Rules that do not require SSL secured connections. SSL security requires additional steps and we’ll cover those steps in the next section where we focus on secure SSL Web Publishing Rules.
To start the Web Server Publishing Rule wizard, open the ISA Firewall 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 the 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 (figure 1), 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 be to 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, for example, to create exceptions to an allow rule. Chose the Allow option and click Next.
Figure 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. 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)
In the Computer name or IP address text box you enter either the IP address or the fully qualified domain name of the Web server on the ISA firewall Protected Network. If you use a FQDN, then 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 insure 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. It’s important to note here that improvements in the 2006 ISA Firewall obviate the need to create the HOSTS file entry.
Figure 2: 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 not forwarding and forwarding the original host headers in figures 3, 4 and 5. In figure 3 you 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 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 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 4: HTTP headers seen on the Published Web Server without forwarding original host header
However, when we enable the Forward the original host header instead of the actual one (specified above), we see on the published Web server what appears in figure 5. In this case, the Network Monitor trace shows that the host header seen on the Web server is HTTP: Host =www.msfirewall.org.
Figure 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, is 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 choose 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)
The Accept requests for down list provides you with two choices: Any domain name and This domain name (type below). If you choose the Any domain name option, any requests for any 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 virus or worm attack, or attacks from malicious users. Enabling access via IP address enables a vast array of automated attacks to be launched against your Web site. Again, I strongly recommend that you never allow access via IP address.
For example, many 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 the Any domain name option, 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 the This domain name (type below) option. When you choose this option, you enter the exact domain name that must be included in the users request to access the Web site. If you want to accept requests only for the www.msfirewall.org domain, then incoming requests for http://184.108.40.206 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 the This domain name (type below) option, 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.
Note that even if you have just a single IP address bound to the external interface of the ISA Firewall, you can create multiple Web Publishing Rules to publish multiple Web sites on your internal or DMZ networks. The difference is that each Web Publishing Rule will have a different name on the Public Name page and the redirect will be to a different IP address or host header name. You can publish literally hundreds of Web sites using a single IP address.
The Path (optional) text box allows you to restrict the path(s) that users can access via this Web publishing rule. 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, you can enter additional paths after the wizard is complete in the Properties dialog box for this rule.
Figure 6: The Public Name Details page
In this article, part 1 of a three part series on publishing non-SSL sites, I went over the basic concept of a Web Publishing Rule and what they’re used for, how to start the Web Publishing Rule wizard, and took us up to the part of the wizard where we’ll next be asked to create a new Web listener. Because the concept of the Web listener is somewhat complex, and is the configuration, of the Web listener, we’ll leave that part until next week. See you then! – Tom.
If you would like to read the other parts in this article series please go to: