Web Filters - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Web Filters

ISA firewall Web filters are used to mediate HTTP, HTTPS, and FTP tunneled (Web proxied) connections through the ISA firewall. In this section, we discuss the following Web filters:

HTTP Security filter

ISA Server Link Translator

Web Proxy filter

SecurID filter

OWA Forms-based Authentication filter

The HTTP Security Filter (HTTP Filter)

The ISA firewall's HTTP Security filter is one of the key application layer filtering and inspection mechanisms included with the ISA firewall. The HTTP Security filter allows the ISA firewall to perform application layer inspection on all HTTP communications moving through the ISA firewall and block connections that do not match your HTTP security requirements.

The HTTP Security filter is tightly tied to the Web Proxy filter. When the Web Proxy filter is bound to the HTTP protocol, all communications outbound through the ISA firewall with a destination port of TCP 80 are subjected to the HTTP Security filter's deep application layer inspection. We'll see later how to unbind the Web Proxy filter from the HTTP protocol if you do not want all communications to be scrubbed by the HTTP Security filter.

The HTTP Security filter is applied on a per-rule basis, and you can apply different HTTP filtering properties on each rule that allows outbound HTTP communications. This provides you very granular, fine-tuned control over what type of connections can move over the HTTP channel. In addition, you can bind the Web Proxy filter to other ports and enforce HTTP Security Filter policy over connections moving over alternate ports. This provides you another potent weapon against users and applications that try to subvert your network and Firewall Security policy by tunneling Web connections over alternate ports.

In this section, we discuss:

Overview of HTTP Security Filter Settings

HTTP Security Filter Logging

Disabling the HTTP Security Filter for Web Requests

Exporting and Importing HTTP Security Filter Settings

Investigating HTTP Headers for Potentially Dangerous Applications

Example HTTP Security Filter Policies

Commonly Blocked Application Signatures

The Dangers of SSL Tunneling

Overview of HTTP Security Filter Settings

The HTTP Security filter includes a number of tabs that allow you precise control over what HTTP communications are allowed through the ISA firewall on a per-rule basis. Configuration of the HTTP Security filter is done on the following tabs:

General

Methods

Extensions

Headers

Signatures

The General Tab

On the General tab, you can configure the following options (see Figure 10.16):

Maximum header length

Payload length

Maximum URL length

Verify normalization

Block high bit characters

Block responses containing Windows executable content

Figure 10.16: The General Tab

The Maximum headers length (bytes) option allows you to configure the maximum length of all headers included in a request HTTP communication. This setting applies to all rules that use the HTTP Security filter. This setting protects you from attacks that try to overflow Web site buffers by sending excessively long headers to the Web server. If you set the value too low, some applications on your site might not work correctly. If you set it too high, intruders may be able to construct a special HTTP request that could exploit known and unknown buffer overflow issues with your Web site or Web server. You might want to start with a value of 10,000 bytes and work upward from there. Your Web site administrator should be able to help you with the maximum header length required for sites your ISA firewall protects.

In the Request Payload frame, you have the option to Allow any payload length or to set a specific maximum payload length. The payload is the part of the HTTP communication that is not part of the HTTP header or command structure. For example, if you allow users to post content to your Web site (an ordering form or a discussion forum), you can set a limit on the length of their posts by unchecking the Allow any payload length checkbox and entering a custom value in the Maximum payload length (bytes) text box. Again, you may want to discuss your Web site's requirements with your Web site administrator or Web programmer to get specific details on maximum payload length requirements for your protected Web sites.

There are several options in the URL Protection frame. The Maximum URL length (bytes) option allows you to set the maximum URL that the user can send through the ISA firewall when making a request through the firewall for a Web site. Exploits can send excessively long URLs in an attempt to execute a buffer overflow or other attack against a Web server. The default value is 10240, but you can increase or decrease this value based on your own site's custom requirements. The Maximum query length (bytes) value allows you to set the maximum length of the query portion of the URL. The query part of the URL appears after a question mark (?) in the request URL. The default value is 10240, but you can make it longer or shorter, based on your requirements. Keep in mind that the Maximum URL length must be longer than the Maximum query length because the query is part of the URL.

The Verify normalization option is also included in the URL Protection frame. Normalization is the process of decoding so-called 'escaped' characters. Web servers can receive requests that are encoded using escaped characters. One of the most common examples is when there is a space in the URL, as in the URL http://msfirewall.org/Dir%20One/default%20file. The %20 is an 'escape' character representing a 'space.' The problem is that bad guys can also encode the '%' character and perform what is called 'double encoded' requests. Double encoding can be used to attack Web servers. When the Verify Normalization option is selected, the HTTP Security filter will normalize or decode the request twice. If the request of the first and second decodings is not the same, the HTTP Security filter will drop the request. This prevents 'double encoding' attacks. You should enable this feature, but keep in mind that poorly designed Web sites and Web applications are not always security aware, and may actually accept and require double encoded requests. If that is the case for sites you want to access on the Internet or for sites you publish through the ISA firewall, you will need to disable this option.

