Microsoft Internet Security and Acceleration Server 2000 Application Layer Filtering Kit

Chapter 8

Prevent Attackers from Gathering Valuable Internal Network Information by using the ISA Server 2000 Link Translator

Dr. Thomas W Shinder

Martin Grasdal

December 2003

Table of Contents

Abstract 3

The Problem: Attackers Can Obtain Valuable Networking Information from Web Site Generated Links. 4

The Solution: The ISA Server 2000 Link Translator 5

Security Implications of Non-Translated Links. 6

How the ISA Server 2000 Link Translator Works. 7

Configuring Link Translation. 9

Determining Custom Dictionary Entries. 12

Summary. 16

Abstract

Network attackers use a variety of methods to gain access to information on your corporate network. Different attackers have different motivations; some want to destroy information or disable the network, either “just for fun” or for political or economic reasons (business competitors). Others do not wish to do damage, but instead want to steal information. This is often done for profit (corporate espionage). The latter care more about stealing private information than destroying or disabling network services.

Some Web sites return the names of private internal network servers. Attackers can use this information to help them steal private and proprietary information from your network. The ISA Server 2000 Link Translator can correct this problem by leveraging ISA Server 2000’s application layer filtering firewall features to return only public names to external users accessing the Web sites.

This article includes information on how to configure the ISA Server 2000 link translator to increase the security and accessibility of Web sites published using ISA Server 2000 Web Publishing rules. Step by step instructions are provided on how to install and configure the ISA Server 2000 Link Translator.

The Problem: Attackers Can Obtain Valuable Networking Information from Web Site Generated Links

More sophisticated attacks who seek to gain specific information about network services and applications on the corporate network will attempt to determine the location of private or proprietary information so they can steal your corporate information. Vulnerable data includes financial information, business strategy documents, trade secrets and information about your clients and employees.

There are several ways the intruder can obtain information about your network:

• The intruder can attempt to compromise and control the firewall and launch the attack from there. This is difficult because most firewalls, including ISA Server 2000, are almost impossible to compromise and abnormal conditions are immediately reported to a security administrator
• The intruder can attempt an attack against a publicly accessible server and then attempt to gain information about the network after obtaining control over the compromised server. This is difficult because publicly accessible servers typically are hardened and are configured to immediately inform a security administrator in the event of an abnormal condition, such as a file change or unexpected log on.
• The intruder can gain information about the network using non-attack methods, acting as a normal user. The attacker can then use social engineering approaches to gain direct access to the corporate network and connect directly to the server containing the desired information. This method is more effective because no abnormal incidents are generated that might attract a security administrator’s attention and it also allows the attacker to get into the network and gather the desired information as quickly as possible.

One way network attackers can find out information about your private network is from links that are returned to users when they connect to publicly accessible Web sites. Many Web applications are coded in a way that allows them to be used primarily on an intranet and not with remote access users in mind. These Web applications return links with single-label computer names in them instead of public names in hierarchical domain format. The attacker can use these single label names and get information about the names of the servers on your internal network.

For example, you have published a Web server on the internal network using an ISA Server 2000 Web Publishing rule. External users access the sites using the URL http://www.external.net. The published Web server responds to the user’s request with a Web page containing several links. Each of these links contains URLs that point to http://hrdatabase1. If the attacker is interested in stealing information about employees, he can safely infer that this server might contain the information he desires. Other Web pages on the site may contain names of other servers on the internal network that store private information not meant for public consumption.

You might have thought, when reading the example above, that the external user would not be able to access any content using single label links such as http://hrdatabase1 because this is not an Internet resolvable name. For a name to be Internet resolvable, you have to have the host name and the domain name. In order to connect to http://hrdatabase1, you would have to have some mechanism to append a domain name to hrdatabase1, so that it looks something like hrdatabase1.external.net.

Organizations hosting Web sites that contain single label links can solve the problem if they have control over the external clients that access the site. These external clients can be configured with a primary domain name that is used when fully qualifying single label names. For example, if an external client is configured to use external.net as its primary domain name, then the link to http://hrdatabase1.external.net will actually go to http://hrdatabase1.external.net. If there is a public DNS entry hrdatabase1.external.net, then the external client will be able to access a Web site published to the IP address mapping to hrdatabase1.external.net.

