Richard Hicks' Blog

Today I confirmed a bug in Service Pack 2 (SP2) for Forefront TMG 2010 that was discovered by Jason Jones. If you have deleted the default Internet Access network rule and replaced it with something else, installing SP2 for Forefront TMG 2010 mysteriously restores this rule. Unfortunately it places the default Internet Access rule ahead of your custom rule which in most cases will cause serious problems. This bug only affects Forefront TMG 2010 configurations where the default Internet Access network rule has been specifically deleted. If you’ve altered this rule in any way, those changes are unaffected.

Before Forefront TMG SP2 installation…

After Forefront TMG SP2 installation…

Frequently I am asked to review Forefront TMG 2010 firewall logs for suspicious behavior. Often times a security administrator will express concerns about many instances of denied requests by clients attempting to connect to Forefront TMG’s web proxy service. On busy TMG firewalls there may be hundreds or even thousands of instances where the following access denied record appears in the Web Proxy logs:

Status: 12209 Forefront TMG requires authorization to fulfill the request.
Access to the Web Proxy filter is denied.

On a Forefront TMG 2010 firewall where web access rules require authentication, this behavior is expected and by design. It does not indicate an attack of any type on the Forefront TMG firewall or its web proxy service. The root cause for the flood of access denied messages has to do with how the Web Proxy client behaves when accessing resources via an authenticating web proxy like the Forefront TMG 2010 firewall. When a Web Proxy client sends its initial request for a resource it will always attempt to do so anonymously. Only when prompted for authentication by the firewall will the web proxy client provide the credentials of the logged on user.

Consider a scenario where Forefront TMG is configured to only allow authenticated users to access the Internet. The firewall policy might look something like this:

Below is a network trace taken from a client attempting to access http://www.bing.com/ through a TMG firewall as configured above.

We can see that the first three packets of the trace are the TCP three-way handshake taking place between the web proxy client and the Forefront TMG firewall. Once a connection to the web proxy listener has been established, in packet 8 the client sends an HTTP GET request for http://www.bing.com/. In packet 13 you’ll see that the Forefront TMG firewall denied the request and replied with an HTTP 407 response, indicating that proxy authentication was required. This was done because the Forefront TMG firewall did not have any access rules which would allow the anonymous request. It did, however, have access rules that might apply to this request, depending on who the user is. This response also includes which authentication methods the web proxy listener is configured to accept.

In packet 15 the web proxy client again submits its HTTP GET request for http://www.bing.com/, this time indicating that it would like to use the NTLM Secure Service Provider (SSP). In packet 16 the Forefront TMG web proxy denies the request yet again and replies with another HTTP 407 response, this time including the NTLM challenge. In packet 17 the client submits an HTTP GET request for http://www.bing.com/ and supplies the credentials in the form of an NTLM response.

As you can see, each time a web proxy client requests a resource through a Forefront TMG firewall that requires NTLM authentication the client is actually denied twice during the transaction before being successfully authenticated and allowed access. If this sounds like a lot of overhead for authenticated proxy traffic, you are right. Denying each request twice consumes additional resources on the Forefront TMG firewall and introduces some latency for clients as well. In addition, the burden of authenticating the user is placed on the TMG firewall when using NTLM, as the firewall itself must contact a domain controller to authenticate the user. You can reduce the authentication load on the Forefront TMG firewall considerably by enabling Kerberos authentication. When the Forefront TMG firewall is configured to use Kerberos there is only a single denied request and HTTP 407 response. The client must then contact a domain controller and obtain a Kerberos ticket to present to the TMG firewall to gain access to the resource. Information on how to configure Microsoft ISA Server and Forefront TMG 2010 to use Kerberos authentication can be found here.

Additional information…

HTTP response codes – http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
NTLM challenge/response – http://en.wikipedia.org/wiki/NTLM

An intrusion detection and prevention system (IDS/IPS) is an essential component of a modern secure web gateway. The Network Inspection System (NIS) in Forefront Threat Management Gateway (TMG) 2010 is a unique implementation of IDS/IPS. NIS is focused specifically on detecting and preventing attacks on Microsoft operating systems and applications. NIS uses signatures that are developed by the Microsoft Malware Protection Center (MMPC) and are distributed through Windows Update or WSUS.

