Chapter 8: Publishing Network Services with ISA 2004 Firewalls - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Chapter 8: Publishing Network Services with ISA 2004 Firewalls

Overview of Web Publishing and Server Publishing

Web Publishing and Server Publishing Rules allow you to make servers and services on ISA firewall Protected Networks available to users on both protected and non-protected networks. Web and Server Publishing Rules allow you to make popular services, such as SMTP, NNTP, POP3, IMAP4, Web, OWA, NNTP, Terminal Services, and many more available to users on remote networks or on other Internal or Perimeter Networks.

Web Publishing Rules and Server Publishing Rules provide very different feature sets and are used for very different purposes. In general, Web Publishing Rules should be used to publish Web servers and services, and Server Publishing Rules should be used to publish non-Web servers and services. There are exceptions to these rules, and we will discuss these exceptions in this chapter.

We will begin the chapter with a discussion of the features and capabilities of Web and Server Publishing Rules. After this general overview of Web and Server Publishing Rules, we will go into the details of how to create and configure Web and Server Publishing Rules. We will then complete this chapter with several scenarios that demonstrate how Web and Server Publishing Rules are used on production networks.

Web Publishing Rules

Web Publishing Rules are used to publish Web sites and services. Web Publishing is sometimes referred to as 'reverse proxy.' When you publish a Web site, the ISA firewall's Web Proxy filter always intercepts the request and then proxies the request to the Web site published by the Web Publishing Rule.

Web Publishing Rules sport the following features:

Provide proxied access to Web sites protected by the ISA firewall

Perform deep application-layer inspection of connections made to published Web sites

Path redirection

Pre-authentication of connections made to published Web sites (Forward Basic authentication credentials)

Reverse Caching of published Web sites

Ability to publish multiple Web sites with a single IP address

Ability to re-write URLs returned by the published Web site using the ISA firewall's Link Translator

Support for forwarding either the ISA firewall's IP address or the original client's IP address to the Web site

Support for SecurID authentication

Support for RADIUS authentication

Ability to schedule when connections are allowed to Published Web sites

Port and Protocol Redirection

Let's look at each of these features in more detail.

Provide Proxied Access to Web Sites Protected by the ISA firewall

Web Publishing Rules provide proxied access to Web sites located on an ISA firewall Protected Network. Any Network that is not part of the default External Network is considered an ISA firewall Protected Network. A proxied connection is more secure than a routed and NATed connection because the entire communication is deconstructed and reconstructed by the ISA firewall. This allows the ISA firewall to perform very deep application-layer inspection of Web requests made to published Web sites that have been published using Web Publishing Rules.

The ISA firewall's Web Proxy filter handles all incoming Web connections made through Web Publishing Rules. Even when you unbind the Web Proxy filter from the HTTP protocol definition, the Web Proxy filter is always enabled for Web Publishing Rules. This is a security decision made by the ISA firewall team. They determined that non-proxied incoming connections to Protected Network Web servers should always be proxied to allow for the highest degree of protection for published Web servers.

Perform Deep Application-Layer Inspection of Connections Made to Published Web Sites

One of the major advantages of using Web Publishing Rules to publish Web sites on protected networks is the ISA firewall's ability to perform very deep application-layer inspection on all connections made to published Web sites. This deep application-layer inspection prevents attackers from sending malicious commands or code to the published Web site. This allows the ISA firewall to stop attacks at the perimeter and prevents the attacker from ever reaching the published Web server itself.

Deep application-layer inspection for Web requests is the responsibility of the ISA firewall's HTTP Filter. The ISA firewall's HTTP filter allows you to control virtually any aspect of an HTTP communication and block or allow connections based on almost any component of an HTTP communication.

Examples of how you can control connections to published Web sites include:

Setting the maximum payload length

Blocking high-bit characters

Verifying normalization

Blocking responses containing Windows executable content

Setting the exact HTTP methods that you want to allow to the published Web site and block all others

Allowing only a specific list of file extensions

Allowing only a specific list of Request or Response headers

Creating fine-tuned signatures that can block connections based on Request URLs, Request headers, Request body, Response headers, or Response body

We will go into some of the details of the HTTP Security Filter (HTTP Filter) later in this chapter, and we will also go into the deep details of the HTTP Security Filter in Chapter 10 on the ISA firewall's application-layer filtering feature set.

Path Redirection

Web Publishing Rules allow you to redirect connections based on the path indicated by the external user. Path redirection allows you to redirect connections based on the user's indicated path to an alternate directory on the same Web server, or to another Web server entirely.