The Block high bit characters option allows you to block HTTP requests that include URLs with high bit characters in them. High bit characters are used by many languages that use extended character sets, so if you find that you can't access Web sites that use these extended character sets in their URLs, you will need to disable this option.

The Block responses containing Windows executable content option allows you to prevent users from downloading files that are Windows executable files (such as .exe files, but any file extension can be used on a Windows executable). The HTTP Security filter is able to determine if the file is a Windows executable because the response will begin with an MZ. This can be very helpful when you need to prevent your users from downloading executables through the ISA firewall.

The Methods Tab

You can control what HTTP methods are used through an Access Rule or Web Publishing Rule using the settings on the Methods tab (see Figure 10.17). You have three options:

Allow all methods

Allow only specified methods

Block specified methods (allow all others)

Figure 10.17: The Methods Tab

HTTP methods are HTTP commands that hosts can send to a Web server to perform specific actions; for example, GET, PUT, and POST. There are others that you, as a network and firewall administrator might not be familiar with, such as HEAD, SEARCH, and CHECKOUT. There are other methods that are proprietary and used by specific Web applications, such as Outlook Web Access. The Allow all methods option allows you to allow HTTP methods used in an HTTP communication through the ISA firewall.

The Allow only specified methods option allows you to specify the exact methods you want to allow through the ISA firewall. If you can identify what methods are required by your Web site and Web application, then you can allow those only and block any other method. Other methods could be used to compromise your Web site, so if they're not needed, block them.

The Block specified methods (allow all others) option allows you to allow all methods except those specific methods you want to allow. This option provides you a bit more latitude in that even if you don't know all the methods your site might require, you might know some that are definitely not required. One example might be the POST method. If you don't allow users to post content to your Web site, then there's no reason to allow the POST method, and you can explicitly block it.

When you select either the Allow only specified methods or the Block specified methods (allow all others) option, you need to click the Add button to add the method you want to allow or block. The Method dialog box appears after clicking the Add button.

In the Add dialog box, you enter the method in the Method text box (Figure 10.18). You might also want to add a description of this method in the Description text box. This helps you remember what the method does and helps the next person who might need to manage your ISA firewall and isn't aware of the insides of the HTTP protocol command set.

Figure 10.18: The Methods Dialog Box

The Extensions Tab

On the Extensions tab, you have the following options (see Figure 10.19):

Allow all extensions

Allow only specified extensions

Block specified extensions (allow all others)

Block requests containing ambiguous extensions

Figure 10.19: The Extensions Tab

You can control what file extensions are allowed to be requested through the ISA firewall. This is extremely useful when you want to block users from requesting certain file types through the ISA firewall. For example, you can block users from accessing .exe, .com, .zip, and any other file extension through the ISA firewall.

The Allow all extensions option allows you to configure the Access Rule or Web Publishing Rule to allow users access to any type of file based on file extension through the ISA firewall. The Allow only specified extensions option allows you to specify the precise file extensions that users can access through the ISA firewall. The Block specified extensions (allow all others) option allows you to block specified file extensions that you deem dangerous.

If you select the Allow only specified extensions or Block specified extensions (allow all others) option, you need to click the Add button and add the extensions you want to allow or block.

The Extension dialog box appears after you click the Add button. Enter the name of the extension in the Extension text box. For example, if you want to block access to .exe files, enter .exe . Enter a description if you like in the Description (optional) text box. Click OK to save the new extension. (See Figure 10.20.)

Figure 10.20: The Extensions Dialog Box

The Headers Tab

On the Headers tab, you have the following options (see Figure 10.21):

Allow all headers except the following

Server header

Via header

Figure 10.21: The Headers Tab

An HTTP header contains HTTP communication specific information that is included in HTTP requests made from a Web client (such as your Web browser) and HTTP responses sent back to the Web client from a Web server. These headers perform multiple functions that determine the status or state of the HTTP communications and other characteristics of the HTTP session.

Examples of common HTTP headers include:

Content-length

Pragma

User-Agent

Accept-Encoding

You can accept all HTTP headers or you can block certain specific HTTP headers. There are certain HTTP headers you might always want to block, such as the P2P-Agent header, which is used by many peer-to-peer applications. If you want to block a specific HTTP header, click the Add button.

