ISA & TMG NAT behavior And MS08-037

ISA & TMG NAT behavior And MS08-037

  • Comments 15
  • Likes

Introduction

Microsoft Security Response Center (MSRC) issued bulletin MS08-037 to address vulnerabilities in DNS resolvers caused by predictable UDP source port usage.  MSKB 956190 addresses behavior observed when traffic crosses a NAT-based firewall and provides workarounds to mitigate this behavior.  

Traffic crossing a NAT device cannot be assumed to maintain the original source port because of the likelihood of multiple internal hosts using the same protocol to send traffic to the same external destination; especially in the case of an infrastructure protocol such as DNS.  The NAT device will typically create a new connection to the external network using whatever source port allocation algorithm it has available.  In the case of ISA and TMG, this is deferred to Windows; specifically Winsock.

 

Behavior for ISA and TMG

Although the multi-network model and flexible NAT structure of ISA 2004, ISA Server 2006 and TMG differ greatly from ISA Server 2000, the default behavior for traffic crossing a NAT relationship is the same for all.

Note that although traffic handled by the Web Proxy may appear to be NAT, it is not.  Because a web proxy terminates the traffic between the client and server; the connections to each have no relationship to each other beyond that which is maintained by the web proxy itself.  Traffic which is processed by a NAT device maintains one or more of the IP or transport header data fields.  All IP and transport header data for traffic processed through a web proxy is unique to each host on either side of the proxy.  Because Web proxy traffic (that which is handled by web publishing or web proxy listeners) is actually terminated through layer-7 at the ISA itself, only the “Local host Access” network rule which defines a route relationship applies to Web Proxy traffic.

 

NAT Relationship

Default NAT relationships for ISA and TMG are considered “uni-directional”; that is, they only change the IP and transport data of the host in the “source” network.  Note that a NAT relationship imposes a strict limitation for the use of access and server (non-web) publishing rules:

1.       Access rules can only apply to traffic which originates from the “source” network

2.       Server Publishing rules can only apply to traffic which originates from the “destination” network

To illustrate the effect on traffic crossing NAT relationships, consider the following traffic flows:

 

Access Rule

 Access Rule

DNS traffic is being sent from the host at 10.10.255.127, destined for the DNS server at 123.123.123.123.  ISA applies IP-NAT to the source-IP so that the DNS server responses can be directed to the ISA server external IP of 123.123.123.124.   ISA maintains a connection table which maps these internal and external sockets to each other so that traffic can be directed properly.  Because ISA must potentially serve multiple requests to this server, it must obtain a unique source port for the external traffic so that the external DNS server will treat the requests from each internal host as a unique conversation.  Return traffic from the DNS server will exhibit the same, albeit opposite effect as it traverses the firewall.

 

Publishing Rule (default behavior)

 Publishing Rule (NAT)

DNS traffic from an external client on IP 123.123.123.123 is sent to the ISA external IP of 123.123.123.124.  Because the source-IP is not changed in the traffic sent to the internal DNS server, the source port can also remain unchanged and thus conversations between all external clients will be unique.  Return traffic from the DNS server will exhibit the opposite behavior across this relationship.

Publishing Rule (Full-NAT)

 Publishing Rule (Full-Nat)

In the case where the ISA admin elects to perform full-NAT for traffic crossing a Server Publishing rule, ISA will change the source-IP and source-port for all traffic crossing this relationship.  In this case, the source-port for the traffic sent to the DNS server will not be the same as used by the external client.  This configuration is made possible by:

·         ISA Server 2000: apply Service Pack 2 and follow the instructions in MSKB 311777. 

·         ISA Server 2004 / 2006 and TMG: publishing rules provide a UI setting in the “To” tab:

i)        Requests appear to come from the ISA Server computer (full-NAT; default for web publishing)

ii)      Requests appear to come from the original client  (half-NAT; default for server publishing)

 

 

Route Relationship

ISA does not change any IP or transport header data for traffic which traverses a route relationship.

 

Considerations for Client Traffic

What makes this more difficult to evaluate is the point that there are multiple client request types that are supported in ISA deployments.  When required, ISA defers to Winsock GetAddrInfo name resolution mechanisms when name resolution is required to satisfy a client request, so you should ensure that Windows on your ISA Server is patched.  Windows 2008 already incorporates the changes provided in MS08-037, so TMG name resolution does not suffer from this problem.

 

Web Proxy clients

These clients depend on ISA/TMG to perform name resolution on their behalf.  If the Windows installation under ISA has been patched, the source port randomization provided by the MS08-037 update will be used by Windows when ISA makes name resolution requests for these requests.  If not, applying this patch should be your next priority.

 

SecureNET clients

 These clients perform their own name resolution and so may be affected by ISA / TMG NAT behavior *if* they make direct DNS queries to external DNS servers.  If they only communicate with internal DNS resolvers, ISA / TMG NAT behavior does not affect them directly, but may affect the internal DNS server they use if it makes recursive queries through ISA / TMG as a SecureNET client in its own right.

 

Firewall clients

