Publishing and Customizing Web Server Publishing Rules

The key to ISA's HTTP filtering functionality revolves around the Web Server Publishing Rule. What this type of rule does is enable an ISA Server to "pretend" to be the web server itself, while secretly passing the packets back to the server via a separate process. This has the added advantage of securing the traffic by not exposing the web servers to direct attack and by forcing them to first overcome the ISA server before they can overcome the web server.

NOTE

Unlike the other types of server publishing rules, ISA does not need to be installed as a multi-homed (multiple NICs) server to take advantage of web publishing rules. Instead, ISA allows for the creation of web-based publishing rules when it is set up as a uni-homed server, sometimes set up in the DMZ of an existing packet filter firewall. In fact, this setup is a very common deployment model for ISA because there is a strong demand for systems to provide this type of secured reverse proxy capabilities. For more information on this deployment model, see Chapter 7, "Deploying ISA Server as a Reverse Proxy in an Existing Firewall DMZ."

All the HTTP-based filtering and functionality is stored within the web publishing rule options, and it is therefore critical to become intimately aware of its capabilities.

Using the Web Server Publishing Wizard

To secure a web server through ISA Server 2004, a basic web server publishing rule must be set up and configured. When this rule is created, it can be modified as necessary to provide for additional filter capabilities and other options. To create a simple rule, follow the instructions outlined in the following steps. These instructions apply to a specific scenario, where a company's public web server, using simple HTTP, is published through ISA.