In the Header dialog box, select either the Request headers or Response headers option from the Search in drop-down list. In the HTTP header text box, enter the HTTP header you want to block. Click OK. (See Figure 10.22.)

Figure 10.22: The Header Dialog Box

You can configure the Server Header returned in the HTTP responses by making a selection in the Server Header drop-down list. The Server Header is an HTTP header that the Web server sends back to the Web client informing the client of the type of Web server to which the client is connecting. Intruders can use this information to attack a Web server. You have the options to:

Send original header

Strip header from response

Modify header in response

The Send original header option lets the header sent by the Web server go unchanged. The Strip header from response option allows the ISA firewall to remove the Server Header, and the Modify header in response allows you to change the header. You should change the header to confuse the attacker. Since this header isn't required by Web clients, you can change it to something like Private or CompanyName or anything else you like.

These options all help to prevent (or at least slow down) attackers. Attackers will have to expend more effort and use alternate methods to 'fingerprint' your Web server. (See Figure 10.23.)

Figure 10.23: The Server Header Option

The Via Header option allows you to control the Via Header sent to the Web client. When Web Proxy servers are located between a client and Web server, the Web Proxy server will insert a Via Header in the HTTP communication informing the client that the request was handled by the Web Proxy server in transit. Each Web Proxy server in the request path can add its own Via Header, and each sender along the response path removes its own Via Header and forwards the response to the server specified in the next Via Header on the Via Header 'stack.' The Via Header settings allows you to change the name your ISA firewall includes in its own Via Header and enables you to hide the name of your ISA firewall. The default setting is for your ISA firewall to include its own Computer name in the Via Header.

You have two options:

Send default header

Modify header in request and response

The Send default header option leave the Via Header unchanged. The Modify header in request and response option allows you to change the name included in the Via Header inserted by your ISA firewall. We recommend that you change this to hide the actual name of your ISA firewall to prevent attackers from learning the actual name of your ISA firewall machine. (See Figure 10.24.)

Figure 10.24: The Via Header

Enter the alternate Via Header in the Change To text box.

The Signatures Tab

The Signatures tab allows you to control access through the ISA firewall based on HTTP signatures you create. These signatures are based on strings contained in the following components of an HTTP communication:

Request URL

Request headers

Request body

Response headers

Response body

You access the Signature dialog box by clicking the Add button. (See Figure 10.25.)

Figure 10.25: The Signatures Tab

In the Signature dialog box, enter a name for the signature in the Name text box and a description of the signature in the Description text box. This is especially helpful so that you know the purpose and rationale for this signature.

In the Search in drop-down list, select where you want the ISA firewall to search for the specified string. You have the follow options:

Request URL When you select this option, you can enter a string that when found in the Web client's request URL, the connection is blocked. For example, if you wanted to prevent all requests to sites that have the string Kazaa in the URL included in the Web client's request, you enter Kazaa in the Signature text box.

Request headers When you select this option, you enter the specific HTTP header you want the ISA firewall to check in the HTTP header text box and then enter the string in the header you want the ISA firewall to block in the Signature text box. For example, if you want to block eDonkey P2P applications, you can select this option and then User-Agent in the HTTP header text box. In the Signature text box, you then enter ed2k. Note that this option gives you more granular control than you would have if you just blocked headers in the Headers tab. If you block a specific header in the Headers tab, you end up blocking all HTTP communications that use that specific header. By creating a signature that incorporates a specific header, you can allow that HTTP header for all communications that do not include the header value you enter for the signature.

Request body You can block HTTP communications based on the body of the Web request outside of that contained in the HTTP commands and headers. While this is a very powerful feature, it has the potential to consume a great deal of resources on the ISA firewall computer. For this reason, you need to configure the byte range you want the ISA firewall to inspect in the Byte range From and To text boxes. We don't have any explicit recommendations on specific entries you might want to include in this section, but will provide updates on www.isaserver.org when we do.

Response headers When you select this option, you enter the specific HTTP header you want to block based on the HTTP response returned by the Web server. You enter the specific HTTP header in the HTTP header text box and the HTTP header value in the Signature text box.

Response body The response body option works the same as the Request body option, except it applies to the content returned to the Web client from the Web server. For example, if you want to block Web pages that contain specific strings that are identified as dangerous or inappropriate, you can create a signature to block those strings. Keep this in mind when reading about the latest Web-based attack and create a signature that blocks connections that employ such an attack.

Figure 10.26 shows some example signatures blocking some commonly encountered applications that might be considered a major security risk for corporate networks.

