Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 2)

If you would like to read the other parts in this article series please go to:

• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 1)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 3)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 4)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 5)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 6)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 7)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 8)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 9)
• Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 10)

Introduction

In Part 1 of this multi-part series, we discussed the importance of enabling inbound acces

s through TMG to your corporate network, in order to provide the “broad network access” that is an essential characteristic of private cloud computing. We then talked about what web publishing rules bring to the table in this regard, and how TMG can act as a reverse proxy to published web and FTP sites.

In Part 2, we continue the discussion by addressing three more of TMG’s capabilities that are enabled by Web Publishing rules:

• Authentication of users before they reach the published web server to increase security.
• Port and Protocol Redirection to published web and FTP servers.
• Conservation of IP addresses by publishing multiple sites on a single address or collection of addresses.

Authentication of users before they reach the published web server

One of the more interesting features in the TMG firewall’s web publishing feature set is the ability to “pre-authenticate” users before they connect to published resources. This enables you to carry out both authentication and authorization before the connection is forwarded to the published web server.

When you enable pre-authentication at the TMG firewall, you configure the Web Publishing Rule to use the type of authentication that you want the external web user to use when connecting to the TMG firewall.

You should note that the user in this scenario doesn’t know that he’s connecting to the TMG firewall, because the TMG firewall is impersonating the web site, so as far as the external user is concerned, that user is connecting to the web site to which he wanted to connect and is authenticating against that web site.

After the user authenticates with the TMG firewall using the authentication protocol that you have specified, the TMG firewall will then check to determine whether that user is authorized to connect to the published web site using that Web Publishing Rule. If the user successfully authenticates, but is not authorized to reach the site, then the connection will be dropped. If the user successfully authenticates and is authorized to connect to the published web site, then the connection will be forwarded to the published web site.

The TMG firewall also has the ability to forward the credentials that are presented by the user through a process known as delegation of authentication. In this scenario, the TMG firewall will first authenticate the user against the authentication repository (typically Active Directory). If that authentication attempt succeeds, then the credentials will be forwarded to the published web server so that the web server can also authenticate the user. This enables the user to authenticate with the TMG firewall and the published web server without enabling the user to actually directly communicate with the published web server, which is much more secure than allowing the external web user to connect to the web server before being authenticated and authorized.

Pre-authentication of users is very helpful in preventing denial of service attacks and other attacks that leverage anonymous connections to compromise a web server. In addition, you get robust logging for all of the connections to the published web server and these log entries will also have the number of the user who logged on, or tried to log on, associated with the name of the Web Publishing Rule so that you can do auditing and possibly forensics if you need to do so in the future.

Port and Protocol Redirection to published web and FTP server

You probably know that there are a number of ways you can make multiple web sites available on a single web server, such as assigning each site a separate IP address, or assigning each site the same IP address but using a different port, or even using a single IP address and a different “host name” that is associated with each of the sites hosted on the same web server. TMG enables you to support each of these methods.

When you configure a Web Publishing Rule on the TMG firewall, you have the option to forward to a different port number than the port number on which the connection was initially established, or forward the connection to a different host name than the host name on which the connection was established. This gives you a great deal of flexibility at the firewall level because you don’t have to change the way that you’ve set up your web server’s configuration to support the firewall web publishing capabilities. The TMG firewall will work with whatever scheme you are currently employing to publish multiple sites on a single server behind the TMG firewall.

In addition to publishing web sites, you can also publish FTP sites behind the TMG firewall using alternate port numbers. This allows you to host multiple FTP sites on a single FTP server using the same IP address by assigning different port numbers to the FTP sites. The TMG firewall can then be configured to forward the HTTP connection it received from the external web client as an FTP connection to the FTP server, using the port number that you’ve assigned to the specific FTP site.

You can preserve IP address by publishing multiple sites on a single address or collection of addresses

IPv4 address exhaustion has already taken place and we have technically already run out of available IPv4 addresses. What this means to us is that it’s going to get harder and harder to obtain large blocks of IPv4 addresses that we will want to use to publish our internal resources to users on the Internet. While those of us who already have large blocks reserved might feel comfortable, the time might come when you will be asked to return some of those addresses to your ISP. In addition, if you don’t already have a large block of addresses, it’s going to be almost impossible for you to obtain them in the future unless you want to move to IPv6 (in which case you will likely be able to obtain as many addresses as you like and you will never run out of addresses – but the transition can be time consuming and costly). Eventually, that’s what we’ll all do, but in the meantime, you need solutions for today.

To help you deal with the current situation of a limited number of IP addresses available to use for web publishing, the TMG firewall enables you to publish multiple web sites using the same IP address. When you configure the Web Publishing Rule, you specify in the rule the FQDN and path that apply to the rule and then you configure it so that when the request matches that FQND and path, TMG will forward the connection to a specific web server on the internal network, the server that you want to publish using that rule. This rule will also be bound to one or more IP addresses on the external interface of the TMG firewall.

You can then create a second and subsequent rules that contain different FQDNs and paths, which publish other servers on the internal network that you want to publish for external users on the Internet. These rules can also be bound to the same IP address. The TMG firewall is able to forward the connections to the correct web servers because when the connections are received on the same IP address, the TMG firewall’s web proxy service is able to “look at” the details of the connection request. The TMG firewall will be able to “see” the FQDN and path that are included in the request and match that information to one of the Web Publishing Rules that are configured on the TMG firewall. With that information, the TMG firewall will be able to forward the connection to the correct web server on the internal network.

This works great when you publish HTTP sites. However (isn’t there always a “however”?), it becomes a little more problematic when you are publishing SSL secured sites. The reason for this is that when you publish an SSL site, the TMG firewall is, in effect, impersonating the SSL site on the internal network. This means that the TMG firewall has a web site certificate bound to a “web listener” that is used to accept the incoming SSL connections from external hosts. The SSL web site certificate includes the name of the web server, and that name must match the name in the web client request that is received by the web listener on the TMG firewall. The problem is that you can only assign a single web site certificate per IP address on the TMG firewall. You cannot assign multiple web site certificates to the same IP address on the TMG firewall. This makes it almost impossible to publish multiple SSL sites using the same IP address on the external interface of the TMG firewall.

The good news is that there is a potential workaround for this, but it has some security implications and security administrators will not be happy with this. You do have an option to use a “wildcard certificate”. When you use a wildcard certificate, the name on the web site certificate will be in the form of *.domain.com. You can then use this certificate to publish any host in “domain.com” and you can bind that certificate to the web listener on the TMG firewall. However, as I said, the security implications of using wildcard certificates is a big concern and therefore you will need to work out the security implications with your security team to determine whether this is a viable option.

If you are interested in more information on the potential security issues with wildcard certificates, please see this Eweek article.

Summary

In this, Part 2 of our comprehensive overview of web and server publishing rules on TMG 2010, we looked at three more of the capabilities you get with web publishing rules. Specifically, we discussed how you can increase security by authenticating users before they reach the published web server, using port and protocol redirection to published web and FTP servers, and how you can conserve IP addresses by publishing multiple sites on a single IP address or collection of IP addresses.

In Part 3, we will delve into how you can use advanced authentication mechanisms such as RADIUS, SecurID, One-time Password (OTP) authentication and Kerberos Constrained Delegation (KCD).