In the chapter, application filters and Web filters will be provided as solutions.
INTRODUCTION
The ISA firewall is able to perform both stateful filtering and stateful application layer inspection.
Its stateful filtering feature set makes it a network layer stateful firewall in the same class as any
hardware firewall that performs stateful filtering at the network and transport layers. Stateful filtering
is often referred to as stateful packet inspection, which is a bit of a misnomer because packets are Layer 3
entities, and to assess connection state, Layer 4 information must be assessed.
However, in contrast to traditional packet filter-based stateful hardware firewalls, the ISA firewall is
able to perform stateful application layer inspection, which enables it to fully inspect the communication
streams passed by it from one network to another. In contrast to stateful filtering where only the
network and transport layer information is filtered, true stateful inspection requires that the firewall be
able to analyze and make decisions on all layers of the communication, including the most important
layer, the application layer.
The Web filters perform stateful application layer inspection on communications handled by the
ISA firewall’s Web Proxy components. The Web Proxy handles connections for HTTP, HTTPS (SSL),
and HTTP tunneled FTP connections. The Web filters take apart the HTTP communications and
expose them to the ISA firewall’s application layer inspection mechanisms, examples of which include
the HTTP Security filter and the OWA forms-based authentication filter.
The Application filters are responsible for performing stateful application layer inspection on
non-HTTP protocols, such as SMTP, POP3, and DNS. These application layer filters also take apart
the communication and expose them to deep stateful inspection at the ISA firewall.
Web and Application filters can perform two duties:
- Protocol access
- Protocol security
Protocol access allows access to protocols that require secondary connections. Complex protocols may
require more than one connection, either inbound or outbound through the ISA firewall. SecureNAT
clients require these filters to use complex protocols because the SecureNAT client does not have the
power of the Firewall client. In contrast to the Firewall client that can work together with the ISA firewall
to negotiate complex protocols, the SecureNAT client is a simple NAT client of the ISA firewall and
requires the aid of application filters to connect using these complex protocols (such as FTP or MMS).
Protocol security protects the connections moving through the ISA firewall. Protocol security
filters such as the SMTP and DNS filters inspect the communications that apply to those filters and
block connections that are deemed outside of secure parameters. Some of these filters block
connections that may represent buffer overflows (such as the DNS and SMTP filters), and some of
them perform much deeper inspection and block connections or content based on policy (such as
the SMTP Message Screener).
APPLICATION FILTERS
The ISA firewall includes a number of Application filters. In this section, we discuss:
- SMTP filter
- DNS filter
- POP Intrusion Detection filter
- SOCKS V4 filter
- FTP Access filter
- H.323 filter
- MMS filter
- PNM filter
- PPTP filter
- RPC filter
- RTSP filter
The SMTP Filter
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.)
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 DNS Filter
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.)
Once detection is enabled, you can then enable prevention. You can protect yourself from three
attacks:
- DNS host name overflow
- DNS length overflow
- DNS zone transfer
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 confi guring 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
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
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.)
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:
- The Firewall client is a generic Winsock Proxy client application. All applications designed
to the Windows Sockets specification will automatically use the Firewall client.
- The SOCKS filter supports applications written to the SOCKS v4.3 specification.
- When the Firewall client is installed on the client machine, all Winsock applications
automatically use the Firewall client, and user credentials are automatically sent to the ISA
firewall. In addition, the Firewall client will work with the ISA firewall service to manage
complex protocols that require secondary connections (such as FTP, MMS, and many others).
- The SOCKS client must be configured on a per-application basis. Each application must be
explicitly configured to use the ISA firewall as its SOCKS server. When the application is
configured to use the ISA firewall as its SOCKS server, the SOCKS filter will manage
complex protocols for the SOCKS client application.
- The SOCKS 4.3a filter included with the ISA firewall does not support authentication.
SOCKS 5 introduced the capability to authenticate the client application that attempts to
access content through the SOCKS proxy.
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
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.
ISA FIREWALL SECRET
If you plan to support PORT-mode FTP client connections, make sure that IP Routing
is enabled on the ISA firewall (the default setting). When IP Routing is enabled, the
secondary connections are handled in kernel mode rather than user mode. This
kernel-mode handling of the secondary connections (which are data transfers from
the FTP server to the FTP client) will significantly increase performance.
|
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
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:
- Use this Gatekeeper
- Use DNS gateway lookup and LRQs for alias resolution
- Allow audio
- Allow video
- Allow T120 and application sharing
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
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
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
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 (GR E) 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 GR E 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
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
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.
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 7.4):
- Maximum header length
- Payload length
- Maximum URL length
- Verify normalization
- Block high bit characters
- Block responses containing Windows executable content
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 fi rst 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)
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
defi nitely 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.
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
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.)
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
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.)
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 "fi ngerprint" your Web server. (See Figure 7.11.)
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.
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.
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 identifi ed 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.
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.
|
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 2006 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 7.15 shows an example of a connection that was blocked
because the URL contained a string that was disallowed by the HTTP Security filter.
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 in the SDK kit located
at http://www.microsoft.com/downloads/details.aspx?familyid=16682C4F-7645-4279-97E4-9A0C73
C5162E&displaylang=en 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 simplifi es 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 2006 management console.
In this section, we discuss how you can export and import an HTTP policy from and to a Web
Publishing Rule.
ISA FIREWALL TIP
Jim Harrison, the Godfather of ISA firewall scripting, has several attack prevention
tools and scripts on his site that automatically configure an HTTP policy as part of the
attack prevention and mitigation Configuration. Check out Jim’s fantastic ISA firewall
tools Web site at www.isatools.org.
|
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 2006 CD-ROM. Follow these steps to export the HTTP
policy from an existing Web Publishing Rule:
- Copy the HttpFilterConfig.vbs file 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 conforming that the information was successfully imported into
the rule (see Figure 7.16).
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 2006 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 conforming that the information was successfully imported into
the rule (see Figure 7.17).
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 fi gure out this information for yourself, especially for new and obscure
applications.
Your main tool in fi ghting 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 fi rst
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 confi guring 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.)
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.)
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.
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.
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.
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 7.1 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 7.2 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.
ISA FIREWALL TIP
You may not want to include the & character and .exe extension. You need to allow
.exe for downloading of the S/MIME control. However, because HTTP Security Filter
policy is applied on a per-rule basis, we suggest you create a separate rule allowing
access for specific Outlook Web Access needs, and order it before the rule that
blocks access based on Table 7.3. The allow rule would allow access only to the OWA
directory containing those controls. If you do not allow the & character in requests,
certain functions, like Calendaring, will not work correctly.
|
Table 7.3 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 Table 7.4 and Table 7.5.
Table 7.4 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 7.5 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 7.5 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 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:// prefi xes 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 specifi es 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.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:
- 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
ISA FIREWALL TIPS
- Don’t end the search string in the Link Translator dictionary with a terminating
character. For example, use http://SERVER1, not http://SERVER1/.
- When adding an entry for a site name, also add an entry with the site
name and port. For example, if you add the search string http://SERVER1 in
the Link Translator dictionary, also add the search string http://SERVER1:80.
- Use both http:// and https://.
- Use caution when changing directory structures, as this will affect the
settings in yoURLink Translation dictionary.
- Dictionaries with a large number of entries when applied to Web sites
that have many links requiring translation could detrimentally impact ISA
Server performance.
|
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 fi rst 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:
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 prefi x (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 prefi x (http instead of https) and internal server names.
In addition, after adding custom dictionary entries to fi x these problems, the source code of
the search results page contains JavaScript that includes references to the wrong prefi x, 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 7.23.)
- The dictionary entry appears in the list of dictionary entries. Click the Content Types
button. (See Figure 7.24.)
- 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.
ISA FIREWALL WARNING
The Web Publishing Rule must list an explicit fully qualifi ed domain name (FQDN) or
IP address in order to perform link translation. If you configure the Web Publishing
Rule to redirect for all incoming connections to the listener, you will see an error
dialog box informing you that you must use an explicit FQDN or IP address on the
Public tab of the Web Publishing Rule’s Properties dialog box.
|
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.
ISA FIREWALL WARNING
Be aware that disabling the HTTP filter for the HTTP protocol is a global setting and
affects all rules that use the HTTP filter. While the filter is still active for Web Proxy
clients, the Configuration interface for the HTTP filter is removed, and you will not
be able to configure the HTTP policy for the Web Proxy clients. This problem may be
solved in the future, and we will post this information at www.isaserver.org when we
find a solution to this problem. (See Figure 7.25.)
|
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 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.
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.
IP FILTERING AND INTRUSION DETECTION/INTRUSION PREVENTION
The ISA firewall performs intrusion detection and intrusion prevention. In this section, we discuss the
following intrusion detection and intrusion prevention features:
- Common Attacks Detection and Prevention
- DNS Attacks Detection and Prevention
- IP Options and IP Fragment Filtering
Common Attacks Detection and Prevention
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.)
You can disable logging for packets dropped by the Intrusion Detection filter by removing the
checkmark from the Log dropped packets checkbox.
DNS Attacks Detection and Prevention
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.)
Once detection is enabled, you can enable prevention, and protect yourself from three attacks:
- DNS host name overflow
- DNS length overflow
- DNS zone transfer
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 confi guring 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.
IP Options and IP Fragment Filtering
You can configure what IP Options are allowed through the ISA firewall and whether IP Fragments
are allowed through. Figure 7.29 and Figure 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.
Source Routing Attack
TCP/IP supports source routing, which is a means to permit the sender of network data to route the
packets through a specific point on the network. There are two types of source routing:
- Strict source routing The sender of the data can specify the exact route (rarely used).
- Loose source record route (LSRR) The sender can specify certain routers (hops)
through which the packet must pass.
The source route is an option in the IP header that allows the sender to override routing
decisions that are normally made by the routers between the source and destination machines. Source
routing is used by network administrators to map the network, or for troubleshooting routing and
communications problems. It can also be used to force traffic through a route that will provide the
best performance. Unfortunately, source routing can be exploited by hackers.
If the system allows source routing, an intruder can use it to reach private internal addresses on
the LAN that normally would not be reachable from the Internet, by routing the traffic through
another machine that is reachable from both the Internet and the internal machine.
Source routing can be disabled on most routers to prevent this type of attack. The ISA firewall
also blocks source routing by default.
SUMMARY
In this chapter, we discussed the ISA firewall’s application layer filtering feature set. We discussed the
two main types of application filters employed by the ISA firewall: access filters and security filters.
While we broke down the ISA firewall’s filters into these two main categories, this is not to say that
access filters are unsecure. Both the access filters and the security filters impose requirements that the
connections meet specifications of legitimate communications using those protocols.
We finished the chapter with a discussion of the ISA firewall’s intrusion detection and prevention
mechanisms. You learned about common network layer attacks that can be launched against the ISA
firewall and how the ISA firewall protects you against them.
|
Windows IT Pro
Register