For example, a user sends a request to www.msfirewall.org/kits. You want the request to be forwarded to a server named WEBSERVER1 and to a directory on the server named /deployment_kits. You can configure the Web Publishing Rule to direct the path in the request (which is /kits) to the path on the internal Web server, /deployment_kits.

You can also use path redirection to forward the request to another Web server entirely. For example, suppose users submit requests for the following sites:

www.msfirewall.org/scripts

www.msfirewall.org/deployment_kits

You can create two Web Publishing Rules, one for incoming requests to www.msfirewall.org/scripts and one for www.msfirewall.org/deployment_kits. The request for www.msfirewall.org/script can be redirected to a Web server named WEBSERVER1, and the second can be redirected to WEBSERVER2. We can even redirect the request to alternate paths on each Web server.

We will go over some examples of path redirection in the scenarios section of this chapter.

Pre-authentication of Connections Made to Published Web Sites

Web Publishing Rules can be configured to forward basic authentication credentials (basic delegation). This means that you can pre-authenticate the user at the ISA firewall. This pre-authentication prevents unauthenticated connections from ever reaching the Web server. Pre-authentication blocks attackers and other malicious users from leveraging unauthenticated connections to exploit known and unknown weaknesses in Web servers and applications.

One popular use of pre-authentication is for OWA Web sites. Instead of allowing unauthenticated connections from reaching the OWA Web site, the ISA firewall's Web Publishing Rule for the OWA Web site can be configured to authenticate the user. If

the user successfully authenticates with the ISA firewall, then the connection request is passed to the OWA site. If the user cannot authenticate successfully with the ISA firewall, then the connection attempt is dropped at the firewall and never reaches the published Web site.

Pre-authentication also allows you to control who can access Web sites. You can configure Web Publishing Rules to allow only certain user groups to access the published Web site. So even if users are able to authenticate successfully, they will only be able to access the published Web site if they have permission to do so. In this way, the ISA firewall's Web Publishing Rules allow authentication and authorization for access to published Web sites.

The ISA firewall's delegation of basic authentication option allows the ISA firewall to authenticate the user and then forward the user credentials to the published Web site when the Web site request credentials. This prevents the user from being subjected to double authentication prompts. Instead of the user answering the Web site's request for authentication, the ISA firewall answers the request after successfully authenticating the user.

Reverse Caching of Published Web Sites

The ISA firewall can cache responses from Web sites published via Web Publishing Rules. Once a user makes a request for content on the published Web site, that content can be cached (stored) on the ISA firewall. When subsequent users make requests for the same content on the published Web server, the content is served from the ISA firewall's Web cache instead of being fetched from the Web server itself.

Caching responses from published Web sites reduces the load on the published Web server and on any network segments between the ISA firewall and the published Web server. Since the content is served from the ISA firewall's Web cache, the published Web server isn't exposed to the processing overhead required to service those Web requests. And because the content is served from the ISA firewall's Web cache instead of the published Web site, network traffic between the ISA firewall and the published Web site is reduced, which increases overall network performance on the corporate network.

You can also control the reverse caching on content. You may want users to always receive the freshest versions of content in some locations on your published Web server, while allowing the ISA firewall to cache other content on the published Web servers for a pre-defined time period. You can create cache rules on the ISA firewall in order to have fine-tuned control over what content is cached and how long that content is cached.

Ability to Publish Multiple Web Sites with a Single IP Address

Web Publishing Rules allow you to publish multiple Web sites using a single IP address on the external interface of the ISA firewall. The ISA firewall can do this because of its ability to perform stateful application-layer inspection. Part of the ISA firewall's stateful application-layer inspection feature set is its ability to examine the host header on the incoming request and make decisions on how to handle the incoming request based on that host header information.

For example, suppose you have a single IP address on the external interface of the ISA firewall. You want to publish two Web servers on an ISA firewall Protected Network. Users will access the Web sites using the URLs www.msfirewall.org and www.tacteam.net. All you need to do is create two Web Publishing Rules. One of the Web Publishing Rules will listen for incoming connections for www.msfirewall.org and forward those requests to the msfirewall.org server on the ISA firewall Protected Network, and the other Web Publishing Rule will listen for requests to www.tacteam.net and forward those requests to the Web site on the ISA firewall Protected Network responsible for the tacteam.net Web site.

The key to making this work, as we'll discuss later in this chapter, is to make sure that the public DNS resolves the fully-qualified domain names to the IP address on the external interface of the ISA firewall. Once the DNS issue is addressed, publishing two or two hundred Web sites with a single IP address is very simple using the ISA firewall's Web Publishing Rules.

Ability to Rewrite URLs Returned by the Published Web Site using the ISA Firewall's Link Translator

