1. Introduction

Nowadays information is much easier to find than it was in the past, you can find information about pretty much everything by just searching on the web (try http://www.letmebingthatforyou.com/?q=dns%20atacck for example). For this reason it is even more important to be diligent while protecting your company’s data by avoiding data leakage and data enumeration.

One of the pre-attack phases is exactly the enumeration of data for the target system (or company), during this phase the attacker will try to gather as much information as possible about the target, going from the basic stuff that it can find about the target on the company’s web site to a more detail data enumeration using tools and techniques. One of the steps for data enumeration is query the target DNS system in order to obtain more information about hosts and IPs. This process can start by simply using the nslookup command. Assuming a successfully query, the attacker can try to transfer all the information for that domain by attempting a zone transfer operation. This post will explain how to configure your DNS Publishing rule on TMG to avoid zone transfer.

2. What you want to avoid?

The scenario that I described above is an unfortunate common scenario, many times because the system administrator forgot to securely configure the DNS Server on the internal network to not allow zone transfer for all systems. Here an example of a DNS that is wide open for zone transfer:

When this configuration is place the following result will happen if the client tries to transfer a zone using nslookup:

Well, this is not nice at all…here it is my whole internal domain zone exposed to all Internet users just because the system administrator forgot to disable one checkbox.

3. Protecting Internal Resources

If system administrator didn’t do his homework, you as firewall admin MUST do it ASAP. However it is very important to emphasize that this band aid solution on the perimeter shouldn’t be the main one, we always need to fix the root cause of the problem, which in this case is to securely configure the DNS Server. The fact that you are protecting the DNS Publishing on your perimeter is just a countermeasure to avoid a potential attempt to transfer the internal DNS zone to an external (non trusted) resource.

The DNS Filter on TMG is enabled by default as shown below:

This filter has the following capabilities pre-configured by default:

• DNS_Intrusion_detection= 1
• DNS_Hostname_Overflow=1
• DNS_Length_Overflow=1

As zone transfer can or cannot be a legitimate type of access the parameter DNS_Zone_Transfer is set to 0 by default. In other words: if you want to allow zone transfer you should leave this parameter as is. The recommendation is to make sure to allow zone transfer only to trusted DNS servers, which means that you should configure your DNZ zone to allow transfer only for the server’s IPs that you trust. If all the servers that you trust are behind TMG (on the internal network) then you can safely block zone transfer attempts from traffic coming from the external (Internet) network. To do that you need to run the following script:

…OR you can also use the UI to make this change using the option below:

Note: if you run the script while the console is open and you try to see if this option is enabled on the UI, the option might still be disabled. To refresh it, close TMG console and open it again.

After running this script (or changing it on the UI), make sure to restart Firewall Service and then try again to run the nslookup ls command from an external computer. The expected result is shown below:

Now this for sure is a better result for an external user to get it.

TMG installation problems can be a bit trick to troubleshooting if you don’t know which components are involved, however if you know then things start make more sense. Most of the setup problems that I faced up to now on TMG 2010 (since RTM) were related to ADLDS or some kind of domain connectivity problem. The most two recent examples are described on two articles that I tech reviewed from my friends Bala Natarajan and Niladri Dasgupta wrote:

• Troubleshooting ERROR: Setup failed to install ADAM.\r\n (0x80074e46) and 0x80070643 while trying to install TMG 2010
• Another TMG 2010 Installation failure with error 0x80070643

Last week I worked on an issue where TMG admin was not able to install this brand new TMG to be used as Edge Firewall. The error message that he was receiving was:

After this error the setup process rolled back and finish without completing the installation. As recommended on the previous two articles mentioned in this post, the first step is to review the setup logs and look for more information in order to move the troubleshooting further. In the ADAM Log file we can see the following entry:

When you see an error where trust relationship between client and domain is failing, be sure to do your homework, in other words, check:

• General connectivity with the DC – can TMG access the DC (ping, tracert, etc)?
• Name resolution – can TMG resolve DC’s name?
• NIC Binding Order – is the Internal NIC on the top of the binding order?
• Secure Channel – is the secure channel between the server where TMG is installed and the DC working correctly?

When I hit the third test I found out the problem:

This was the problem, because Windows (where I was trying to install TMG) was sending the traffic to the wrong interface. Once we moved the Internal to the top, flushdns (with ipconfig) and ran the setup again the issue went away and the installation finished successfully.

Note: same recommendation to have Internal on the top applies to UAG, check it out a great reference on that written by Jason Jones at http://blog.msedge.org.uk/2010/04/recommended-network-card-configuration_14.html

Slow browsing experience is a behavior that can happen for so many reasons that cover everything in one single article is just not feasible, mainly when the list still growing. Here are some posts/articles that I wrote on this matter:

• How Disk Bottleneck can affect TMG Performance?
• Side Effects of Incorrect DNS configuration on ISA Server: 10060 Connection Timeout Scenario
• Slow performance while browsing Internet using IE8 through ISA Server 2006
• A Failed Attempt to Optimize Browsing Performance
• Clients can’t browse Internet through ISA because ISA is waiting for the DNS to answer
• Intermittent Performance Problem while Accessing Internet through ISA Server 2006
• Intermittent Performance Problem while Accessing Internet through ISA Server 2006 – Round 2
• Improving Web Proxy Client Authentication Performance on ISA Server 2006

The list is growing because recently, troubleshooting another issue of this nature today I learned another cool thing: disabled adapters matters. What I mean with this is that if you have multiple adapters on your ISA/TMG and if some of the adapters are not in use and are disabled, this can still affect the performance of the system. How? According to the binding order. Remember that I talked about binding order here some time ago? The DNS best practice analyzer pointed me to the right direction on this, here what he said about disabled adapters on the top of the binding order:

Keep this caveat in mind during your ISA/TMG performance health check analyzes.