Note:
This method only works for external clients over which you have some control, because the clients must be explicitly configured with the proper domain name used to fully qualify the single label name.

A network attacker who is reconnoitering your network will be able to access the first page of the site, but will not be able to connect to the links. However, this doesn’t pose a significant problem for the attacker because he can manually enter the same domain name that he used for the initial connection to the single label name and access other pages in the site, which might reveal even more private server names.

Outside the security risk issues related to returning single label names in links returned to the users, this situation creates a large amount of administrative overhead if you need to configure each remote client to use a specific domain name to qualify unqualified requests. A better solution is to re-write the Web application so that it does not use hard-coded links to internal server names. Unfortunately, this can become a very expensive proposition and in many circumstances isn’t possible at all.

The Solution: The ISA Server 2000 Link Translator

The ISA Server 2000 Link Translation feature solves a number of issues that may arise for external users connecting through an ISA Server 2000 firewall to access a published Web site. The ISA Server 2000 link translator solves the problem of revealing private network computer names and allows external users to access published content by receiving links that are accessible from the Internet.

SharePoint Portal Server 2003 provides an ideal example of how the ISA Server 2000 link translator solves these problems. Links that SharePoint Web sites return in response to search queries show the name of the internal network server. When an external user enters a search term on the SharePoint 2003 Web site, the response to that search includes links pointing to the internal server name of the SharePoint server, rather than the external name used for the published site. External users cannot access resources using these links because the internal server name is different from the name the external user uses to access the published Web site.

Another important issue that you may encounter when publishing Web sites involves the use of SSL and links included in response to external client requests. In many cases, the URLs returned to external clients use an http:// instead of https://. This breaks the connection because the server requires an SSL connection. The connection attempt fails when the external user clicks a link using http:// instead of https://

The figure below demonstrates this problem:

The figure above shows an external user connected to https://extranet.external.net/, which is the FQDN in the Destination Set used in the Web Publishing Rule to provide access to the internal Web site. Notice that links returned to the external user point to http://sps/, which is the internal name of the SharePoint server.

The request will fail when an external user clicks any of these links. There is no Web Publishing rule allowing users to connect to http://sps. Even if there were a Web Publishing rule that included sps in its Destination Set, http://sps is a name used to access the site from an internal network client. The external client is unlikely to be able to correctly resolve the name sps to the IP address on the external interface of the ISA Server 2000 firewall that is being used by the Incoming Web Requests listener. In addition, if the Web Publishing rule has been configured to require an SSL connection, a connection request using http:// will fail.

Security Implications of Non-Translated Links

While these are serious problems in terms of accessibility, perhaps an even more troubling issue is that the page returned to the external user contains links to internal network server names that are used inside the organization. This is a security risk.

It is considered best practice in the security community to never reveal internal server names used on the internal network to external users. This helps to prevent hackers, competitors, and others from discovering information about the network and inferring the function of various network servers based on their names. Because servers are often named with informative labels that help internal users and administrators identify their roles on the network, a significant amount of information can be gleaned by an interested third party whose motives may be suspect.

Link translation solves these problems by mapping text strings contained in the returned URLs to other text strings that the administrator configures in an ISA Server 2000 link translation dictionary used by the Web publishing rule.

Note:

Some Web servers allow you to customize the URLs returned to users who access the sites from a remote location, but others do not. For example, SharePoint Portal Server 2003 allows you to customize the URL returned on search result pages using a feature called Alternate Portal Access Settings. A similar feature is not available in Outlook Web Access, so the link translator becomes a valuable tool in these scenarios.

How the ISA Server 2000 Link Translator Works

Link translation is part of ISA Server 2000 Feature Pack 1 and installs as a Web application filter. Due to the ISA Server 2000 link translator’s built-in functionality and its default dictionary, simply enabling it will solve a number of problems in simple publishing scenarios. For example, when pages on the internal Web server contain absolute URLs that point to its own server name (NetBIOS name), the link translation filter will return the appropriate links that are accessible for external network users. In addition, even when those URLs contain http:// and the external user connects to the Web site using https://, the ISA Server 2000 link translator can change the link to use https:// instead of http://.