NIS in Forefront TMG 2010 provides protection by performing low-level network protocol inspection. Each packet is analyzed for protocol state, message structure, and message content. When a packet is received, NIS will inspect it only after the firewall policy has allowed it, and only after any associated web or application filters have processed it.

There is one caveat, however. A custom protocol is not subject to NIS inspection by the Forefront TMG firewall unless it is associated with a standard protocol. Often a Forefront TMG firewall administrator will create a custom protocol for a standard protocol that uses a non-standard port. One of the most common protocols to be configured to use non-standard ports is the HTTP protocol. For example, if an administrator defines a custom protocol to support a web-based application that uses the non-standard TCP port 62112, by default NIS will not inspect this traffic even though the communication is HTTP, a protocol which NIS normally inspects when it takes place over the standard TCP port 80.

To apply Forefront TMG NIS inspection to a custom protocol it must first be associated with a standard protocol. In our example we’re using HTTP over a non-standard port, so we need to associate our custom protocol with the Web Proxy Filter.

Next, associate the custom protocol with a standard protocol definition, in this case HTTP Proxy.

Once complete, Forefront TMG NIS inspection will be applied to the custom protocol and policy will be enforced according to the current NIS configuration.

Forefront TMG NIS additional information:

Enabling and configuring Forefront TMG 2010 NIS

Forefront TMG 2010 NIS Whitepaper [Word Document]

Security hardening and attack surface reduction is an important step in preparing a Forefront TMG 2010 firewall. To accomplish this task, the tool of choice is the Security Configuration Wizard (SCW). In one of my ISAserver.org articles I demonstrated how to use this tool to properly configure the underlying operating system to support the Forefront TMG 2010 firewall role. Since the native Windows SCW does not include support for the Forefront TMG role, the TMGRolesForSCW.exe utility included in the Forefront TMG Tools and SDK is required. This tool was released prior to service pack 1 for Windows Server 2008 R2 and does not include a template that works correctly out of the box. When you attempt to register the Windows Server 2008 R2 template on a system with SP1 installed you will receive the following error:

Command completed with error.
The parameter is incorrect.
Please check log file(s) under the following directory:
%windir%\security\msscw\logs

To resolve this issue, create a copy of the template file SCW_TMG_W2K8R2_SP0.xml and name it SCW_TMG_W2K8R2_SP1.xml. Open this file with any text editor and navigate to the SCWKBRegistrationInfo node (line 2). Change the value of ServicePackMajorVersion from “0” to “1” and save the file. Register the template using the following command:

scwcmd register /kbname:TMG /kbfile:scw_tmg_w2k8r2_sp1.xml

Continue using the SCW to configure and apply a security template to your TMG firewall following the instructions in my ISAserver.org article.

Recently I received a call from a customer who was trying to resolve an issue where all web proxy clients that were configured to use Web Proxy Auto Discovery (WPAD) with DNS suddenly stopped working. We began troubleshooting by confirming that the hostname WPAD resolved to the internal IP address of the Forefront TMG firewall, which it did correctly. Next we used a telnet client to confirm that the TMG firewall was listening on TCP port 80 (used by TMG for DNS WPAD clients) and indeed it was responsive. A scan of the event logs on the firewall turned up the following warning message:

“The Web Proxy filter failed to bind its socket to 172.16.1.253 port 80. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.”

Something was listening on TCP port 80, so we opened a command prompt and entered the following command in order to determine which process was listening on this port:

netstat –ano | findstr :80

Netstat was reporting that TCP port 80 was in a listening state and bound to the IP address 172.16.1.253. The process using this port was the System process (PID 4). This is unexpected, because the Forefront TMG web proxy service (wspsrv.exe) should be bound and listening on this port. Clearly this was a web service hijacking this port, so to find out more we entered the following command at a command prompt:

netsh http show servicestate

The output of this command revealed a valuable clue. Notice the registered URL below…

