The subject of Web site certificates used by the ISA and TMG firewalls to impersonate the published Web Server came up the other day. The commentator mentioned that there really weren’t any explanations of why or how the ISA or TMG firewall uses these certificates and what’s important to know about Web site certificates.

First, the reason why you install certificates on the ISA Firewall is typically to support secure Web Publishing. When you do this, the external client can connect to the external interface of the ISA Firewall and terminate the SSL connection there. The ISA Firewall is able to do this because it has a certificate installed on it and bound to a Web Listener that allows the ISA Firewall to impersonate the published Web server.

But what do I mean by “impersonating” the published Web server? What exactly is being to make this impersonation work? Many people would think that maybe the ISA firewall is pretending to be an IIS server of some type, and that the browser had some kind of mechanism that allowed it to identify whether or not it was connected to an OWA or other Web site. While this would be a cool feature, that’s not what happens when the ISA firewall impersonates the Web server.

It’s actually very simple. When a external Web browser tries to connect to the secure Web site published by the ISA firewall, the first part of the SSL session setup between the client and server includes the ISA firewall sending the Web site certificate to the client. If the common or subject name on the Web site certificate matches the name included in the client request, then that “proves” to the client that it is connecting to the correct Web server.

That’s all there is to it. If the name in the client request doesn’t match the common or subject name on the Web site certificate returned by the ISA firewall to the client, then the impersonation fails, because the client is expecting that common or subject name to be the same as that included in the request.

However, for the entire process to complete successfully, you need:

• The client request to match the common or subject name on the certificate bound to the Web Listener. For example, if the client requests https://owa.msfirewall.org/owa, then the common/subject name on the certificate must be owa.msfirewall.org
• The client needs the CA certificate of the CA that issued the certificate installed in it’s Trusted Root Certification Authorities certificate store. This is how a machine trusts the Web site certificate; if the CA that issued the certificate is trusted, then the machine also will trust the Web site certificate. The CA certificate needs to be installed on both the client and the server
• If you expect non-managed clients to connect to your published, secure Web site, then you should install a commercial Web site certificate on the ISA firewall. If only managed clients are going to connect to the secure Web site through the ISA firewall, it might be more secure to use a private certificate that you generate on your own certificate server, and use an Enterprise CA internally so that the CA certificate is automatically added to all the domain computers
• Both the Web site certificate and the CA certificate must not be expired. If any of the certificates are expired, they will not longer be valid and will not work.
• In some cases, clients will need to connect to the CRL site that publishes the certificate revocation list. If you have problems with secure Web site publishing, try publishing your CRL. Publishing the CRL can also significantly improve performance in some cases.

That’s all there is to it, at least conceptually. How to make the certificate requests, how to install the Web site and CA certificates, and how to check for validity are part of a longer article. I’ll probably do one soon for either ISAserver.org or Windowsecurity.com in the near future.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Now that Windows Essential Business Server (EBS) has hit the public domain and is available for beta testing to anyone, we can start talking about the TMG firewall included as part of the EBS package. If you haven’t seen or heard of EBS yet, it is a collection of three servers, a Management Server, a Messaging Server (running Exchange 2007) and a Security Server (running Forefront TMG). The most interesting part of the package, of course, is the TMG component.

I found it very interesting how they decided to deploy the TMG configuration on the Security Server. After setup completes, they create 16 Firewall Policy rules to support outbound access for internal users, inbound access to OWA, TSG, RPC/HTTP, RRW and ActiveSync. There are also other rules in place to support management from SCE, sync with the Exchange Edge Server which is also installed on the TMG firewall, and other protocols for monitoring.

When you install EBS, I suggest that you take some time to review the configuration of the TMG firewall and also of the Exchange Server and Terminal Services Gateway. EBS is supposed to present a fully baked best practices solution for all the components that part of the EBS package. What I want to challenge you to do, my dear ISAserver.org reader and ISA firewall admin, is to look at how the TMG is configured, look at the details of the access rules, Web Publishing Rules and Server Publishing Rules.

After reviewing the configuration (together with that on the Exchange and TSG servers), tell me what you think. Do you think that they’ve actually implemented security best practices with the TMG configuration and firewall rule set (including System Policy Rules)? Or do you think that maybe someone “forgot” something and that there are changes that should be made that would significantly improve the security offered by the TMG firewall as part of the EBS offering.