Figure 10.26: Example Signatures

HTTP Security Filter Logging

How do you know if your security filters are working? One way to determine the effectiveness of the entries you've made in the HTTP Security filter is to use the ISA firewall's built-in log viewer. Perform the following steps to configure the ISA firewall's built-in log viewer to view HTTP Security Filter actions:

In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name and click the Monitoring node in the left pane of the console.

In the Monitoring node, click the Logging tab. In the Tasks tab of the Task Pane, click the Start Query link.

Right-click one of the column headers and click the Add/Remove Columns command.

In the Add/Remove Columns dialog box, click the Filter Information entry in the Available Columns list and click Add. The Filter Information entry now appears in the list of Displayed columns. Click OK.

Issue a request from a client behind the ISA firewall that would be blocked by your HTTP Security Filter settings. Figure 10.27 shows an example of a connection that was blocked because the URL contained a string that was disallowed by the HTTP Security filter.

Figure 10.27: Log File Entries Showing the HTTP Security Filter Blocking a Connection

Exporting and Importing HTTP Security Filter Settings

An HTTP policy can be exported from or imported into an Access Rule that uses the HTTP protocol or a Web Publishing Rule. The HttpFilterConfig.vbs script located at \sdk\samples\admin can be used to export an existing HTTP policy that has already been configured in an Access Rule or Web Publishing Rule or an HTTP policy that has already been exported to a file can be imported into an existing Access Rule or Web Publishing Rule.

The HttpFilterConfig.vbs script greatly simplifies configuration of complex HTTP policies that include multiple entries for parameters such as signature, file extensions, and headers. We recommend that you export your HTTP policies after you create them in the Microsoft Internet Security and Acceleration Server 2004 management console.

In this section, we discuss how you can export and import an HTTP policy from and to a Web Publishing Rule.

Exporting an HTTP Policy from a Web Publishing Rule

HTTP policies can be exported from an Access Rule or Web Publishing Rule using the HttpFilterConfig.vbs file located on the ISA 2004 CD-ROM. Follow these steps to export the HTTP policy from an existing Web Publishing Rule:

Copy the HttpFilterConfig.vbs file from the ISA firewall CD-ROM to the root of the C: drive.

Open a command prompt and change the focus to the root of the C: drive. Enter the following command and press Enter (notice that if the rule name has a space in it you must enclose the name in quotes):

C:\Httpfilterconfig.vbs import "Publish OWA Site" c:\webpol.xml

You will see a dialog box confirming that the information was successfully imported into the rule (see Figure 10.28).

Figure 10.28: Successful Import Dialog Box

Importing an HTTP Policy into a Web Publishing Rule

HTTP policies can be imported into Access Rules that include the HTTP protocol and Web Publishing Rules. We use the same script we used when exporting an HTTP policy, the HttpFilterConfig.vbs file. To import an HTTP policy saved to an .xml file into a Web Publishing Rule named Publish OWA Site:

Copy both the .xml file and the HttpFilterConfig.vbs file from the ISA firewall CD-ROM to the root of the C: drive. In this example, the .xml file is named webpol.xml.

Open a command prompt and change the focus to the root of the C: drive. Enter the following command and press Enter (notice that if the rule name has spaces in it, you must enclose the name in quotes):

C:\Httpfilterconfig.vbs import "Publish OWA Site" c:\webpol.xml

You will see a dialog box confirming that the information was successfully imported into the rule (see Figure 10.29).

Figure 10.29: Successful Import Dialog Box

Investigating HTTP Headers for Potentially Dangerous Applications

One of your primary tasks as an ISA firewall administrator is to investigate characteristics of network traffic with the goal of blocking new and ever more dangerous network applications. These dangerous applications might be peer-to-peer applications, instant messaging applications, or other applications that hide by wrapping themselves in an HTTP header. Many vendors now wrap their applications in an HTTP header in an attempt to subvert your Firewall policy. Your goal as an ISA firewall administrator is to subvert the vendors' attempt to subvert your Network Usage policy.

As you can imagine, the vendors of these applications aren't very cooperative when it comes to getting information on how to prevent their applications from violating your firewall security. You'll often have to figure out this information for yourself, especially for new and obscure applications.

Your main tool in fighting the war against network scumware is a protocol analyzer. Two of the most popular protocol analyzers are Microsoft Network Monitor and the freeware tool Ethereal. Both are excellent, the only major downside of Ethereal being that you need to install a network driver to make it work correctly. Since the WinPcaP driver required by Ethereal hasn't been regression tested against the ISA firewall software, it's hard to know whether it may cause problems with firewall stability or performance. For this reason, we'll use the built-in version of Network Monitor included with Windows Server 2003 in the following examples.