These clients pose a more complex problem, since the combination of application behavior as well as firewall Client Application settings makes determining client behavior more difficult.  As a rule, applications which perform name resolution through the use of Winsock API calls will benefit from the behavior provided by an ISA Server which operates on a patched Windows installation.  Those that insist on making direct-to-server queries will have a more difficult time.

One example of a FWC mixed behavior scenario is the use of nslookup.exe:

nslookup hostname
Nslookup will resolve "hostname" by making a Winsock GetAddrinfo request.  This request will be intercepted by the FWC and "hostname" will be resolved by ISA via Windows name resolution functionality. 

nslookup hostname dns_server_name
Nslookup will perform two tasks:

1.       Obtain dns_server_ip through a Winsock GetAddrinfo request for dns_server_name.  This request will be intercepted by the FWC and forwarded to ISA for resolution through Windows.   The results of that query will be sent back to nslookup via the FWC.

2.       Resolve "hostname" by sending a DNS query through Winsock to dns_server_ip.  The FWC will intercept this traffic and send it to ISA for rule evaluation and processing.  When ISA forwards the DNS query to dns_server_ip, the traffic will be sourced from the ISA server external IP and so will exhibit port assignment behavior as determined by the installation of the MS08-037 patch.

 

Summary

The ISA and TMG teams are working with MSRC to evaluate these problems in order to determine the most functional solution for each ISA Server version and TMG.  We will respond here as soon as a design decision is made and an expected ship date is determined.

 

Jim Harrison, Program Manager, Forefront Edge SE

Comments
  • Good article!

    Just wondering…

    Shouldn’t it be SecureNAT client instead of SecureNET? Or is it two different names for the same thing?

  • I have a personal preference for "SecureNET" because it allows you to mentally consider the fact that the traffic flow from a host / application which is neither a Firewall client nor a Web Proxy client can be processed by a route relationship.  "SecureNAT" doesn't allow for this mental flexibility.

    ..hope it's not too confusing...

  • body { font-family: Arial; font-size: 10pt} 183 Microsoft Team blogs searched, 88 blogs have new articles

  • We've created updates to ISA and TMG to support source port randomization for UDP traffic across NAT relationships.

    You can obtain the update packages here:

    ISA 2000 (requires SP2): http://www.microsoft.com/downloads/details.aspx?FamilyID=1455d4e6-a0b5-4583-82f1-ee8239fca207

    ISA 2004 Std Ed (requires SP3): http://www.microsoft.com/downloads/details.aspx?FamilyID=0ab83f12-653b-4be1-befe-594c4ef62baa

    ISA 2004 Ent Ed (requires SP3): http://www.microsoft.com/downloads/details.aspx?FamilyID=55ce3623-2f7b-4900-9a2f-7e2aa2fe9c50

    ISA 2006 (requires SP1): http://www.microsoft.com/downloads/details.aspx?FamilyID=e96a6e20-0c04-4c7d-9f3e-207b02ae29cc

    TMG MBE: http://www.microsoft.com/downloads/details.aspx?FamilyID=e974422f-42b0-426c-8852-ff8e67264909

  • We just released an update for ISA (2000, 2004 and 2006) and TMG MBE for the behavior that Jim Harrison

  • Wer heute in den WSUS geschaut hat, wird Updates für alle ISA Server-Versionen gefunden haben. These

  • After installing this update PPTP stopped working.

    Only after removing it could I get PPTP to work again.

  • Nori, have you contacted CSS?

    Can you elaborate on "stopped working"?

  • After applying the patch, you're not able to establish PPTP connections to your ISA, because TCP 0.0.0.0:1723 stops listening for incomming PPTP calls.

  • Due to some installation issues on Forefront TMG (MBE), the package at: http://www.microsoft.com/downloads/details.aspx?FamilyID=e974422f-42b0-426c-8852-ff8e67264909 has been re-released.  The code which manages the UDP NAT pool has not changed; only the installation process.

  • Kai! - whereyabeen?!?

    Given that the update only allocates UDP sockets and PPTP operates on TCP:1723, this error doesn't male sense.

    I'll see if I can repro it.  If not, will you have cycles to provide more targeted data?

  • Why do I need this? Last month, we released a collection of updates to help mitigate the problem caused

  • I didn't have time to troubleshoot further why PPTP stopped working or contact CSS.

    So I just uninstalled.

  • There is already a solution to the problem of PPTP ports disappeared?

    Already tried hotfix KB968078 that supersedes KB956570 but that has the same problem.

  • A few minutes ago i ran into the same PPTP issue again. Thx to MS09-016 for making trouble...

    Deinstalled MS09-016 and everything runs fine again. But now I'm sitting in front of a non-patched ISA box, again!

    Hope PSS will fix this issue soon, so that ISA admins would be finally protected against the Kaminsky DNS exploit.

    > Kai! - whereyabeen?!?

    Jim? (i guess, because nobody else would use the word "whereyabeen") ;)

    I'm still in Berlin. But i've played in the last two years a little bit more with Cisco stuff than with ISA.

    Regarding the help... sure you can ping me via email. (kw at itacs dot de)

    -Kai

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment