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.
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.
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:
DNS traffic is being sent from the host at 10.10.255.127, destined for the DNS server at 22.214.171.124. ISA applies IP-NAT to the source-IP so that the DNS server responses can be directed to the ISA server external IP of 126.96.36.199. 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.
DNS traffic from an external client on IP 188.8.131.52 is sent to the ISA external IP of 184.108.40.206. 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.
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)
ISA does not change any IP or transport header data for traffic which traverses a route relationship.
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.
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.
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.
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 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.
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
Jim Harrison, Program Manager, Forefront Edge SE