The ISA firewall’s SMTP filter configuration interface can be accessed by opening the Microsoft Internet Security and Acceleration Server 2006 management console, expand the server name, and then expand the Configuration node. Click the Add-ins node. In the Details Pane, double-click the SMTP Filter. Click the SMTP Commands tab. (See Figure 7.1.)

Figure 7.1. The SMTP Commands Tab

The settings on the SMTP Commands tab are mediated by the SMTP filter component. The SMTP Message Screener does not evaluate SMTP commands and does not protect against buffer overflow conditions. The commands in the list are limited to a predefined length. If an incoming SMTP connection sends a command that exceeds the length allowed, the connection is dropped. In addition, if a command that is sent over the SMTP channel is not on this list, it is dropped. (See Figure 7.1.)

The ISA firewall’s DNS filter protects the DNS server published by the ISA firewall using Server Publishing Rules. You can access the configuration interface for the DNS filter’s attack prevention configuration page in the Intrusion Detection dialog box. Expand the server name and then expand the Configuration node. Click the General node.

In the Details Pane, click the Enable Intrusion Detection and DNS Attack Detection link. In the Intrusion Detection dialog box, click the DNS Attacks tab. On the DNS Attacks tab, put a checkmark in the Enable detection and filtering of DNS attacks checkbox. (See Figure 7.2.)

Figure 7.2. The DNS Attacks Tab

Once detection is enabled, you can then enable prevention. You can protect yourself from three attacks:

The DNS host name overflow and DNS length overflow attacks are DNS denial-of-service (DoS) type attacks. The DNS DoS attack exploits the difference in size between a DNS query and a DNS response, in which all of the network’s bandwidth is consumed by bogus DNS queries. The attacker uses the DNS servers as “amplifiers” to multiply the DNS traffic.

The attacker begins by sending small DNS queries to each DNS server that contains the spoofed IP address of the intended victim. The responses returned to the small queries are much larger, so if a large number of responses are returned at the same time, the link will become congested and denial of service will take place.

One solution to this problem is for administrators to configure DNS servers to respond with a “refused” response, which is much smaller than a name resolution response, when they receive DNS queries from suspicious or unexpected sources.

You can find detailed information for configuring DNS servers to prevent this problem in the U.S. Department of Energy’s Computer Incident Advisory Capability information bulletin J-063, available at www.ciac.org/ciac/bulletins/j-063.shtml.

The POP Intrusion Detection filter protects POP3 servers you publish via ISA firewall Server Publishing Rules from POP services buffer overflow attacks. There is no configuration interface for the POP Intrusion Detection filter.

The SOCKS v4 filter is used to accept SOCKS version 4 connection requests from applications written to the SOCKS version 4 specification. Windows operating systems should never need to use the SOCKS filter because you can install the Firewall client on these machines to transparently authenticate to the ISA firewall and support complex protocol negotiation.

For hosts that cannot be configured as Firewall clients, such as Linux and Mac hosts, you can use the SOCKS v4 filter to support them. The SOCKS v4 filter is disabled by default. To enable the filter, open the Microsoft Internet Security and Acceleration Server 2006 management console, expand the server name, and then expand the Configuration node. Click the Add-ins node. In the Details Pane, right-click the SOCKS V4 filter and click Enable.

You will need to configure the SOCKS V4 filter to listen on the specific network(s) for which you want it to accept connections. Double-click the SOCKS V4 filter. In the SOCKS V4 Filter Properties dialog box, click the Networks tab. On the Networks tab, you can configure the Port on which the SOCKS filter listens for SOCKS client connections. Next, put a checkmark in the checkbox next to the network for which you want the SOCKS filter to accept connections. Click Apply and then click OK. (See Figure 7.3.)

Figure 7.3. The SOCKS V4 Filter Properties Dialog Box

The SOCKS v4 filter supports SOCKS v4.3 client applications. The SOCKS filter is a generic sockets filter that supports all client applications that are designed to support the SOCKS v4.3 specification. The SOCKS filter performs duties similar to that performed by the Firewall client. However, there are some significant differences between how SOCKS and the Firewall client work:

We always recommend that you use the Firewall client because of the impressive advantages it provides by allowing you the ability to authenticate all Winsock connections made through the ISA firewall. However, SOCKS is a good “second best” when you cannot install the Firewall client.

The FTP Access filter is used to mediate FTP connections between Protected Network clients and FTP servers on the Internet, and from external hosts and published FTP servers. The FTP Access filter supports both PASV and PORT (passive and standard) mode FTP connections.