HTTP://172.16.1.253:80:172.16.1.253/REPORTSERVER_ISARS/

As it turns out, this customer had attempted to change the SQL Reporting Services Web Service URL. By assigning the Forefront TMG firewall’s internal IP address and changing the port to 80 in the Reporting Service Configuration Manager, this caused a conflict with the Forefront TMG web proxy filter, which requires TCP port 80 to provide WPAD for DNS.

To resolve the issue, the administrator chose a TCP port other than 80 and restarted the system.

Deploying Forefront Threat Management Gateway (TMG) 2010 in a workgroup (non-domain joined) enterprise array configuration can present a significant challenge to many administrators. This post isn’t meant to be a comprehensive TMG Enterprise Management Server (EMS) deployment guide, but I would like to share with you a few important tips that will hopefully make the process of creating an EMS-managed array a little easier.

Before Installing EMS

IP Addressing – Make certain that all basic IP connectivity is verified before installing any Forefront TMG 2010 services.

Name Resolution – Confirm that name resolution is working properly and that hostnames are being resolved to the correct IP addresses. Be sure that these IP addresses are assigned to the Internal network interface of the EMS and each array member.

Certificates – The EMS will require a machine certificate, and each array member should trust the Certificate Authority (CA) that issued this certificate. It is recommended that this certificate be issued by your internal private CA and not a public third-party CA. The certificate should be for server authentication and the common name on the certificate should be the FQDN of the host it is to be installed on. Be sure to install the root certificate and any intermediate certificates for the CA on the EMS and each array member. Make certain the certificate is issued with the option for the private key to be exportable.

Local Accounts – Identical (mirrored) local accounts should be configured on the EMS and each array member and be granted administrative rights for the Forefront TMG 2010 Enterprise.

After Installing EMS

Before joining a TMG firewall to an array, you can perform some preliminary tests to determine if certificate authentication between hosts is working correctly. To do this, open a PowerShell command window and enter the following commands:

import-module servermanager
add-windowsfeature rsat-adlds

Once complete, click Start | Run and enter ldp.exe. From the drop-down menu choose Connection, and then Connect…. For the server, enter the fully-qualified domain name (FQDN) of the EMS, specify port 2172, and then select the option to use SSL.

If certificate authentication is working correctly you will connect to the RootDSE. If it is not configured correctly you will receive a connection error.

To determine if user authentication is working correctly, select Connection from the drop-down menu and then Bind…. If you are currently logged on with the local mirrored account, select the option to Bind as currently logged on user, otherwise select Bind with credentials and enter the user and password of the mirrored account (leave the domain blank).

If configured correctly you will receive notification that you have been authenticated. If not, you will be notified that the logon attempt failed.

Once you’ve completed these steps you can proceed with configuring the TMG firewall to join the array. Be sure to specify the name of the EMS in exactly the same format as the certificate common name (preferably using the FQDN ).

In the first part of this two-part series we used PAL and Performance Monitor to collect data. In this second part I’ll demonstrate how to use PAL to analyze the data and generate a report.

Analyzing the Data

Once you’ve collected the necessary log data you are ready to analyze it using PAL. To begin, open the PAL tool, click Next or select the Counter Log tab, then choose the path to the log file collected using Performance Monitor.

Select Microsoft Forefront Threat Management Gateway for the threshold file and choose Next.

To accurately analyze the data, PAL needs to know specific details about the system where the log data was collected. Highlight and answer each question and choose Next.

Accept the default settings for Analysis Interval and All Counter Stats.

By default, PAL generates reports in HTML format and places them in the My Documents\PAL Reports folder. Here you can change the default file location and also select the option to generate reports in XML format.

Behind the scenes PAL leverages a complex PowerShell script to perform analysis and generate reports.

To perform the analysis and generate a report, click Finish. Optionally you can add the analysis job to the job queue or execute the analysis and restart the wizard with the same settings. You can also select the option to execute as a low priority process.

PAL begins analyzing the log data and once complete it generates a report in the format specified. You can view a sample report here.