Let's look at a couple of examples of how you can determine how to block some dangerous applications. One such application is eDonkey, a peer-to-peer file-sharing application. The first step is to start Network Monitor and run a network monitor trace while running the eDonkey application on a client that accesses the Internet through the ISA firewall. The best way to start is by configuring Network Monitor to listen on the Internal interface of the ISA firewall, or whatever interface eDonkey or other offending applications use to access the Internet through the ISA firewall.

Stop the trace after running the offending application for a while. Since we're only interested in Web connections moving through TCP port 80, we can filter out all other communications in the trace. We can do this with Display filters.

Click the Display menu and then click the Filter command. In the Display Filter dialog box, double-click the Protocol == Any entry. (See Figure 10.30.)

Figure 10.30: The Display Filter Dialog Box

In the Expression dialog box, click the Protocol tab and then click the Disable All button. In the list of Disabled Protocols, click the HTTP protocol, click the Enable button, and then click OK. (See Figure 10.31.)

Figure 10.31: The Expression Dialog Box

Click OK in the Display Filter dialog box. The top pane of the Network Monitor console now only displays HTTP connections. A good place to start is by looking at the GET requests, which appear as GET Request from Client in the Description column. Double-click on the GET requests and expand the HTTP: Get Request from Client entry in the middle form. This displays a list of request headers.

In Figure 10.32, you can see that one of the request headers appears to be unusual (only if you have experience looking at Network Monitor traces; don't worry, it won't take long before you get good at this). The HTTP: User-Agent =ed2k seems like it might be specific for eDonkey2000. We can use this information to create an HTTP Security Filter entry to block the User-Agent Request Header value ed2k.

Figure 10.32: The Network Monitor Display Window

You can do this by creating an HTTP Security Filter signature using these values. Figure 10.33 shows what the HTTP Security Filter signature would look like to block the eDonkey application.

Figure 10.33: The Signature Dialog Box

Another example of a dangerous application is Kazaa. Figure 10.34 shows a frame displaying the GET request the Kazaa client sends through the ISA firewall. In the list of HTTP headers, you can see one that can be used to help block the Kazaa client. The P2P-Agent HTTP request header can be blocked completely, or you can create a signature and block the P2P-Agent HTTP request header when it has the value Kazaa. You could also block the Host header in the HTTP request header when the value is set as desktop.kazaa.com.

Figure 10.34: Network Monitor Display Showing Kazaa Request Headers

Example HTTP Security Filter Policies

Creating HTTP Security Filter policies can take some time. You need to run the required applications and then determine the required methods, extensions, headers, and other signatures that are specific for your application. While the effort is well spent, sometimes you need to get critical applications up and running quickly.

For this reason, we include a couple of example HTTP Security Filter policies you can use right away to protect IIS Web sites and Outlook Web Access sites.

Table 10.2 provides the defaults of a good default Web site HTTP Security Filter policy you can use. This policy allows the most common methods required for simple Web sites and restricts extensions that might allow an attacker to compromise your site. There are also several HTTP signatures included that block common strings that Internet criminals might use to compromise your Web site or server.

Table 10.3 provides settings you can use to configure an HTTP Security Filter policy for OWA publishing. Notice the methods required by OWA. You can see these in action by using the ISA firewall's built-in log filter and watching the HTTP Methods column.

Table 10.4 shows entries for an HTTP Security Filter policy you can use for an RPC-over-HTTP Web Publishing Rule. Notice the unusual HTTP methods used by the Outlook 2003 RPC-over-HTTP protocol.

Commonly Blocked Headers and Application Signatures

While we consider it an entertaining pastime spending long evenings with Network Monitor and discovering how to block dangerous applications, not all ISA firewall administrators share this predilection. For those of you who need to configure your ISA firewall to protect your network from dangerous applications as soon as possible, we provide the information in Tables 10.5 and 10.6.

Table 10.5 lists the information you need to include in signatures to block commonly encountered dangerous applications. You use the information in this table to create a signature entry in the HTTP Security filter.

Table 10.6 contains some HTTP header values you can use to block dangerous applications. In contrast to signatures that require the HTTP header name and value, the entries in Table 10.6 can be configured in the Headers tab of the HTTP Security filter. These headers are specific for the listed dangerous applications and are not used for legitimate HTTP communications, so you do not need to specify a specific value for the HTTP headers blocked here.

The Dangers of SSL Tunneling