The FTP Access filter is required for SecureNAT clients because FTP uses secondary connections for PORT-mode FTP connections. FTP is a complex protocol that requires outbound connections from the FTP PORT-mode client and new secondary inbound connections from the FTP server. While the Firewall client does not require application filter support for secondary connections, SecureNAT clients do require application layer filter support, which is why the ISA firewall dev team included the FTP Access application filter.

Stefaan Pouseele, an ISA Server MVP, has written an excellent article on the FTP protocol and how FTP challenges firewall security. Check out his article, How the FTP Protocol Challenges Firewall Security at http://isaserver.org/articles/How_the_FTP_protocol_Challenges_Firewall_Security.html.

There is no configuration interface for the FTP Access filter. However, if there is an Access Rule that applies to FTP connection, the right click menu on the Access Rule will allow you to Configure FTP. The Configure FTP option allows you to control whether or not FTP uploads are allowed.

The H.323 filter is used to support H.323 connections through the ISA firewall. To configure the H.323 filter, open the Microsoft Internet Security and Acceleration Server 2006 management console and expand the server name. Next, expand the Configuration node and click the Add-ins node. Double-click the H.323 Filter entry in the Details Pane.

In the H.323 Filter Properties dialog box, click the Call Control tab. You have the following options:

Click the Networks tab. On the Networks tab, put a checkmark in the checkbox to the left of the networks on which you want the H.323 filter to accept connections requests.

The MMS filter supports Microsoft Media Services connections through the ISA firewall for Access Rules and Server Publishing Rules. The MMS filter is an access filter that allows SecureNAT client access to the complex protocols and secondary connections required to connect to Microsoft Media Services hosted content. Firewall clients do not require the help of the MMS filter to connect to MMS servers. There is no configuration interface for the MMS filter.

The PNM filter supports connections for the Progressive Networks Media Protocol from Real Networks. The PNM filter is an access filter allowing SecureNAT client access to the complex protocols and secondary connection required to connect to Progressive Networks Media servers. There is no configuration interface for the PNM filter.

The PPTP filter supports PPTP connections through the ISA firewall for outbound connections made through Access Rules and inbound connections made through Server Publishing Rules. The ISA firewall’s PPTP filter differs from the ISA Server 2000 PPTP filter in that it supports both inbound and outbound PPTP connections. The ISA Server 2000 PPTP filter only supports outbound PPTP connections.

The PPTP filter is required by both SecureNAT and Firewall clients. In fact, a machine located on an ISA firewall protected network must be configured as a SecureNAT client to use the PPTP filter to connect to PPTP VPN servers through the ISA firewall. The reason for this is that the Firewall client does not mediate non-TCP/UDP protocols. The PPTP VPN protocol requires the use of the Generic Routing Encapsulation (GRE) protocol (IP Protocol 47) and TCP protocol 1723. The TCP session is used by PPTP for tunnel management.

When the outbound access to the PPTP protocol is enabled, the PPTP filter automatically intercepts the GRE and TCP connections made by the PPTP VPN client. You do not need to create an Access Rule allowing outbound access to TCP 1723 for VPN clients.

The RPC filter is used to mediate RPC connections to servers requiring Remote Procedure Calls (RPCs) for both outbound connections using Access Rules and inbound connections using Server Publishing Rules. This includes secure Exchange RPC publishing.

There is no configuration interface for the RPC filter.

The RTSP filter supports Microsoft Real Time Streaming Protocol connections through the ISA firewall for Access Rules and Server Publishing Rules. The RTSP filter is an access filter that allows SecureNAT client access to the complex protocols and secondary connections required to connect to Microsoft Real Time Streaming Protocol hosted content (such as that on Windows Server 2003 Microsoft Media Servers). Firewall clients do not require the help of the MMS filter to connect to MMS servers.

There is no configuration interface for the RTSP 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

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 7.4):

• Maximum header length

• Payload length

• Maximum URL length

• Verify normalization

• Block high bit characters

• Block responses containing Windows executable content

Figure 7.4. 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.htm. 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.

ISA Firewall Tip

Remember that your HTTP policy is configured on a per-rule basis. Because you can configure HTTP policy on a per-rule basis, you can enable these settings for some rules, and disable them for other rules. This per-rule HTTP policy configuration option provides you a great deal of flexibility in what content is available from specific sites to specific users at specific times.

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 7.5). You have three options:

• Allow all methods

• Allow only specified methods

• Block specified methods (allow all others)

Figure 7.5. 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.

ISA Firewall Secret

