Web Publishing and Server Publishing Rules allow you to make servers and services on ISA firewall Protect 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 to different purposes. In general, Web Publishing Rules should always 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, however.
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 include the following features:
- Provide proxied access to Web sites protected by the ISA firewall
- Perform 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)
- Delegation of user 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 and RADIUS One-time Password authentication (two factor authentication)
- Support for RADIUS and LDAP 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 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 and provides a stark contrast to the limited security the typical “hardware” firewall can provide.
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 ISA Firewall 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 Security Filter. The ISA firewall’s HTTP Security 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:
- Set the maximum payload length
- Block high-bit characters
- Verify normalization
- Block responses containing Windows executable content
- Set the exact HTTP methods that you want to allow to the published Web site and block all others
- Allow only a specific list of file extensions
- Allow only a specific list of Request or Response headers
- Create fine-tuned signatures that can block connections based on Request URLs, Request headers, Request body, Response headers or Response body
Figure 1
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 a Chapter 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 for http://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:
- http://www.msfirewall.org/scripts
- http://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/scripts can be redirect 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.
Figure 2
Pre-authentication of Connections Made to Published Web Sites
Web publishing rules can be configured to forward authentication credentials to the destination Web server. ISA 2004 was limited to only basic delegation, but ISA 2006 provides a much richer selection of authentication delegation. This means that you can pre-authenticate the user at the ISA firewall before the connection is forwarded to the published Web server. 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 to 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.
Figure 3
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 permissions to do so. In this way, the ISA firewall’s Web Publishing Rules enforce authentication and authorization before access to published Web sites is allowed.
The ISA firewall’s authentication delegation 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 using a variety of methods, including authentication protocol transition. For example, the user might authenticate using a User Certificate, and then the user’s credentials can be forwarded as Kerberos authentication.
Delegation of authentication also 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 the ISA Firewall successfully authenticates the user.
Figure 4
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 performance and efficiency on the corporate network.
You can also control the reverse caching on content. You may wish users 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 to get 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 that request 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 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 Re-write URLs Returned by Published Web Site using the ISA Firewall’s Link Translator
The ISA firewall’s link translator can be used to re-write the responses published Web servers send to users making requests to the published Web server. 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 http://server1/documents or http://webserver2/users. Since these are not fully qualified domain names that are accessible from the Internet, the connections requests fail. This is a common problem with some SharePoint Portal Server Web sites.
The Link Translator solves this problem by re-writing the responses returned to the user accessing the Web site, so that the links http://server1/documents and http://webserver2/users are rewritten http://www.msfirewall.org/documents and http://www.tacteam.net/users, both of which are accessible from the Internet.
Figure 5
Link Translation is also useful in some SSL scenarios. For example, when you are not using SSL from the ISA firewall to the Web server, but you are using SSL between the Web client on the Internet and the ISA firewall, then the link translator can change the HTTP response returned by the Web server to an SSL response in the links presented to the user. This prevents the users from encountering broken links on the published Web page.
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 of the internal interface of the ISA Firewall. 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 Firewall. This was a major barrier to adopt for many potential ISA Firewall administrators because they already had significant sunk costs in log analysis software installed on the published Web servers. Their only option was to use Server Publishing Rules, which wasn’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.
Figure 6
Support for SecurID and RADIUS One-time Password Authentication
RSA’s SecurID is a two-factor authentication mechanism that requires that the users have something (the SecurID token) and know something (their user credentials). The ISA firewall comes with built-in support for SeurID authentication for Web servers and services published via Web Publishing Rules. ISA 2006 adds a second two-factor authentication mechanism – RADIUS One Time Passwords (OTP).
Figure 7
Support for RADIUS and LDAP 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 might not want to 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.
RADIUS does suffer from a lot of disadvantages and for this reason the ISA dev team upped the ante by allowing us to use LDAP authentication for Web Publishing Rules, which among other things, allows you to leverage Active Directory users and groups when setting your authorization requirements for Web Publishing Rules.
Figure 8
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.
Figure 9
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.
Figure 10
Certificate Restriction Policies
With the new ISA firewall (2006) you have a lot more control over how the ISA firewall handles certificates. For example, if you are using User Certificate authentication, you might want to make sure that the User Certificate was generated by a specific CA. In the past, the ISA firewall trusted all CAs in the ISA Firewall’s Root Certification Authorities machine certificate store. You can tighten things up by customizing the Web listener for the rule to have only a subset of CAs that you want the rule to trust, such as your corporate CA. This prevents users from presenting user certificates generated by other CAs that are out of your control. In addition, you can set other restrictions on the certificates presented by the users, such as that the certificate contain a specific OID.
Figure 11
Figure 12
Conclusion
I’ve spent a lot of time here at ISAserver.org explaining how to configure various aspects of the ISA firewall system, but I haven’t spent much time explaining what all these features do, which doesn’t help out folks who aren’t sure if the ISA firewall will do what they want to do, or those people who are trying to discovery what this ISA firewall is and what it does. In this article I went over the ISA firewall’s basic Web Publishing feature set. To get the details of Web Publishing, check out any of the OWA, OMA, Exchange ActiveSync, and RPC/HTTP publishing articles on this site. Thanks! –Tom.