As an ISA firewall administrator, your main concern is controlling what external users can access on your corporate network and what users on the corporate network can access on the Internet and other networks within the corporate network. You spend a lot of time configuring a Firewall policy so users have access only to the protocols you want them to use, connect only to the servers you want them to connect to, download only the content corporate Security policy approves, and access resources only at a specified time of day.

You must have the ability to allow or deny VPN connections, remote desktop connections, access to Web servers, and file transfer via Web or Instant Messenger connections. The truth is, you need to be able to explicitly allow or deny all communications moving through the ISA firewall.

Major problems occur when a firewall encounters encrypted communications. For example, what happens when users use an SSL encrypted connection to an OWA Web site? Conventional hardware firewalls (such as PIX or Sonicwall) see an incoming connection to TCP port 443. An access control list (ACL) on the hardware firewall tells it to allow the incoming connection and forward it to the OWA site on the corporate network.

The remote access OWA client negotiates an encrypted SSL connection with the OWA site. All communications moving through the hardware firewall are now encrypted and the hardware firewall has no clue about the contents of the encrypted SSL 'tunnel.' There is nothing the hardware firewall can do if an attacker or worm on the OWA client machine launches an attack against the OWA server through this SSL encrypted session. Simple stateful filtering hardware firewalls just say, 'this is an SSL connection and I have an ACL to allow SSL connections to the OWA server, have a nice day.'

This is a serious security problem, and one against which hardware firewalls are helpless to protect. The fact that attackers can leverage an encrypted channel that you allow through the firewall means you have lost access control, because the corporate Firewall policy cannot be enforced against the contents of the encrypted channel.

This situation gets even worse. Many application developers are getting into the HTTP tunneling act. They do this ostensibly to get around 'restrictive firewalls' that allow only HTTP and/or HTTPS outbound or inbound. To get around these 'restrictive firewalls,' they 'wrap' their application protocol in an HTTP header so that firewalls configured to allow HTTP/HTTPS communications allow their application through.