Thanks!

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

A few people have mentioned to me recently that they’ve been having problems with opening FTP sites using IE 7 when their computers are configured as Web Proxy clients. The problem happens when the users need to log on to an FTP site to gain access.

If you’re having this problem, then check out the ISA Firewall Product Team Blog and Doron Juster’s post at https://blogs.technet.com/isablog/archive/2008/04/...y.aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Someone was having DNS problems recently related to his publishing rules and it reminded me of the important difference between how you need to set up your DNS when dealing with NAT and ROUTE relationships between source and destination networks.

For Server Publishing Rules, there are two scenarios — A NAT relationship between the published server and the external client, and a ROUTE relationship between the published server and the external client.

When there is a NAT relationship between the published server and the external client, your DNS server needs to map the name of the published server to the IP address on the external interface of the ISA Firewall that is listening for those connections, based on the settings you’ve configured in the Server Publishing Rule for that published server.

When there is a ROUTE relationship between the published server and the external client, your DNS server needs to map the name of the published server to the actual IP address of the published server. This is important in public address DMZ scenarios, where you typically have a ROUTE relationship between the DMZ ISA Firewall Network and the default External Network.

The ISA and TMG firewalls are able to do this because in a ROUTE relationship scenario, the firewall is able to employ something called “port stealing”, so that when an incoming connection request to the actual IP address of the server on the DMZ is made, the ISA or TMG firewall intercepts the request and exposes it to its application layer inspection filters before forwarding the connection to the published server.

For more information about the ISA and TMG firewall core, check out the Introduction to the ISA Server 2006 Firewall Core document at http://download.microsoft.com/download/e/7/6/e76fd...wp.doc

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

If you haven’t had a chance to check out the Beta 1 version of the new Forefront Threat Management Gateway (TMG), then make a note for yourself to take some time and test it out in your lab. The Forefront TMG is the next version of the ISA Firewall, and the TMG should be released some time next year if everything goes OK during the development.

While the Beta 1 version is far from feature complete (at least we all hope so), one thing that I’ve been very impressed by is the new Help File for the TMG. While the previous versions of the Help file included with the three versions of the ISA Firewall were pretty good, the Help file contents included with the Beta 1 version of the TMG set a new bar for high quality Help content.

It’s clear that the folks who put the Help content together for the TMG have been working hard for quite some time. The new Help file content isn’t just a rehash of the old Help file content. Instead, the content has been significantly enhanced so that features that were ambiguous or hard to understand are now more thoroughly explained. The chance of running into a configuration option that you have idea what it does is significantly decreased due to the new, enhanced Help file content.

But, no matter how good things are, they can always be made better. This is where you come in! When going over the Forefront TMG Help content, if there is anything you don’t understand or doesn’t make sense, click the Send Feedback link and let them know. One problem with this is that you don’t typically have an email client configured on the firewall, and in fact, it’s TMG firewall best practice to NOT have a email client configured, so that you don’t download malware to the firewall.

One solution to this problem is to install the Windows Desktop Experience on the Windows Server 2008 computer and use the email client associated with that, and then configure the mail client with a real SMTP server, but with a bogus POP3 server, so that you don’t use the mail client to download malware to the firewall.

If you don’t want to deal with the mail client at all, you can just copy and paste the content and send it to isadocs@microsoft.com The docs team really does want to hear from you and they read and consider everything you send to them. So let them know!

Also, write to them not only about things in the existing content that you don’t understand, but let me know if there are additional topics that need to be covered.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Chris Avis, IT Pro Evangelist for Microsoft, has a nice article on how to get Vonage to work with the ISA firewall.

Check it out here:

http://stewedprunes.com/blogs/stewed_prunes/archiv...2.aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Tarek Majdalani (who runs the great http://www.elmajdal.net/ Web site) brought up an interesting question today regarding the next version of the ISA Firewall, the Forefront Threat Management Gateway (Forefront TMG). He mentioned whether we were going to have problems with the fact that IIS 7 is installed on the TMG, given that we’ve been so vehement on ISAserver.org that you should never install the WWW service on the ISA Firewall.

The reason why we so strongly recommend that you don’t place the WWW service on the firewall is that in the past, the only reason to do so was to run a Web site on the firewall. Since the ISA firewall security model is broken when you install extraneous services on the firewall, we recommended that you never do so. Exposing the ISA firewall via a Web site that’s accessible to connections from clients on any network significantly increases the attack surface.

