Publishing and Customizing SharePoint Web Server Publishing Rules

The key to ISA's HTTP filtering functionality revolves around the web server publishing rule. This type of rule allows an ISA Server to "pretend" to be the SharePoint 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 directly exposing the SharePoint web servers from direct attack and forcing them to overcome the ISA server before they can overcome the SharePoint server.

NOTE

Unlike with 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 as a unihomed server, sometimes set up in the DMZ of an existing packet filter firewall. In fact, this setup is a common deployment model for ISA because there is a strong demand for systems to provide this type of secured reverse proxy capabilities.

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 Publish a SharePoint Site

To secure a SharePoint 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 additional filter capabilities and other options. To create a simple rule, perform the following steps. These instructions apply to a specific scenario, where a SharePoint Portal Server for a company, 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 Publish a Web Server link.
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 or name that ISA can use to contact it. NOTE The ISA server must be able to directly address the web server via the name or IP address entered, which will almost always resolve 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 will fail if the host header is not exactly the same.
6.	Under Path, enter /*, as shown in Figure 16.1, so that the entire site will be published, and click Next to continue. Figure 16.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, sharepoint.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-SharePoint-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 16.2, and click Next to continue. Figure 16.2. Creating a web listener for a SharePoint 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 once 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.

When 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

By double-clicking on the web publishing rule that was created, the properties dialog box is invoked, which allows for the configuration of the HTTP filtering settings. The first tab displayed is the General tab, as shown in Figure 16.3.

Figure 16.3. Examining the General tab on an ISA web publishing rule.

The General tab allows for 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 because there is no reason to create a web publishing rule just to deny access to a web server. In addition, a check box on this tab allows specific log requests to be generated that match the rule.

Exploring the From Tab Options

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

In addition to specifying where the traffic can come from, this tab also allows specific exceptions to be made. For example, if an entire subnet was restricted, specific exceptions can be made.

Outlining To Tab Options

The To tab of a web publishing rule, as shown in Figure 16.4, allows information to be entered about the particular server being published. This includes the FQDN of the server itself, as well as the option to forward the original host header if necessary.

Figure 16.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 important option is displayed on this tab: the option of deciding 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 unihomed NIC mode in the DMZ of a firewall, the only option that will work properly is to have the requests appear to come from the ISA Server console. This is because most firewalls do not allow the ISA Server to mimic the packets from an untrusted network and subsequently block the traffic.

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 what type of traffic the rule applies to (HTTP or HTTPS) and provides 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

Filtering of the HTTP traffic is made accessible by clicking on the Filtering tab and choosing Configure HTTP, which provides 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 allow for specific HTTP methods (such as GET and POST) to be allowed in the particular rule. By restricting specific HTTP methods, 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, do the following steps while in the Methods tab:

1.	Under Specify the Action Taken for HTTP Methods, select Allow Only Specified Methods from the drop-down box.
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 16.5, click OK to save the changes. Figure 16.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 others defined in this rule. It also allows for the reverse, where all attachments except for specific defined ones will be blocked. This is accomplished by choosing 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 enables 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, which defines the type of HTTP traffic being used.

Restricting Signatures

The signature restriction tab is one of the most important because 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 16.6.

Figure 16.6. Blocking Kazaa HTTP traffic by signature.

The Signature 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 useful to configure these settings to block malware, scumware, and any other applications not approved by the organization. This enables 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 16.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. When that traffic hits the listener, it then processes that traffic back into ISA. Listeners are required for web server publishing rules and are what allows the ISA server to act as a web server to the requesting client.

Figure 16.7. Viewing the Listener tab settings.

The existing listener created during the Publishing Rule Wizard can be directly modified by selecting the rule from the drop-down box and clicking the Properties button. This enables 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 only have 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 16.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 SharePoint site such as sharepoint.companyabc.com only occurs 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 would fail because the web publishing rule is only allowing traffic sent to the sharepoint.companyabc.com website, in this case.

Figure 16.8. Viewing Public Name options.

Understanding Paths Tab Options

The Paths tab allows specific external paths to be mapped to different locations on a web server. For example, it may be helpful to send requests sent to http://sharepoint.companyabc.com to http://sharepoint.companyabc.com/ sites/sales automatically. To add a path to accomplish this example, do the following:

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

Exploring the Bridging Tab

The Bridging tab of an ISA web publishing rule, shown in Figure 16.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 environments that have nonstandard ports set up for their web environment.

Figure 16.10. Exploring bridging concepts.

For example, an organization may have set up multiple SharePoint web servers on an internal SharePoint 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 allows end users to not have to enter 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 8888 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, it is always set to All Users. If the Firewall client is installed, however, per-user based access control can be realized, allowing 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 16.11, does not require much explanation. Using this tab, an organization can decide exactly at what times the rule will be in effect.

Figure 16.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 content and replacing those bits of content with something else. Link translation effectively looks through all the web traffic and replaces specific hypertext links with administrator defined ones. This comes in handy with SharePoint, which too often exposes a bug in the code that allows internal SharePoint Portal identities to be exposed to the Internet. For example, if SERVER15 is a SharePoint server, but the SharePoint site is http://portal.companyabc.com, the pages in SharePoint will sometimes appear with links to //server15, which will not be able to be resolved from the Internet.

To enable link translation on a SharePoint site, do the following:

1.	On the Link Translation tab of the web publishing rule, check the box to Replace Absolute Links in Web Pages.
2.	Click the Add button.
3.	Under the Add/Edit Dictionary Item dialog box, enter the text that will be replaced. For example, replace the text server15 with portal.companyabc.com, as shown in Figure 16.12. Figure 16.12. Performing link translation on a SharePoint site.

In addition to replacing text links with link translation, the Link Translation tab also has the capability to restrict by content type, by clicking on the Content Types button. The following types of content are available for restriction:

• Application

• Application data files

• Audio

• Compressed files

• Documents

• HTML documents

• Images

• Macro documents

• Text

• Video

• VRML