The ISA firewall's link translator can rewrite the responses that published Web servers send to users making requests. The link translator is useful when publishing Web sites that include hard-coded URLs in their responses, and those URLs are not accessible from remote locations.

For example, suppose you publish a Web site that hard codes the URLs in its responses and the hard-coded URLs include the private names of servers on the Protected Network. Such URLs would have the form Chapter 10 on application-layer filtering.

Support for Forwarding either the ISA Firewall's IP Address, or the Original Web Client's IP Address to the Web Site

One of the limitations with Web Publishing Rules in ISA Server 2000 was that logs on the published Web server always showed the IP address for the internal network adapter of the ISA Server. When you published Web servers using Web Publishing Rules, the source IP address of the client connecting to the published Web server was replaced with the internal IP address of the ISA Server. This was a major barrier to adoption for many potential ISA Server administrators because they already had sunk significant costs into log analysis software installed on the published Web servers. Their only option was to use Server Publishing Rules, which isn't a good option because Server Publishing Rules do not confer the same high level of security as Web Publishing Rules.

The good news is that the new ISA firewall gives you the choice between forwarding the ISA firewall's IP address to the published Web server or forwarding the actual remote Web client's IP address to the published Web server. If you don't need the actual client's IP address in the Web server's log files, then use the default option, which is to replace the client IP address with the ISA firewall's network interface address. If you need to preserve the remote Web client's IP address, then you can choose the option to preserve the IP address.

We'll discuss the advantages and disadvantages of each approach when we cover the details of creating and configuring Web Publishing Rules later in this chapter.

Support for SecurID Authentication

RSA's SecurID is a two-factor authentication mechanism that requires that the user have something (the SecurID token) and know something (their user credentials). The ISA firewall comes with built-in support for SecurID authentication for Web servers and services published via Web Publishing Rules.

Support for RADIUS Authentication

Some organizations will choose to put the ISA firewall in a location where making the firewall a member of the user domain is not the best option. For example, if you have a back-to-back firewall configuration where the front-end firewall is an ISA firewall, you should not make the front-end ISA firewall a member of the user domain. You can still take advantage of the domain user database for authentication and authorization by using RADIUS for Web Publishing Rule authentication.

The ISA firewall can be configured as a RADIUS client to a RADIUS server on the corporate network. The RADIUS server can then be configured to authenticate users against the Active Directory or any other RADIUS-compliant directory on the corporate network. RADIUS authentication can be used for both inbound and outbound connections through the ISA firewall's Web Proxy filter. Setting up Web Publishing Rules using RADIUS is very easy and allows the ISA firewall support back-to-back firewall scenarios where the ISA firewall is the front-end firewall.

Ability to Schedule when Connections are Allowed to Published Web Sites

ISA Firewall Web Publishing Rules allow you to control when users can access the published Web site. You may have some Web sites that you only want accessed during work hours, and other Web sites that have high bandwidth requirements that you only want accessed during off-hours. You can control when users access published Web sites by applying either built-in or custom schedules to your Web Publishing Rules.

Port and Protocol Redirection

Web Publishing Rules allow you to perform both protocol and port redirection. Port redirection allows the ISA firewall to accept a connection request on one port and then forward that request to an alternate port on the published Web server. For example, the ISA firewall can listen to incoming requests on its Web listener on TCP port 80 and then redirect that connection to TCP 8888 on the published Web server on the ISA firewall Protected Network.

You can also perform protocol redirection using Web Publishing Rules. In contrast to port redirection, where the only change is the destination port, the ISA firewall's support for protocol redirection allows you to publish FTP sites using Web Publishing Rules. The incoming HTTP GET request made to the Web Publishing Rule's Web listener is transformed to an FTP GET and forwarded to the published FTP site on a ISA firewall Protected Network. Web Publishing Rules support protocol redirection from HTTP to FTP.

Server Publishing Rules

Like Web Publishing Rules, you can use Server Publishing Rules to provide access to servers and services on ISA firewall Protected Networks. The following features and capabilities characterize Server Publishing Rules:

Server Publishing Rules are a form of reverse NAT or 'Port Mapping' and do not proxy the connection.

Almost all IP level and TCP/UDP protocols can be published using Server Publishing Rules.

Server Publishing Rules do not support authentication.

Application-layer filtering can be applied to a defined subset of Server Published protocols.

You can configure port overrides to customize the listening ports and the port redirection. You can also lock down the source ports the requesting clients use to connect to the published server.

You can use IP address controls over who can access published resources.

The external client source IP address can be preserved or can be replaced with the ISA firewall's IP address.

You can apply schedules that limit when the published server can be accessed via the Server Publishing Rule.