The reason why IIS is installed on the TMG firewall is that it’s required to support SQL reporting services, which is what the TMG firewall uses to create the TMG firewall reports. However, if you look at the IIS configuration, you’ll see that the only binding is for TCP port 8008 which is used for local access to the SQL reports.

More importantly, there are no rules that allow connections to the local IIS Web server, so the Web server is not exposed to external (non-local host) connections. So, for all practical purposes, the Web server is not accessible except to the TMG Firewall and locally logged on users. This means there is no practical increase in the attack surface on the TMG due to the IIS 7 installation.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

We had a short, but interesting conversation regarding whether or not you should put the ISA firewall in a forest separate from the corporate network and then create a one-way trust so that the ISA Firewall forest trusts the corporate network forest. Jason Jones brought this up because we generally don’t recommend such a configuration because it adds to complexity of deployment and creates a number of management headaches that are often hard or impossible to solve.

However, it made me think about how important it is to be consistent. I’m a big advocate of least privilege. It’s least privilege that should guide all of our security decisions when working with the ISA and TMG firewalls. It’s the problems with least privilege that drives me insane regarding the Exchange Team’s ISA guidance, and their lack of support for putting the Client Access Server (CAS) in an authenticated access DMZ segment.

So, if I’m so strong regarding least privilege regarding Exchange Server topologies, it should make sense that I would be a major advocate of putting the ISA/TMG firewall in it’s own forest and creating a one-way trust. And now that I think of it, it does make sense.

However, it makes sense if you have the hardware and software resources to support the configuration. I still consider the security advantages of this configuration to be nominal in 98% of the cases where the ISA/TMG firewalls are deployed. However, for the 2% where it makes sense, it’s worth marshalling the hardware and software resources to make this trusting forest configuration happen.

What are examples of such a deployment? Tim Mullen helped with this. Suppose you log in as admin to the ISA/TMG firewall? Those credentials can be retrieved (given the right set of configuration and management mistakes). What if you were an ISP supporting multiple clients with write access to directory structures? In that case, you have a more complex authentication situation, where joining the ISA/TMG firewall to a single domain doesn’t work, since you would otherwise require that the other domains set up trusts with one another.

So, like all guidance, you have to consider the relative costs and benefits of least privilege. Configuring firewall rules to support Exchange and other servers has very low cost — you don’t need to buy new software, you just need to configure the correct rules. The low cost in this scenario makes it worthwhile to impose least privilege in all cases where it’s just a matter of configuring firewall rules.

However, putting the ISA Firewall in a separate forest has much higher cost, and thus you should consider this the option of choice only if the costs are outweighed by the security advantages, such as the scenario where there are multiple other forests that the ISA/TMG firewall need to authenticate with.

The bottom line is that guidance is just that — guidance. You need to take the entire deployment requirements into consideration and come up with the best solution given the exigencies you’re presented with. That’s why you hire consultants like me, Tim and Jason Jones (and Jim Harrison, if he ever decides to leave Microsoft) to help you make the right decision based on these exigencies.

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

Yuri Diogenes from Microsoft PSS has put together a great article on troubleshooting Outlook Web Access Publishing Rules.

Check it out at:

http://blogs.technet.com/isablog/archive/2008/04/2...6.aspx

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)

It’s difficult to give hard and fast information on how to best order the rules in your ISA Firewall rule set, since there are many exceptions that require understanding of how rules are processed. However, The following will help you get started:

1. Rules that deny access to all users
2. Rules that allow access to all users
3. Rules that allow or deny access to specific computers (that is to say, rules that don’t require authentication)
4. Rules applying to specific users, URLs, and MIME types
5. All other rules

Web and Server Publishing Rules can be placed anywhere.

Keep in mind that with enterprise edition, the best way to get the rules higher in rule order is to put them in the Pre-array Enterprise Rules.

For more information, check out:

http://www.microsoft.com/technet/isa/2006/BP_Firew...r=true

HTH,

Tom

Thomas W Shinder, M.D.
Site: http://www.isaserver.org/
Blog: http://blogs.isaserver.org/shinder/
GET THE NEW BOOK! Go to http://tinyurl.com/2gpoo8
Email: tshinder@isaserver.org
MVP — Microsoft Firewalls (ISA)