Archive
Windows Server 2012 DirectAccess Video Training Course Now Available
Recently I announced the availability of my Windows Server 2012 DirectAccess video training course at TrainSignal. Click here to read the full story!
Forefront TMG 2010 Protocols and Ports Reference
When deploying Forefront TMG 2010 as a forward or reverse proxy, many organizations will place their TMG firewalls in a perimeter or DMZ network to provide an additional layer of protection for their proxies. When deployed in this manner, configuring perimeter firewalls to allow proper communication to and from the Forefront TMG firewall can be challenging. Although the Service Overview and Network Port Requirements for Windows document on TechNet includes information about ISA server (which also applies to TMG) it includes all protocols and ports used by TMG in all deployment scenarios. This can be confusing when you simply want to allow TMG firewalls in a perimeter network to communicate with an Enterprise Management Server (EMS) on the internal network, or simply manage a TMG firewall in a perimeter network from a management workstation on the internal network. Opening all of the ports listed in the Microsoft KB article mentioned above would be unnecessary and would violate the principle of least privilege, which dictates that only the specific ports required for communication should be opened.
Note: This reference covers typical TMG configurations and may not include all protocols and ports required for every deployment scenario. For example, if you are using RADIUS or RSA for authentication, have configured connectivity verifiers or a remote SQL server, or have deployed Forefront TMG 2010 for Exchange integration, each of these configurations will require additional perimeter firewall access. Also, don’t forget that your perimeter firewalls will need to allow access to the protocols and ports required for the services you are accessing/publishing through Forefront TMG 2010.
For reference, here are the protocols and ports required for specific, common Forefront TMG 2010 deployment scenarios:
EMS to TMG
TCP 135, 10000-65535* – RPC
TCP 3847 – MS Firewall Control
TMG to EMS
TCP 445 – CIFS
UDP 445 – CIFS
TCP 2171 – MS Firewall Storage (domain-joined only)
TCP 2172 – MS Firewall Storage Secure (workgroup mode only)
TCP 3847 – MS Firewall Control
TMG to DCs
Domain joined…
TCP 88 – Kerberos
UDP 88 – Kerberos (send receive)
UDP 123 – NTP
TCP 135, 49152-65535* – RPC
TCP 389 – LDAP
UDP 389 – LDAP
TCP 445 – CIFS
UDP 445 – CIFS
TCP 3268 – LDAP Global Catalog
Non domain-joined…
TCP 389 – LDAP (required only for pre-authentication in reverse proxy scenarios)
TCP 636 – LDAPS (required only for pre-authentication in reverse proxy scenarios)
TMG to DNS
TCP 53 – DNS (send receive)
UDP 53 – DNS
Primary EMS to Replica EMS
TCP 135, 49152-65535* – RPC
TCP 2173 – MS Firewall Storage Replication
Replica EMS to Primary EMS
TCP 135, 49152-65535* – RPC
TCP 445 – CIFS
UDP 445 – CIFS
TCP 2171 – MS Firewall Storage – domain-joined only
TCP 2172 – MS Firewall Storage (Secure) – workgroup mode only
TCP 3847 – MS Firewall Control
Web Proxy Client to TMG
TCP 80 – HTTP (WPAD only)
TCP 8080 – HTTP Proxy
Firewall Client to TMG
TCP 80 – HTTP (WPAD only)
TCP 1745 – Firewall Client Control Channel
UDP 1745 – Firewall Client Control Channel
TCP 1024-65535 – All high ports**
UDP 1024-65535 – All high ports**
Management Workstation to TMG
TCP 135, 10000-65535* – RPC
TCP 2171 – MS Firewall Storage – Domain mode only
TCP 2172 – MS Firewall Storage (Secure) – Workgroup mode only
TCP 3847 – MS Firewall Control
*The default dynamic port range for Windows Server 2008 R2 is 49152-65535. When TMG is installed this setting is changed to 10000-65535. This does not apply to TMG EMS, however. RPC can be configured to use a smaller range of dynamic ports, if necessary. For more information, please see Microsoft KB 154956.
**The Forefront TMG 2010 Firewall Client is designed to operate without a firewall between itself and the TMG firewall. It is highly recommended that you avoid this design whenever possible. If this is unavoidable, all TCP and UDP high ports will have to be opened, as the TMG Firewall Client control channel utilizes random high ports and cannot be restricted as RPC can.
Addressing Security Issues with PPTP VPN in Forefront TMG 2010
At the recent DEFCON hacking conference, security researchers demonstrated a method to crack the MS-CHAPv2 authentication protocol with a 100% success rate. MS-CHAPv2 is used as the default authentication method for remote access VPN in Forefront TMG 2010.
With the public availability of tools to automate the cracking process, PPTP communication using MS-CHAPv2 should be considered unencrypted. There are two options available to mitigate this concern: disable MS-CHAPv2 and enable EAP with PPTP, or disable PPTP and switch to a more secure remote access VPN protocol such as L2TP/IPsec or SSTP. Enabling EAP requires the use of smart cards or certificates for authentication which makes implementation more challenging. SSTP is an excellent option as it leverages SSL/TLS to protect the MS-CHAPv2 authentication process. However, SSTP is only supported on Windows Vista SP1 and later clients. L2TP/IPsec is another good choice, and although it does support certificates it can also be configured using a pre-shared key. If long, complex passwords are used and care is taken to ensure that the password is well protected, it can provide a secure remote access solution.
Controlling Access to File Shares with Forefront TMG 2010
Consider a scenario in which you have an IIS server located in a perimeter network protected by Forefront TMG 2010. The server is published to the Internet and is used to display product information for your company. Web content developers on your internal network need to have access to file shares on the IIS server to upload new web content. To facilitate this access you create an access rule to allow CIFS access to the IIS server. For security reasons you decide to restrict access to members of the Web Content Developers domain group. In addition, your workstations have the Forefront TMG Firewall Client installed. The access rule looks like this:
When users attempt to map a drive to the file share on the web server they receive the following error message:
System error 67 has occurred. The network name cannot be found.
In addition, the Forefront TMG 2010 firewall log indicates the following:
Denied Connection Log Type: Firewall Service Status: The action cannot be performed because the session is not authenticated.
At this point you might be puzzled because you have the Forefront TMG Firewall Client is installed on the workstation. TMG Firewall Client communication is always authenticated, so why does the firewall log indicate otherwise? The answer is simple. The Forefront TMG 2010 Firewall Client is a Layered Service Provider (LSP) that listens for Winsock calls made by the operating system and applications. Any Winsock calls made for resources on a remote network will be transparently delivered to the proxy server by the Firewall Client. However, CIFS communication does not use Winsock, so the TMG Firewall Client does not handle this traffic. As such, the network requests are delivered to the Forefront TMG firewall as SecureNAT requests. Since the rule in question requires authentication, and SecureNAT traffic cannot be authenticated, the firewall appropriately denies the traffic and the request fails.
You can resolve this issue by removing authentication on the access rule and controlling access on the file share itself. If you want to enforce user and group authentication at the firewall, consider using another protocol such as FTP.
For more information about the Forefront TMG 2010 Firewall Client and CIFS connections, please review Microsoft Knowledge Base article 913782.
New DirectAccess Blog
For anyone interested in news and information about Microsoft DirectAccess, I have started another blog at directaccess.richardhicks.com. With this blog I’ll be writing about DirectAccess in Windows Server 2008 R2, Forefront Unified Access Gateway (UAG) 2010 DirectAccess, and DirectAccess in Windows Server 2012. In addition, I’ll be touching on topics related to VPN and remote access in general, IPv6, and core networking. DirectAccess is the way of the future for managed client remote access, so I would encourage you to follow my blog and stay up to date with this wonderful technology. Of course I’ll still continue to write about edge security and Forefront TMG 2010 here, don’t worry!
IP Spoofing Alert from APIPA Address in Forefront TMG 2010
Security administrators may encounter the following IP spoofing alert on their Forefront TMG 2010 firewall:
Alert: IP Spoofing Description: Forefront TMG 2010 detected a possible spoof attack from the IP address 169.254.x.x. A spoof attack occurs when an IP address that is not reachable through the network adapter on which the packet was received. If logging for dropped packets is enabled, you can view the details of this attack in the firewall log in Forefront TMG 2010 log viewer. If the IP address belongs to a VPN client, this event may be ignored.
This alert occurs because the Forefront TMG 2010 firewall received a packet on its internal network interface from a client (server, workstation, or other host) that did not have a statically assigned IP address and was not able to obtain one from DHCP, so the client selected an IP address from the Automatic Private IP Address Assignment (APIPA) address range defined in RFC 3927.
You can safely ignore this alert, or you can resolve the issue by adding the APIPA reserved network 169.254.0.0/16 to the Internal network definition. This can be accomplished by opening the Forefront TMG 2010 management console and highlighting the Networking node in the navigation tree, then right-clicking the Internal network, selecting the Addresses tab, then clicking the Add Private button and choosing the address range 169.254.0.0 – 169.254.255.255.
Note: It is possible to resolve this issue by disabling alerts for IP spoofing attempts. However, this is considered bad security practice and is strongly discouraged.
You may recall from an earlier blog post I indicated that the best way to configure the Internal network definition in Forefront TMG 2010 is to choose the Add Adapter option. This still remains true. However, this is one of those rare cases in which you’ll want add an additional network address space to your Internal network definition to reduce the volume of IP spoofing alerts being raised by the Forefront TMG 2010 firewall.
The one side effect to implementing this change is that you will now receive a Configuration error alert informing you that your Internal network does not correlate with the network adapters that belong to it.
Essentially you have traded one annoying alert for another. However, the noise generated by IP spoofing alerts from clients with APIPA IP addresses might make this tradeoff worthwhile. In addition, it is much safer to disable the configuration error alert than it is the IP spoofing alert.
Forefront TMG 2010 Protocol Direction Explained
When reviewing the configuration of a pre-defined protocol or creating a custom protocol on the Forefront TMG 2010 firewall, many new (and sometimes even veteran) firewall administrators can be confused by the protocol direction. The correct configuration of the protocol direction is essential for proper firewall operation, but there are times when it can be somewhat unintuitive. In this post I’ll provide some clarification.
TCP
For TCP protocols the direction can be specified as either inbound or outbound.
For access rules, protocol direction is configured as outbound. Traffic flows outbound from the source to the destination. This is true even when creating an access rule to allow traffic inbound to the Forefront TMG 2010 firewall itself. It sounds counterintuitive, but the TCP protocol direction for access rules allowing access to the Local Host network should still be outbound. Why? Again, because traffic flows outbound form the source to the destination, in this case the TMG firewall’s Local Host network. If, in this case, you were to configure the protocol direction as Inbound (intuitively, inbound to the TMG firewall) it will not work.
For publishing rules, protocol direction is configured as inbound. Traffic flows inbound from the source to the published service on the Forefront TMG 2010 firewall. Pre-defined server publishing protocols include the “server” suffix, as shown here:
UDP
For UDP protocols the direction can be specified as either Receive, Receive Send, Send, or Send Receive.
For access rules, protocol direction is configured as Send. Traffic is sent from the source to the destination. If a response is expected then the protocol direction is configured as Send Receive. This is required because UDP is connectionless and the return traffic would otherwise be denied by the TMG firewall.
For publishing rules, protocol direction is configured as Receive. Traffic is received by the TMG firewall from the source to the published service on the Forefront TMG 2010 firewall. If a response is expected then the protocol direction would be configured as Receive Send.
IP and ICMP
For IP and ICMP protocols the direction can be specified as either Send or Send Receive.
IP and ICMP protocol definitions are only supported for access rules, so protocol direction is configured as Send. As with UDP, IP and ICMP are connectionless and if a response is expected then the protocol direction is configured as Send Receive.
Bug in Forefront TMG 2010 Service Pack 2
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…
Microsoft Security Bulletin MS11-083 and Forefront TMG 2010
Included in the November Microsoft security bulletin release was security update MS11-083 (KB2588516) that addresses a critical vulnerability in TCP/IP that could allow remote code execution. Forefront TMG 2010 firewalls are protected from this vulnerability, as the firewall engine’s kernel mode driver processes packets even before the operating system sees them. More information about how the Forefront TMG 2010 firewall engine and service work can be found here [this document is for ISA, but TMG is similar]. Although the underlying operating system’s TCP/IP networking stack is protected by the Forefront TMG firewall engine driver, TMG administrators are still strongly encouraged to install the MS11-083 update as soon as possible.
Deploying IPv6 and Forefront UAG 2010 DirectAccess Technical Deep Dive
On Tuesday, September 20 2011, join me and Ed Horley at the Pacific IT Professionals Los Angeles event where we will be presenting a Technical Deep Dive on IPv6 and DirectAccess. During the first session, Ed will discuss in detail how to deploy IPv6 in a Microsoft enterprise network. During the second session I’ll dig in to Microsoft DirectAccess with Forefront Unified Access Gateway (UAG) 2010. The event begins at 6:00PM PDT and is being held at the Microsoft offices in downtown Los Angeles. For more information and to register for the event, click here.
Hope to see you there!
Connect
MVP Profile