Support for 'port redirection' (or PAT - Port address translation) where connections can be received on one port and redirected to another port, providing the same functionality as that seen in many 'hardware' firewall solutions.

Let's look at each of these in a bit more detail.

Server Publishing Rules are a Form of Reverse NAT or 'Port Mapping' and do not Proxy the Connection

Server Publishing Rules are a form of either reverse NAT or port mapping, depending on whether you have a NAT or route relationship between the published server and the host that is connecting to the published server via the Server Publishing Rule. The Server Publishing Rule configures the ISA firewall to listen on a specific port and then forwards those connections to the published server on an ISA firewall Protected Network.

In contrast, Web Publishing Rules proxy the requests to the published Web server. Server Publishing Rules just change the source port and IP address before forwarding the connection to the published server. Proxied connections are completely deconstructed and reconstructed by the ISA firewall, and thus, confer a much higher level of application-layer inspection than Server Publishing Rules.

Almost All IP Level and TCP/UDP Protocols Can be Published using Server Publishing Rules

Web Publishing Rules only accept HTTP and HTTPS connections and forward them as HTTP, HTTPS, or FTP connections. In contrast, Server Publishing Rules can be used to publish almost any IP Level, TCP, or UDP protocol. This provides a great deal of flexibility in what services can be made available to hosts via Server Publishing Rules.

Server Publishing Rules do not Support Authentication

One of the major drawbacks of Web Publishing Rules compared to Server Publishing Rules is that Server Publishing Rules do not support pre-authentication at the ISA firewall. Authentication must be done by the server published by the Server Publishing Rule.

Application-Layer Filtering can be Applied To a Defined Subset of Server Published Protocols

Deep stateful application-layer inspection for connections made through Web Publishing Rules is performed by the ISA firewall's HTTP filter. Server Publishing Rules also support application-layer inspection through the use of Application Filters. The ISA firewall comes out of the box with the following application filters:

DNS (security filter)

FTP Access Filter

H.323 Filter

MMS Filter

PNM Filter

POP Intrusion Detection Filter (security filter)

PPTP Filter

RPC Filter (security filter)

RTSP Filter

SMTP Filter (security filter)

SOCKS v4 Filter

Web Proxy Filter (security filter)

A number of these filters are used to mediate complex protocols in the same way that NAT editors allow the use of complex protocols through a NAT device. Examples of types of access filters are the H.323 Filter, the MMS Filter, and the RTSP filter. In contrast, there are several application filters whose main job is to secure connections made through the ISA firewall by performing compliance testing against the connection. Example of these security filters are the DNS filter, POP Intrusion Detection Filter, and the RPC Filter.

Some of the application-layer filters perform both duties. They mediate complex protocol management for SecureNAT clients, and they also secure the connections they mediate. Filters fitting into this category include the FTP Access Filter and the RPC Filter.

We will cover application-layer filters in detail in Chapter 10.

Configuring Port Overrides to Customize the Listening Ports and the Port Redirection

Within each Server Publishing Rule is the ability to control the listening port, the destination port, and the port that the requesting client can use as a source port to access the Server-Published server. This provides you very granular control over port redirection (port mapping) for any server you publish using Server Publishing Rules.

You can use IP Address Controls Over who can Access Published Resources

Although Server Publishing Rules do not allow you to pre-authenticate users at the ISA firewall, you can configure Server Publishing Rules to limit IP addresses that can connect to the published server via the Server Publishing Rule. This type of IP address-based access control is used for publishing servers that should have limited access. An example of such a server is a Terminal Server on the corporate network that only administrators located at pre-defined addresses can access.

External Client Source IP Address can be Preserved Or Replaced with the ISA Firewall's IP address

In ISA Server 2000, Server Publishing Rules always preserved the original client IP address when it forwarded the connections to the published server on the internal network. The new ISA firewall improves on this by allowing you to choose to either preserve the original client IP address or replace the original client IP address with the IP address of the ISA firewall itself.

Apply Schedules Limiting when the Published Server can be Accessed via the Server Publishing Rule

Like Web Publishing Rules, Server Publishing Rules can be put on a schedule so that connections can only be established to the published server during the times allowed by the schedule. You can use one of the built-in schedules or create your own custom schedules.

Support for Port Redirection or PAT (Port Address Translation)

Like Web Publishing Rules, Server Publishing Rules allow you to customize how connections are forwarded to the published server and what ports are used to accept and forward the connection requests. For example, you might want to accept incoming connections for your private SMTP server on TCP port 26 and forward them to TCP port 27 on a published SMTP server. You can do this using the ISA firewall's port redirection (PAT) feature.