The report is very detailed and includes alerts when a particular counter exceeds a predetermined threshold. The alerts are color coded to easily identify when a threshold has been exceeded. The report also includes a brief explanation of each counter, a graphical chart of the data analyzed, and statistical data relating to the counter.

PAL is a wonderful tool that greatly simplifies the process of analyzing Performance Monitor data. It is not, however, a magic wand that will solve all of your performance issues automatically. Although the tool provides a wealth of information in a clear and concise format, it is still up to the administrator to understand the data and ultimately determine how best to resolve the issue. PAL just makes that task much easier.

Forefront TMG Performance Troubleshooting with PAL v2.x Part 1 – Data Collection
Forefront TMG Performance Troubleshooting with PAL v2.x Part 2 – Data Analysis and Reporting

Troubleshooting performance issues on any system, especially a Forefront Threat Management Gateway (TMG) 2010 firewall can be a significant challenge for many administrators. The primary tool used for this task is the Windows Performance Monitor. This tool allows the administrator to monitor virtually every aspect of the operating system, applications, and hardware. However, deciding which objects and counters to monitor and how to interpret the data can be difficult.

That’s where Performance Analysis of Logs (PAL) comes in. Created by Microsoft Premiere Field Engineer (PFE) Clint Huffman, this free tool automates the analysis of logged data collected using Performance Monitor. PAL uses templates along with user input to analyze and report on the collected log information. It eliminates guesswork by highlighting counters that exceed predefined thresholds. PAL has been around for many years, but until recently has lacked support for Forefront TMG. Thanks to the effort and hard work by some Forefront PFE’s and CSS engineers, the recent release of PAL v2.0.7 now fully supports Forefront TMG.

PAL can be found at http://pal.codeplex.com/. It is available for 32- and 64-bit systems, and requires that Microsoft .NET Framework 3.5 SP1, Microsoft Chart Controls for .NET Framework 3.5, and PowerShell v2.0 be installed.

In this first part of a two-part series we’ll first look at how to use PAL to configure Performance Monitor to collect the necessary data. In the second part will use PAL to analyze the data and generate a report.

Collecting Data

Enabling private Performance Monitor counters is required to fully analyze performance on the Forefront TMG firewall. Enabling private Performance Monitor counters is accomplished be creating the following registry key on the Forefront TMG firewall:

HKLM\SOFTWARE\Microsoft\RAT\Stingray\Debug\FWSRV
"FWS_PRIVATE_PERFORMANCE_COUNTERS"=dword:00000001

Download .reg file here.

To begin collecting performance data on the Forefront TMG firewall, open the PAL tool and select the Threshold File tab, then click the drop-down box and choose Microsoft Threat Management Gateway.

Click Export to Perfmon Template File… and save the file.

On the TMG firewall, open the Performance Monitor, expand Data Collector Sets, and then right-click User Defined and choose New -> Data Collector Set.

Give the new data collector set a descriptive name, select the option to Create from a template, then click Next.

When the wizard prompts for which template to use, click Browse…, then select the PAL template file exported earlier.

Specify the folder where the logged data will be saved and click Finish.

Once complete, the new data collector set will appear. If you right-click the new collector set and choose Properties… you will see that it contains all of the necessary Performance Monitor objects and counters required to perform an in-depth performance analysis of the Forefront TMG firewall. Here you can also change parameters such as the log format (binary log format is recommend, however) and sample interval. You can also change file parameters such as the log file name, the file name format, and the logging mode (overwrite, append, or circular).

To start collecting data, right-click the data collector set and choose Start. Once the capture has started, you can right-click and select Stop to stop the capture.

You can also schedule data collection by right-clicking the data collector set and choosing Properties, clicking the Schedule tab, and then clicking Add.

You can also specify a stop condition that will cease data collection based on any number of different parameters including duration and size of the log file.

In the second part of this two-part series we’ll outline how to use PAL to analyze and generate reports of the Performance Monitor data.

Forefront TMG Performance Troubleshooting with PAL v2.x Part 1 – Data Collection
Forefront TMG Performance Troubleshooting with PAL v2.x Part 2 – Data Analysis and Reporting