The default link translation dictionary will also translate requests made to non-standard ports. For example, if users connect to a Web site published on a non-standard port on the ISA Server 2000 firewall, such as http://www.external.net:8181, link translation includes the port number in the URLs sent back to the external client. If the ISA Server 2000 link translator were not installed, the links would contain the default port (TCP 80) and the external network user would not be able to connect to the site with the links on the Web page.

For more complex publishing scenarios or when complex ASP code is involved (for example, SharePoint Portal Server 2003 publishing) it is necessary to configure dictionary definitions that map to the names returned by the internal Web site. The dictionary name mappings are configured on a per-Web publishing rule basis on the ISA Server 2000 firewall.

The link translation application filter extends the already present link translation capability of ISA Server 2000. Even without the link translation filter installed, ISA Server 2000 performs link translation on the Content-location and location headers that are used in various HTTP response codes. (This always occurs when Web publishing rules are used.)

When link translation is installed and enabled, the ISA Server 2000 firewall also checks the Content-type header of the response to determine whether link translation should be applied to the body of the message. (By default, link translation operates only on MIME types belonging to the HTML documents content group, but other content groups can be specified).

Tech Note:
The link translation filter works by first looking for a Content-type header to determine if it needs to perform translation. If no Content-type header is present, the filter will look for a Content-location header to perform translation. If neither header is present, the filter will look at the file extension.

The link translation filter maps text strings according to the following rules when link translation dictionaries are used in Web publishing rules:

· The filter searches for the longest strings, then shorter strings, and finally the default strings

· If the filter finds a match to a text string, it will then look at the next character to the right to see if it is a terminating character. The following are considered terminating characters:

\t

\r

\n

;

~

<

!

"

&

'

)

$

)

*

+

,

-

/

>

=

?

[

\

]

^

{

|

}

· If the filter finds a terminating character immediately to the right of the string, it will perform translation.

For example, consider a scenario where the link translation dictionary is configured to replace “sps” with “extranet.external.net” and a response page includes a link to http://Sps/SpsDocs/. The filter translates the string as http://extranet.external.net/SpsDocs/. However, if the response page includes a link to http://sps/sps-isa/, both instances of “sps” would be translated because they are both followed by a terminating character, resulting in http://extranet.external.net/extranet.external.net-isa/ being sent to the external client. In the first example (http://extranet.external.net/SpsDocs/) the terminating character is the “/” and in the second example (http://sps/sps-isa/) the terminating character is the “-“.

Needless to say, a good understanding of the results of link translation mapping is important to prevent problems that might occur with custom dictionaries. Furthermore, the behavior of link translation should be a consideration when developing guidelines for naming Web sites that are accessible to internal and external network users.

Configuring Link Translation

The ISA Server 2000 link translation Web application filter is installed with Feature Pack 1 for ISA Server 2000 by default. However, the filter is disabled. A number of potential problems may be solved by the default behavior of the link translation filter without any further action on your part.

If simply enabling the filter solves the problems external clients are experiencing, no other configuration is necessary. If a custom dictionary is necessary, then you will have to do some analysis to determine what entries to put in the dictionary and then add these entries to the dictionary. Dictionary entries are dependent on the underlying code of the returned pages and vary according to how your Web sites and Web services work.

Determining the appropriate strings to replace is something of an art and may require the assistance of a developer who understands the client-side scripts that are returned to the external client. Working with the Web site developer can allow you to cut the time it takes to create the appropriate link translator dictionary.

The steps for configuring the ISA Server 2000 link translator are as follows:

1. Open the ISA Management console, expand the Servers and Arrays node and then expand your server name. Expand the Extensions node, and click on the Web Filters node.
2. Right-click on the Link Translation Filter in the right pane of the console, and click Enable in the context menu, as in the figure below.

Figure 1 Enabling Link Translation Web Application Filter

3. You will be asked whether you wish to restart the Web proxy service manually or have ISA Server restart it automatically for you after enabling the filter. Select the desired choice and click OK. You can manually restart the Web proxy service from the Monitoring | Services node in the ISA Management console.

The only content group the link translator operates on is the HTML Documents content group. If you wish to use link translation for other content groups, access the properties of the Link Translator Filter, click on the Content Groups tab, and select the content groups as appropriate.

Figure 2 Selecting Content Groups for Link Translation

The next step is to enable link translation for the Web Publishing Rule. Perform the following steps to enable the link translator for a specific Web Publishing rule:

1. In the ISA Management console, expand the Servers and Arrays node, expand your server name, and then expand the Publishing node. Expand the Web Publishing Rules node.
2. Right click on the appropriate Web publishing rule, click Properties, and then click on the Link Translation tab.


3. In the Link Translation tab, click on the check boxes to Perform link translation and to Prevent caching of responses on external proxy servers, as in the figure below, and click OK.

Figure 3 Enabling Link Translation on Web Publishing Rule

Determining Custom Dictionary Entries

You should test the default behavior of the link translation filter to see if any custom dictionary entries are required. You do this by connecting to the published SharePoint site using an external client and testing the functionality of the published site. Specifically, you should look for links pointing to internal server names and links that use the wrong protocol prefix (e.g., http rather than https). You should be aware that some of these links will be included in client-side scripts that are returned to the browser for processing, so you should also view the HTML source code that is returned, not just the rendered HTML in the browser.

For example, suppose you publish a SharePoint Portal Server 2003 site. You will need to create custom dictionary entries to publish SharePoint Portal Server 2000 Web sites. As discussed earlier in this article, even though the link translation filter was enabled, the search function on the SharePoint Portal Server 2003 site returned results with both the wrong prefix (http:// instead of https://) and internal server names.

In addition, after adding link translator dictionary entries to fix these problems, the source code of the search results page contained JavaScript that included references to the wrong prefix, which caused errors to be returned to the browser when you try to perform an additional search from the search results page.

For example, after adding two dictionary entries to replace “http://” with “https://” (as per the Feature Pack 1 help files) and to replace “sps” with “extranet.external.net”, the returned source code included the following strings in the client-side JavaScript code:

f.action='http:\/\/extranet.external.net\/Search.aspx', and

http:\\\/\\\/extranet.external.net\\\/Search.aspx

To fix this problem, it was necessary to map the shorter string “http:” to “https:” Importantly, it is necessary to include the colon “:” in the dictionary entry mapping. Simply mapping “http” to “https” (without the colon) causes the entire site to be inaccessible.

Creating optimal custom dictionary entries may involve extensive and repetitive testing. Incorrect link translation mappings can break the Web site for external clients, so it is a good idea to test your configurations in a test lab before deploying link translation in a production environment.

To add a custom dictionary entry, click the Add button on the Link Translation tab of the Properties of the Web Publishing Rule and enter the original and replacement strings in the appropriate text boxes, as in the figure below. When finished, click OK and add other entries as necessary.

Figure 4 Adding a Dictionary Item

Keep in mind that this string will be too long to prevent all problems with incorrect links being returned by the published SharePoint site and that you may have to conduct some trial-and-error experimentation in a test lab to determine string mappings for your environment.

The Feature Pack 1 help files recommend that you also add mappings that include the port number for the Web site, for example, http://sps:80. Also, you should not include terminating characters at the end of the mappings you create.

For SharePoint Portal Server 2003, the minimum configuration seen in the figure below appeared to provide an optimal solution. This configuration allows the proper links to be returned for search results returned by the SharePoint Web site.

Figure 5 Custom Translate Link Dictionary Entries

After configuring dictionary entries, the results returned to external network clients from the search function were correct and accessible. Keep in mind that the entries in the figure above appear to be contrary to recommendations in the Feature Pack 1 help files. However, they do provide the desired functionality. The figure below shows the search results.

Figure 6 Link Translation Providing Correct Responses to Search Queries

Summary

Network attackers use a variety of methods to gain access to information on your corporate network. More sophisticated attacks who seek to gain specific information about network services and applications on the corporate network will attempt to determine the location of private or proprietary information. These attackers care more about stealing private information than destroying or disabling network services.

Some Web sites return the names of private internal network servers. Attackers can use this information to help them steal private and proprietary information from your network. The ISA Server 2000 Link Translator can correct this problem by leveraging ISA Server 2000’s application layer filtering firewall features to return only public names to external users accessing the Web sites.

This article includes information on how to configure the ISA Server 2000 link translator to increase the security and accessibility Web sites published using ISA Server 2000 Web Publishing rules. Step by step instructions are provided on how to install and configure the ISA Server 2000 Link Translator.