Other HTTP methods you’ll encounter when allowing access to Microsoft applications include RPC_IN_DATA and RPC_OUT_DATA, which are used for securely publishing RPC over HTTP for Outlook 2003 clients. However, remember that the filter only blocks communications set in the HTTP policy filter, so be careful not to block methods you might require, even when you’re not completely sure what the exact methods you might require will be. We recommend that you thoroughly test your filter settings and discuss with the Web application admins and developers what methods are required.

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 7.6). 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 7.6. The Methods Dialog Box

The Extensions Tab

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

• Allow all extensions

• Allow only specified extensions

• Block specified extensions (allow all others)

• Block requests containing ambiguous extensions

Figure 7.7. 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 7.8.)

Figure 7.8. The Extensions Dialog Box

The Headers Tab

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

• Allow all headers except the following

• Server header

• Via header

Figure 7.9. 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 7.10.)

Figure 7.10. 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 7.11.)

Figure 7.11. 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 7.12.)

Figure 7.12. 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 7.13.)

Figure 7.13. 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 7.14 shows some example signatures blocking some commonly encountered applications that might be considered a major security risk for corporate networks.

Figure 7.14. Example Signatures

ISA Firewall Tip

Another signature you might want to create is one that blocks the <iframe src=“?”/> string in the response body. This string can potentially peg the processor on the victim machine and hang the operating system.

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 7.18.)

Figure 7.18. 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 7.19.)

Figure 7.19. 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 7.20, 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 7.20. The Network Monitor Display Window

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

Figure 7.21. The Signature Dialog Box

Another example of a dangerous application is Kazaa. Figure 7.22 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 7.22. Network Monitor Display Showing Kazaa Request Headers

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:

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.1
Host: 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:

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:

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:

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:

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:

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.

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

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.

Figure 7.25. The HTTP Properties Dialog Box

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 7.26 shows the configuration interface for the OWA Forms-Based Authentication filter, which is accessible from the Authentication dialog box for the Web listener.

Figure 7.26. The OWA Forms-Based Authentication Dialog Box

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.

You can access the Intrusion Detection dialog box by opening the Microsoft Internet Security and Acceleration Server 2006 management console, expanding the server name, and then expanding the Configuration node. Click the General node.

In the General node, click the Enable Intrusion Detection and DNS Attack Detection link. This brings up the Common Attacks tab.

On the Common Attacks tab, put a checkmark in the Enable intrusion detection checkbox. Put a checkmark to the left of each of the attacks you want to prevent. If you enable the Port scan attack, enter values for the Detect after attacks ... well-known ports and Detect after attacks on ... ports. (See Figure 7.27.)

Figure 7.27. The Common Attacks Tab

You can disable logging for packets dropped by the Intrusion Detection filter by removing the checkmark from the Log dropped packets checkbox.

The ISA firewall’s DNS filter protects DNS servers published by the ISA firewall using Server Publishing Rules. You can access the configuration interface for the DNS filter’s attack prevention configuration page in the Intrusion Detection dialog box. Expand the server name and then expand the Configuration node. Click the General node.

In the Details Pane, click the Enable Intrusion Detection and DNS Attack Detection link. In the Intrusion Detection dialog box, click the DNS Attacks tab. On the DNS Attacks tab, put a checkmark in the Enable detection and filtering of DNS attacks checkbox. (See Figure 7.28.)

Figure 7.28. The DNS Attacks Tab

Once detection is enabled, you can enable prevention, and protect yourself from three attacks:

The DNS host name overflow and DNS length overflow attacks are DNS DoS type attacks. The DNS DoS attack exploits the difference in size between a DNS query and a DNS response, in which all of the network’s bandwidth is tied up by bogus DNS queries. The attacker uses the DNS servers as “amplifiers” to multiply the DNS traffic.

The attacker begins by sending small DNS queries to each DNS server that contain the spoofed IP address of the intended victim. The responses returned to the small queries are much larger, so that if there are a large number of responses returned at the same time, the link will become congested and denial of service will take place.

One solution to this problem is for administrators to configure DNS servers to respond with a “refused” response, which is much smaller than a name resolution response, when they receive DNS queries from suspicious or unexpected sources.

Detailed information for configuring DNS servers to prevent this problem is contained in the U.S. Department of Energy’s Computer Incident Advisory Capability information bulletin J-063, available at http://www.ciac.org/ciac/bulletins/j-063.shtml.

You can configure what IP Options are allowed through the ISA firewall and whether IP Fragments are allowed through. Figures 7.29 and 7.30 show the configuration interfaces for IP Options filtering and IP Fragment filtering. Figure 7.31 shows a dialog box warning that enabling Fragment filtering may interfere with L2TP/IPSec and streaming media services.

Figure 7.29. The IP Options Tab

Figure 7.30. The IP Fragments Tab

Figure 7.31. The IP Fragment Filter Warning Dialog Box