Common Web Publishing Problems

Common Web Publishing Problems
Part 1: Destination Sets
By Thomas W Shinder, M.D.


We can’t get enough of Web Publishing Rules around here! Why? Web Publishing Rules allow you publish Web servers on the internal network or on a DMZ located behind the ISA Server and make them available to users on the Internet. Sure, you could use Server Publishing Rules to publish Web servers on your internal network, but there are several reasons why you might want to use Web Publishing Rules instead of Server Publishing Rules.


Get the Book!


These advantages include:



  • Publishing multiple Web sites with a single external IP address
  • HTTP Content inspection
  • Redirect requests based on path contained in the URL
  • Terminate an SSL request at the ISA Server
  • Bridge SSL requests
  • Redirect HTTP requests as FTP requests
  • Reverse caching
  • And a lot more!!!

  • Web Publishing rules can do a lot more than than Server Publishing Rules because they leverage the intelligence built into the ISA Server’s Web Proxy service. The Web Proxy service must be installed to use Web Publishing Rules. However, you can use Web Publishing Rules even when you install the server in Firewall mode. You just can’t access the Web Proxy service for outbound access.


    However, Web Publishing Rules are a bit more complex than Server Publishing Rules. The reason is that you must deal with the following issues before you create Web Publishing Rules:



  • Configure one or more Incoming Web Requests Listeners
  • Create Destination Sets that are used in the Web Publishing Rules
  • An internal Web site you can redirect users to when they’re denied access to an external Web site
  • Binding a Web site certificate to the Incoming Web Requests listener, if you want to terminate an SSL connection at the ISA Server

  • Web Publishing Rules are easy to create after you do the preliminary footwork. First, let’s see how how to create a Web Publishing Rule. Perform the following steps to create a Web Publishing Rule:



    1. Open the ISA Management console, expand your server or array name, and then expand the Publishing node.
    2. Right click the Web Publishing Rules node, point to New and click Rule. That will open the Web Publishing Wizard. Type a name for the rule on the first page of the Wizard. I typically type the name of the Web site I’m publishing. For example, if the site is for the domain.com domain, I’ll name the rule DOMAIN.COM. Click Next.
    3. On the Destination Sets page, select the Destination Set that applies to the site you want to publish . You have to create the Destination Set before you create the Web Publishing Rule. For example, if your users access the published Web site by typing www.domain.com in their browsers, you must have a Destination Set containing www.domain.com. While ISA Server does allow you to use IP addresses in your Destination Sets, I recommend that you never use IP addresses for security and functionality reasons. Select your Destination Set and click Next.



    1. You can limit who has access to the published Web site based on your selections on the Client Type page. You can implement access control based on IP address (using client address sets) or user/group membership. Web Proxy service can authenticate incoming Web requests; this feature isn’t available with Server Publishing Rules. Web Publishing Rules allow you to authenticate users before the user actually reaches the Web server. You could allow authentication at the ISA Server if you need to offload authentication processing from the Web server on the internal network. Make your selection and click Next.



    1. Things get interesting when you get to the Rule Action page. Select the Redirect the request to this internal Web Server option. Enter the name or IP address of the internal Web site in the text box. An IP address is the easiest way to do this, but its better to use the site name. If you use a site name that’s the same as the FQDN used by the user to access the site from the Internet, the Web Proxy log will be more useful and you won’t get dreaded 14120 errors in your Application Log. However, you’ll have to create a split DNS or use HOSTS file entries to make this work. Select the Send the original host header to the publishing server instead of the actual one if you’re using Host Headers to publish multiple Web sites. If you don’t select the send original host header option, the ISA Server will forward the request to the internal Web server using the information you supplied in the text box. For example, if you configured it to forward the request to 192.168.1.1, the request will be forwarded to http://192.168.1.1/ instead of the actual site name. Click Next.



    1. Click Finish on the last page of the Wizard and the Web Publishing Rule should start working immediately.

    The Web Publishing Rule starts working immediately almost all the time. However, there are some problems that can adversely affect Web Publishing Rules. Common Web Publishing areas of concern include:



    •  Destination Sets
    •  Redirection to the Web Root
    •  Port and Protocol Redirection
    •  DNS Infrastructure

    Get the Book!


     


    ============


    Destination Sets


    ============


    The Web Proxy service uses entries in Destination Sets to match them up with the URLs found in incoming Web requests. If the Incoming Web Requests listener receives a request for a Destination that is not included in one of the Web Publishing Rules, then the incoming request is dropped.


    For example, if someone types in www.somedomain.com in his Web browser, and www.somedomain.com resolves to the IP address used by the Incoming Web Requests listener, the Web Proxy service will drop the request if there is no Web Publishing rule configured with a Destination Set that includes an entry for www.somedomain.com.


    This explains how ISA Server Web Publishing Rules prevent the Code Red and similar exploits. Incoming requests by the Code Red includes the IP address of the destination host or an unqualified name such as www. Production ISA Servers should never use IP addresses in Destination Sets for this reason. I know that some of you are wary of registering domain names, but if you don’t want to deal with a domain Registrar, you can always use a service like TZO (www.tzo.com).


    You’ll run into problems with Code Red like attacks if the ISA Server is allowed to resolve unqualified requests to the IP address used by the Incoming Web Requests listener. As we saw earlier, some variants of Code Red send “www” in the host header rather than an IP address. So, in spite of the fact that you don’t have a Destination Set containing an entry for “www” in any of your Web Publishing Rules, if your ISA Server is configured to resolve unqualified requests by appending the ISA Server’s primary domain name and you have published a site using a Destination Set that includes an entry for www.isa_server’s_domain_name then the request will be passed to the internal Web server and potentially compromise that machine.


    For example, suppose some scumbag creates a worm that sends out requests to Web servers and the request header contains www. The ISA Server doesn’t like unqualified requests, so it attempts to resolve www by appending a domain suffix to the request. By default, Windows member servers append the domain name of the domain they belong to. If your internal network domain is domain.com, the ISA Server will try to resolve the request as www.domain.com by appending the ISA Server primary domain suffix to the request. If www.domain.com resolves to the IP address on the external interface of the ISA Server, the worm could reach your Web server.


    You can prevent this from happening by making the following additions to the ISA Server’s Registry:


    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Proxy\Parameters\SkipNameResolutionForPublishingRules


    DWORD : 1


    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3Proxy\Parameters\SkipNameResolutionForAccessAndRoutingRules


    DWORD : 1


    Restart the ISA Server after adding these values. Now you won’t be vulnerable to Code Red-like attacks using unqualified names in the request header.


    The most common problem with Destination Sets is that they’re misconfigured. Entries in a Destination Set must match what was is included in the inbound request. For example if you publish a Web site that is accessible from the Internet using the URL http://www.mydomain.com, the entry in the Destination Sets must be www.mydomain.com. Note that only the FQDN and optionally a path is included in the Destination Set. You do not include the “http://” in the Destination Set entries. I run into several ISA Server admins who have been able to carry out the most complex ISA Server configurations, but they’re Web Publishing Rules don’t work because they put the protocol in the Destination Set entry. Don’t you fall into the same trap!


    Get the New Book!


    The Destination Set will not work if you put in the name the Web server uses on the internal network. This is true regardless of whether you use the NetBIOS name or Fully Qualified Domain Name that if valid for the publishing server on the internal network. For example, the NetBIOS name of the Web server on the internal network is WEBSERVER1 and the FQDN for the server on the internal network is webserver1.internal-domain.com. Neither one of these names will work in a Destination Set used in a Web Publishing Rule because the Internet users is unaware of the server’s internal network name and do not use it to access the published Web site.


    You can also run into problems with Destination Sets that have path statements. For example, what if you wanted to allow users access only to a specific subdirectory on a published Web site? You would need to include a path statement like in the figure below. If the Destination Set includes only entries with paths, users will not be able to access the Web root. So far, so good.



    Path Statements are frequently used to redirect requests to alternate servers on the internal network. For example, suppose you have two Destination Sets; each Destination Set containing one of the following entries:


    www.mydomain.com PATH: /dallas/*


    www.mydomain.com PATH: /houston/*


    You can use these Destination Sets in two different Web Publishing Rules. The first Web Publishing rule using the Destination Set with the /dallas/* path and forwards requests to an internal server named WEBSERVER1. The second rule with path /houston/* forwards the requests to an internal server named WEBSERVER2.


    Web Publishing Rules allow you to redirect to different servers on the internal network even though the FQDN is the same, because the path after the FQDN is different. The problem is that you must have that same path available on the destination server on the internal network. For example, if the user types in http://www.mydomain.com/dallas in his browser, the Web Proxy service will redirect the request to http://WEBSERVER1/dallas. The request is not redirected to the Web root at WEBSERVER1. This is a common cause of concern for ISA Server admins who have experience with Proxy Server 2.0 because Proxy Server could redirect requests with paths to the Web root.


    Get the Book!


    ============


    Summary


    ============


    In the first part of our two part article on troubleshooting Web Publishing Rules, we went over how to create the Web Publishing rules and examine problems with that crop up when Destination Sets are configured incorrectly. In part two of this article, we’ll look at problems with redirecting incoming Web requests to the Web Root, issues with Protocol Redirection and the very common, but easily fixable, DNS infrastructure snafus.


    I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=5;t=001323 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

    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