When configuring network interface settings on a Forefront Threat Management Gateway (TMG) 2010 firewall, I strongly recommend that the port speed and duplex settings on all active network interfaces be manually configured. Although autonegotiation is typically enabled by default, and in most cases works without issue, I prefer to eliminate any possibility that a slower link speed or incorrect duplex setting is negotiated in error by configuring these settings explicitly.

Some believe you can configure one side of a link (either the host or the switch) manually and leave the other side set to autonegotiate. The theory is that the host set to autonegotiate will determine what settings the other side has configured and automatically choose those. This is not completely true and doesn’t work as expected. When one side of a link is set for autonegotiation and the other side is not (or doesn’t support it), a process called parallel detection takes place whereby the device that is configured to autonegotiate can determine the port speed of the other device, but it cannot determine the duplex settings and defaults to half duplex. Often this results in a duplex mismatch, which will cause extremely poor performance.

So, when configuring port speed and duplex settings, always remember that BOTH sides of the link should be configured identically. That is, if the switch is configured for 100Mbps/full duplex operation, the network interface on the TMG firewall should be configured the same. On some systems (mostly older ones), when attempting to change these settings, you might notice that there is no option to enable 1000Mbps (gigabit) at full duplex operation. The only available option is autonegotiate 1000Mbps.

Why is there no option to select 1000Mbps and full duplex? Because the designers of the 1000BASE-T specification (IEEE 802.3ab) made duplex autonegotiation mandatory when operating at 1000Mbps port speed over copper cabling. For this reason some network interface management software may limit your choices and not allow you to select this option. In my experience it appears that adherence to this mandate has been relaxed as most newer systems I have worked with now give you the option of configuring 1000Mbps and full duplex operation with copper cabling. If you have an older system and don’t have the option to specify 1000Mbps/full duplex on the network interface, I would recommend updating your network interface device drivers. If you still don’t have the option to specify 1000Mbps/full duplex you may need to replace the network interface card itself.

For engineers performing advanced troubleshooting on TMG, you have likely noticed that fwengmon.exe, a utility that you used with previous versions of ISA, no longer functions with TMG.

Not to worry! This detailed information is readily accessible using netsh.exe in the tmg context. The following is a list of common commands and their fwengmon.exe equivalents (where applicable):

To view creation objects, active sessions, NLB hook rules, NLB server assigned ranges, and dynamic and persistent allowed ranges:

netsh tmg show all

To view connections only (fwengmon.exe /session or /s):

netsh tmg show connections

To view detailed information about a specific connection (fwengmon.exe /s <ID>):

netsh tmg show connections <connection_number>

To view firewall creation elements (fwengmon.exe /creations or /c):

netsh tmg show creations

Note: You can sort and filter output from show connections or show creations by source IP address, source port, destination IP address, destination port, or protocol using the sort and filter parameters (fwengmon.exe /organize or /o, or fwengnmon.exe /filter or /f). You can also limit the number of connections or creations displayed using the display parameter. Type netsh tmg show connections ? or netsh tmg show creations ? for more information.

To show NLB hook rules (fwengmon.exe /querynlb or /n):

netsh tmg show nlbhookrules

To view packets held in kernel mode:

netsh tmg show holdpackets

To view packets held in user mode:

netsh tmg show usermodepackets

To view global firewall engine driver settings:

netsh tmg show global

To specify a temporary address range to exempt from firewall filtering (fwengmon.exe /allow or /a):

netsh tmg add allowedrange <beginning_ip> <ending_ip>

To specify a permanent address range to exempt from firewall filtering (fwengmon.exe /allow or /a):

netsh tmg add allowedrange <beginning_ip> <ending_ip> persistent

Note: netsh tmg add allowedrange allows all traffic to and from hosts within the IP address range specified to bypass stateful firewall inspection completely. It should be used for troubleshooting purposes only.

To delete a temporary address range (fwengmon.exe /noallow):

netsh tmg delete allowedrange id=<id>

To delete a permanent address range (fwengmon.exe /noallow):

netsh tmg delete allowedrange id=<id> persistent