Examples of this type of HTTP tunneling of non-Web applications include RPC over HTTP(S), the GoToMyPC application, and a large number of HTTP tunneling applications explicitly designed to subvert a Firewall policy (http://www.google.com/search?hl=en&ie=UTF-8&q=HTTP+tunnel).

So-called 'SSL VPNs' also belong to this group. SSL 'VPNs' are used to bypass firewall security and tunnel an array of application protocols within an encrypted SSL link. All of these applications, whether designed to increase productivity (such as RPC over HTTP) or to explicitly violate Network Usage policy, have a common goal: hide the underlying application protocol inside an encrypted SSL tunnel.

While hardware firewalls do not have the capability to inspect contents of an SSL tunnel and thus block access to application protocols hidden inside the tunnel, the ISA firewall is not hobbled by the limitations of hardware firewall architecture. The ISA firewall does much more than simple stateful filtering; it is able to break open the SSL encrypted tunnel, perform deep stateful application layer inspection of the contents, and then re-encrypt the communication and forward it to the site on the corporate network.

At this point, it should be clear that the ISA firewall provides a much higher level of security than a traditional stateful filtering hardware firewall. Today's attacks are at the application layer and are focused against servers and services on the corporate network that drive business.

This is not to say that the ISA firewall administrator's life is perfect. While the ISA firewall's 'SSL bridging' feature allows it to provide a level of security orders of magnitude higher than what you see with hardware firewalls for incoming SSL connections, we still have to worry about SSL tunneled applications sourcing from the corporate network destined for Internet sites.

The ISA firewall performs inbound SSL bridging and stateful application layer inspection, but does not perform outbound SSL bridging. Outbound SSL bridging is what we need to prevent exploits contained in outbound SSL tunnels. Once outbound SSL bridging is available, you'll be able to block internal users from hiding HTTP tunneled applications in their encrypted SSL links.

Our advice is to be very wary of 'SSL VPNs' and any other application that hides the real nature of its communications inside an SSL encrypted link. The ISA firewall can block or allow these applications when they must pass through a Web Publishing Rule, but not when they move through an Access Rule. It vital that you keep this in mind when creating Firewall policies.

Consider whether users really need outbound access to SSL sites. If so, you should strictly limit the sites to which they can establish SSL connection. Otherwise, users could leverage their permission to tunnel just about any protocol inside that SSL link, and you do not want that.

The ISA Server Link Translator

Link Translation solves a number of issues that may arise for external users connecting through the ISA firewall to an internal Web site.

The ISA firewall Link Translator is implemented as an ISA firewall Web filter. Because of the Link Translator's built-in functionality, and because it comes with a built-in default dictionary, you can use it right out of the box to solve many common problems encountered with proxy-based Web publishing scenarios.

For example, when pages on the internal Web site contain absolute URLs pointing to itself, the Link Translator will return the appropriate links to the external user, even when those URLs contain http:// prefixes and the external user connects to the Web site using https://.

The default Link Translator dictionary can also appropriately translate requests made to nonstandard ports. For example, if users connect to a Web site that is published on a nonstandard port, such as http://www.msfirewall.org:8181, link translation will include the port number in the URLs sent back to the external client.

When you enable link translation for a Web Publishing Rule, a Link Translation dictionary is automatically created. In most cases, you won't have to add to the default dictionary.

The default dictionary includes the following entries:

Any occurrence on the Web site of the computer name specified on the To tab of the Web Publishing Rule Properties is replaced with the Web site name (or IP address). For example, if a rule redirects all requests for http://www.microsoft.com to an internal computer called SERVER1 (or 192.168.1.1), all occurrences of http://SERVER1 in the response page returned to the client are replaced with http://www.microsoft.com.

If a nondefault port is specified on the Web listener, that port is used when replacing links on the response page. If a default port is specified, the port is removed when replacing links on the response page. For example, if the Web listener is listening on TCP port 88, the responses returned to the Web client will include links to TCP port 88.

If the client specifies HTTPS in the request to the ISA firewall, the firewall will replace all occurrences of HTTP with HTTPS.

For example, suppose the ISA firewall publishes a site located on a machine with the internal name SERVER1. The ISA firewall publishes the site using the public name www.msfirewall.orgdocs. An external Web client then makes the following request:

GET /docs HTTP/1.1Host: www.msfirewall.org

Note that the directory name in the request is not terminated by a slash (/). When the server running Internet Information Services (IIS) receives this request, it automatically returns a 302 response with the location header set to http://SERVER1/docs/, which is the internal name of the server followed by the directory name and terminated by a slash.

The ISA firewall's Link Translator then translates the response header value to http://www.msfirewall.org/docs/.

In this example, the following entries are automatically added to the Link Translation dictionary:

http://SERVER1 is mapped to http://www.msfirewall.org

http://SERVER1:80 is mapped to http://www.msfirewall.org

https://SERVER1 is mapped to https://www.msfirewall.org

https://SERVER1:443 is mapped to https://www.msfirewall.org

For security reasons, if an initial client request was sent via SSL, all links to the same Web server are translated to SSL. The following entries are automatically included in the Link Translation dictionary:

http://SERVER1 is mapped to https://www.msfirewall.org

http://SERVER1:80 is mapped to https://www.msfirewall.org

https://SERVER1 is mapped to https://www.msfirewall.org

https://SERVER1:443 is mapped to https://www.msfirewall.org

If the published Web site uses ports other than the default HTTP and SSL ports (for example, 88 for HTTP and 488 for SSL), links containing that port number will also be translated. For example:

http://SERVER1:88 is mapped to http://www.msfirewall.org

https://SERVER1:488 is mapped to https://www.msfirewall.org

In the same way, if the ISA firewall publishes the site using a Web listener on nondefault ports (for example, 85 for HTTP and 885 for SSL), links will be translated to the published ports:

http://SERVER1 is mapped to http://www.msfirewall.org:85

http://SERVER1:80 is mapped to http://www.msfirewall.org:85

https://SERVER1 is mapped to https://www.msfirewall.org:885

https://SERVER1:443 is mapped to https://www.msfirewall.org:885

While the default dictionary is effective for most simple Web publishing scenario, things get a bit stickier when you publish more complex Web sites. For more complex Web publishing scenarios, or when complex ASP code is involved (for example, with SharePoint services), it's necessary to configure dictionary entries that map to names returned by the internal Web site.

The Link Translator checks the Content-type header of the response to determine whether link translation should be applied to the body of the message. The default settings allow for link translation only MIME types belonging to the HTML document's content group. The ISA firewall's Link Translator 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 Translator maps text strings according to the following rules:

The Link Translator searches for the longest strings, then shorter strings, and finally the default strings.

If the Link Translator finds a matching 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 Link Translator finds a terminating character immediately to the right of the string, it will perform translation on that string.

For example, consider a scenario where the Link Translation dictionary is configured to replace 'sps' with 'extranet.external.net' and a response page returned by the Web server includes a hard-coded link to http://Sps/SpsDocs/. The Link Translator translates the string to 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.

Because of these potential translation issues, it's critical that you understand the behavior of link translation mapping to prevent problems with your custom Link Translator dictionaries.

Determining Custom Dictionary Entries

You must test the behavior of the Link Translator to see if any custom dictionary entries are required. SharePoint Portal Services provides a fertile test bed for testing the Link Translator. Begin your test by connecting to a published SharePoint site using an external client and testing the functionality of the published site. You should look for links pointing to internal server names and links that use the wrong prefix (for example, http instead of https).

Be aware that some links will be included in client-side scripts returned to the browser for processing. You should therefore also view the HTML source code that is returned, not just the rendered HTML in the browser.

In the case of a published SharePoint site, it may be necessary to add custom dictionary entries. For example, even though the Link Translator is enabled, the search function on the SharePoint site may return results with both the wrong prefix (http instead of https) and internal server names.

In addition, after adding custom dictionary entries to fix these problems, the source code of the search results page contains JavaScript that includes references to the wrong prefix, causing errors to be returned to the browser when trying to perform an additional search from the search results page.

For example, after adding two dictionary entries to replace 'http://' with 'https://' 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 is necessary to explicitly map the shorter string 'http:' to 'https:'. Importantly, it is necessary to include the colon (:) in the dictionary entry. Simply mapping 'http' to 'https' (without the colon) causes the entire site to be inaccessible.

It should be clear to you at this point that finding the correct custom dictionary entries can involve extensive and repetitive testing. Incorrect link translation mappings can break the Web site for external clients, so we highly recommend that you test configurations in your test lab before deploying link translation in a production environment.

Configuring Custom Link Translation Dictionary Entries

Custom Link Translation dictionaries are configured on a per-rule basis. Remember, link translation is only performed on links returned by Web servers published by Web Publishing Rules; you do not configure Link Translation for outgoing requests to Internet Web servers.

To configure Link Translation:

Right-click the Web Publishing Rule and click Properties.

In the Web Publishing Rule's Properties dialog box, click the Link Translation tab.

On the Link Translation tab, put a checkmark in the Replace absolute links in Web pages checkbox. Click the Add button.

In the Add/Edit Dictionary Item dialog box, enter the name of the string you want replaced in returned links in the Replace this text text box. Enter the value you want to replace the string in the With this text text box. Click OK. (See Figure 10.35.)

Figure 10.35: Add/Edit Dictionary Text Box

The dictionary entry appears in the list of dictionary entries. Click the Content Types button. (See Figure 10.36.)

Figure 10.36: Link Translation Tab in Web Publishing Rule Properties

In the Link Translation dialog box, select the content types to which you want to apply Link Translation. By default, only the HTML Documents content type is selected. Your selection here is global and applies to all Web Publishing Rules. Even though you can create custom dictionaries for each Web Publishing Rule, the content types are the same for all dictionaries.

The Web Proxy Filter

The Web Proxy filter allows connections from hosts not configured as Web Proxy clients to be forwarded to the ISA firewall's Cache and Web Proxy components. If you want only hosts that are explicitly configured as Web Proxy clients to use the ISA firewall's Web Proxy feature set, you can unbind the Web Proxy filter by removing the checkmark from the Web Proxy Filter checkbox.

The SecurID Filter

The SecurID filter is used to mediate SecurID authentication with the ISA firewall. The SecurID filter configuration interface is accessed via the Authentication Properties dialog box for the Web listener. Figures 10.38 and 10.39 show the configuration interfaces.

Figure 10.38: The HTTP Properties Dialog Box and RSA SecurID Tab

Figure 10.39: The Manage Domain Configuration Dialog Box

The OWA Forms-based Authentication Filter

The OWA Forms-Based Authentication filter is used to mediate Forms-based authentication to OWA Web sites that are made accessible via ISA firewall Web Publishing Rules. Figure 10.40 shows the configuration interface for the OWA Forms-Based Authentication filter, which is accessible from the Authentication dialog box for the Web listener.

Figure 10.40: The OWA Forms-Based Authentication Dialog Box

For more information on the OWA Forms-Based Authentication filter, see Chapter 8, 'Web and Server Publishing.'

The RADIUS Authentication Filter

The RADIUS Authentication filter is used to mediate RADIUS authentication for Web Proxy clients and external hosts connecting to published Web sites via Web Publishing Rules.

The RADIUS filter is used by Web listeners when the listeners are configured to use RADIUS authentication. While the RADIUS filter provides you the ability to authenticate against any RADIUS-compliant directory (including the Active Directory), it does limit you to use only RADIUS authentication on the listener configured to use RADIUS. In contrast, when using other authentication methods, such as basic or integrated authentication, you can support multiple authentication protocols on a single Web listener.

For more information on using the RADIUS filter and configuring the RADIUS filter for forward and reverse Web Proxy scenarios, see Chapter 8 and Chapter 6, 'Configuring Outbound Access through an ISA Firewall.'