1.	From the ISA Server Management Console, click on the Firewall Policy node in the console tree.
2.	From the Tasks tab in the Tasks pane, click the link titled Publish a Web Server.
3.	Enter a descriptive name for the rule and click Next to continue.
4.	Under Action to Take, select Allow and click Next to continue.
5.	Under Computer Name or IP Address, enter the Fully Qualified Domain Name (FQDN) or IP address of the server, using an IP address or name that ISA can use to contact it. NOTE It is important to note that the ISA server must be able to address the web server directly via the name or IP address entered, which almost always resolves to a separate IP address than the one that is publicly addressable. In certain cases, it may be necessary to "fool" ISA into resolving a Fully Qualified Domain Name into an internal IP address with a hosts file, so as to preserve the host header information for the connection from end to end. This is particularly the case with SSL-encrypted websites, which fail if the host header is not exactly the same.
6.	Under Path, enter /*, as shown in Figure 14.1, so that the entire site will be published, and click Next to continue. Figure 14.1. Publishing a website.
7.	Under Public Name Details, choose to accept requests for This Domain Name, and type it into the Public Name field (for example, www.companyabc.com). Leave the Path as /* and click Next to continue.
8.	Under Select Web Listener, click the New button to create a Listener for the website traffic.
9.	Enter a name for the Listener, such as HTTP-WWW-Listener
10.	Select to listen for requests from the external network by checking the box next to it and clicking Next.
11.	Check the Enable HTTP box, set the HTTP port to 80 (as shown in Figure 14.2), and click Next to continue. Figure 14.2. Creating a Web Listener for a web publishing rule.
12.	Click Finish to finish creating the Web Listener.
13.	From the next dialog box, review the Listener properties, and click Next to continue.
14.	Under User Sets, accept the default of All Users and click Next to continue.
15.	Click Finish to create the rule.

NOTE

It is important to note that after the server publishing rule is in place, all HTTP requests sent to the website should point to the IP address of the HTTP Listener on the ISA server itself. This includes publicly accessible websites, which must register the DNS namespace with an IP address on the external interface of the ISA Server.

After it is created, the rule itself should be viewed and the administrator should become aware of the different settings and options available for HTTP filtering, as described in the following sections.

Exploring the General Tab Options

Double-clicking on the web publishing rule that was created brings up the Properties dialog box, which allows for the configuration of the HTTP filtering settings. The first tab displayed is the General tab, as shown in Figure 14.3.

Figure 14.3. Examining the General tab on an ISA Web Publishing Rule.

The General tab enables the rule to be enabled or disabled with the check box, as well as for the name to be changed and a description added, if necessary.

Understanding the Action Tab

Under the Action tab of the web publishing rule, the rule can be set up to either allow or deny traffic. For web publishing rules, this is always set to Allow; there is no reason to create a web publishing rule just to deny access to a web server. In addition, a check box exists on this tab to allow specific log requests to be generated that match the rule.

Exploring From Tab Options

The From tab of a web publishing rule enables an administrator to limit the scope of locations from which the traffic will be allowed to come. For example, a rule could be limited to only those users on a particular subnet, or only a specified list of servers. The Add button can be used to apply specific limitations for the rule.

In addition to specifying where the traffic can originate, this tab also enables specific exceptions to be made. For example, if an entire subnet is restricted, specific exceptions can be made.

Outlining To Tab Options

The To tab of a web publishing rule, as shown in Figure 14.4, enables input of information about the particular server that is being published. This includes the FQDN of the server itself, as well as the option to forward the original host header, if necessary.

Figure 14.4. Examining the To tab options on an ISA Web Publishing Rule.

It may be advantageous to forward the original host header (which takes the form of the FQDN) in cases where specific websites are being restricted by host headers or when a web-based application is expecting host header traffic.

Another very important option is displayed on this tab: the option determining whether the web traffic sees the traffic as originating on the original client or on the ISA Server computer itself. The option to make the traffic appear to come from the original client can help with auditing the traffic and making sure that user access is properly documented. Changing to make all requests come from ISA makes the web server think that the traffic originates from ISA instead. This option is typically more inclusive, and works in multiple scenarios.

CAUTION

If the ISA Server is deployed in uni-homed NIC mode in a firewall's DMZ, the only option that will work properly is to have the requests appear to come from the ISA Server console. Most firewalls do not allow the ISA server to mimic the packets from an untrusted network, and block the traffic itself.

Exploring the Traffic Tab and Filtering HTTP Packets

The Traffic tab looks relatively innocuous, but is actually a launching point to the advanced HTTP filtering options. The basic tab itself shows to what type of traffic the rule applies (HTTP or HTTPS) and provides for the option to inform users to use HTTPS if it is enforced. When using SSL, it also gives the option to require the stronger 128-bit encryption to the traffic, a recommended move in most cases.

Filtering HTTP Traffic

To filter the HTTP traffic, click on the Filtering tab and choose Configure HTTP, which allows for the following HTTP filtering options:

• Maximum Header Length

• Request Payload Length

• Maximum ULR Length

• Maximum Query Length

• Verify Normalization

• Block High Bit Characters

• Block Responses Containing Windows Executable Content

Customizing Allowed Methods

In addition to these options, the filter definitions also enable specific HTTP methods (such as GET and POST) to be allowed in the particular rule. If specific HTTP methods are restricted, a web server can be made even more secure because many of the exploits take advantage of little-used HTTP methods to gain control of a system. To restrict by a specific HTTP method, take the following steps while in the Methods tab:

1.	Under specific the action taken for HTTP methods, use the drop-down box to specify to Allow Only Specific Methods.
2.	Click the Add button.
3.	Enter a name for the HTTP method that will be allowed. For example, enter GET (the method is case-sensitive) and click OK.
4.	From the dialog box shown in Figure 14.5, click OK to save the changes. Figure 14.5. Customizing HTTP methods.

Customizing Extensions

The Extensions tab of the Filtering Rules setting allows only specific types of message attachments to be displayed, such as .mpg files, .exe files, or any other ones defined in this rule. It also allows for the reverse, where all attachments except for specific defined ones are. To accomplish this, choose the option Block Specified Extensions (Allow All Others).

For additional security, the box on this page can be checked to block ambiguous or ill-defined extensions, which can pose a security risk to an ISA Server.

Blocking Headers

Specific HTTP headers can be blocked on the Headers tab of the filtering options. This allows for HTTP Request headers or Response headers to be blocked, which can be useful in denying certain types of HTTP headers, such as User-Agent or Server, that define what type of HTTP traffic is being used.

Restricting Signatures

The Signature Restriction tab is one of the most important. It is "ground zero" for filtering of HTTP traffic to scan for specific exploits and viruses, such as the signature that is defined to block the Kazaa file-sharing application, shown in Figure 14.6.

Figure 14.6. Blocking Kazaa HTTP traffic by signature.

This dialog box is where the majority of the custom filters can be created and applied. Because so many applications and exploits use the HTTP port to tunnel their traffic, it is extremely useful to configure these settings to block malware, scumware, and any other applications that are not approved by the organization. This allows for blocking of signatures from such applications as Instant Messaging, Gnutella, Kazaa, Morpheus, and many more. For a list of signatures that can be blocked, see the following Microsoft URL:

http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/commonapplicationsignatures.mspx

Understanding Listener Tab Configuration Options

The Listener tab of the web publishing tool, shown in Figure 14.7, allows for the customization and creation of various web listeners. A Listener is an ISA construct that "listens" for requests made to a specific IP port combination. As soon as the Listener receives the traffic, it then processes that traffic back into ISA. Listeners are required for web server publishing rules, and are what enable the ISA server to act as a web server to the requesting client.

Figure 14.7. Viewing the Listener tab settings.

The existing Listener that was created in the Publishing Rule Wizard can be directly modified if the rule is selected from the drop-down box and the Properties button is clicked. This allows for various settings to be applied, such as the following:

• Rule name and description

• Which IP address(es) the Listener will listen to

• Whether SSL or HTTP or both are enabled

• What type(s) of authentication methods are available, such as Basic, Integrated, and OWA forms-based authentication

• Whether RADIUS servers are needed

• Number of connections allowed and connection timeout

• RSA SecureID settings as necessary

NOTE

The most important thing to remember about Listeners in ISA Server 2004 is that you can have only a single Listener on each IP:Port combination. In cases where additional IP addresses are not a problem, this is a relatively small issue.

Viewing Public Name Options

The Public Name tab on the web server publishing rule, shown in Figure 14.8, enables an administrator to dictate that the traffic to the ISA Server travels with a specific public name. For example, it could be stipulated that access to a website such as www.companyabc.com is granted only to requests made to that website, rather than requests to an internal server such as \\server20. If a user tries to access that site from an IP address, that request fails because the web publishing rule is allowing only traffic sent to the www.companyabc.com website in this case.

Figure 14.8. Viewing Public Name options.

Understanding Paths Tab Options

In the Paths tab, specific external paths can be mapped to different locations on a web server. For example, it may be helpful to send requests sent to http://www.companyabc.com to http://www.companyabc.com/public automatically. The Paths tab offers this type of functionality. To add a path to accomplish what this model illustrates, for example, do the following:

1.	On the Paths tab of the web publishing rule, click the Add button.
2.	Under Path Mapping, enter /public/*.
3.	Under External Path, select The Following Folder and enter /*, as shown in Figure 14.9. Figure 14.9. Setting up path mapping.
4.	Click OK, Apply, and OK to save the changes.

Exploring the Bridging Tab

The Bridging tab of an ISA web publishing rule, shown in Figure 14.10, gives an administrator the flexibility to send HTTP and/or SSL traffic to different ports on a web server. This concept can help to support those environments that have non-standard ports set up for their web environments.

Figure 14.10. Exploring bridging concepts.

For example, an organization may have set up multiple web servers on an internal web server that has a single IP address. Rather than assign multiple IP addresses to that server, the administrators chose to set up different ports for each virtual server and each website. So, internally, users would have to point to http://site1.companyabc.com:8020 and http://site2.companyabc.com:8030, and so on.

The Bridging option in ISA Server 2004 enables end users to not have to enter in strange port combinations to access websites, and instead relies on the Bridging tab of the rule to direct port 80 traffic to the appropriate ports, such as port 8020 or any other defined port.

Understanding the Users Tab

The Users tab on a web publishing rule is useful only if the full firewall client is deployed throughout the organization; otherwise rules always are set to All Users. If the Firewall client is installed, however, per-userbased access control can be realized, enabling an administrator to monitor and adjust to traffic and security on a per-user basis.

Outlining Schedule Tab Options

The Schedule tab of a web publishing rule, shown in Figure 14.11, does not require much explanation. Using this tab, an organization can decide at exactly what times the rule will be in effect.

Figure 14.11. Viewing the Schedule tab for the web publishing rule.

Exploring the Link Translation Tab

The Link Translation tab allows for a great deal of flexibility in searching for unique bits of contents and replacing those bits of content with something else. More information on this is included in the section of this chapter titled "Securing Access to SharePoint 2003 Sites with ISA 2004."