Archive

Archive for the ‘Security’ Category

Windows Azure Multifactor Authentication and Forefront TMG 2010

November 12, 2013 1 comment

When Microsoft first announced Windows Azure Multi-Factor Authentication, a cloud-based strong authentication solution, my first thought was “I wonder if it works with Forefront TMG 2010?” Being cloud-based, my first thought was perhaps not. However, once I started digging in to it I quickly learned that it includes a software component that can be installed on-premises and will even integrate with on-premises security solutions via a number of interfaces, including RADIUS. Forefront TMG 2010 has supported RADIUS authentication for many years, so I put together a test lab and in no time at all I had Windows Azure multi-factor authentication working with Forefront TMG 2010 remote access VPN. Forefront TMG 2010 integrated with Windows Azure multi-factor authentication provides the highest level of protection for remote access users. Leveraging Windows Azure cloud-based strong authentication is extremely cost effective, with very low per user or per authentication costs and no on-premises hardware to purchase. The Windows Azure public cloud, which is ISO/IEC27001:2005 certified, provides the most secure and reliable strong authentication service available today. To learn how to configure Forefront TMG 2010 to work with Windows Azure multi-factor authentication, click here.

windows_azure

Improving SSL Security for Forefront TMG 2010 Published Web Sites

October 8, 2013 Comments off

Recently I wrote an article for ISAserver.org entitled Improving SSL Security for Forefront TMG 2010 Published Web Sites. In the article I demonstrate how to evaluate the current security configuration of your Forefront TMG firewall for published SSL web sites and how to make changes to the default settings in order to improve the overall security posture of TMG in reverse proxy scenarios. Implementing these changes will provide dramatically improved protection for Forefront TMG published SSL web sites. The steps outlined in the article include details for changes to be made to specific registry entries on the Forefront TMG 2010 firewall. I’ve had a number of requests to make the registry file available for download in order to simplify the process and ensure that these changes are made correctly. You can download the registry file used in the ISAserver.org post here. Enjoy!

Win a Copy of Windows Server 2012 Security from End to Edge and Beyond

As many of you know, I recently joined the team at Iron Networks to work more closely with DirectAccess and to be involved with some of their exciting new solutions for enabling the Microsoft private cloud. I was noticing that they don’t have much of a following on Twitter yet, so in an effort to change that I’m announcing a Twitter contest! This Friday, May 31, I will select one individual who is following both me and Iron Networks on Twitter and send you a free copy of Tom and Deb Shinder and Yuri Diogenes’ latest book entitled “Windows Server 2012 Security from End to Edge and Beyond”. I had the privilege of serving as the book’s technical reviewer and I can tell you it is an excellent reference that you’ll want to have in your library. So go out and follow me and Iron Networks for a chance to win!

Iron Networks

Windows Server 2012 Security from End to Edge and Beyond

Identifying and Reducing Anonymous Traffic Allowed by Forefront TMG 2010

March 4, 2013 Comments off

My recent blog post about altering the SafeSearch enforcement rule in Forefront TMG 2010 to require authentication has sparked some discussion on Twitter and Facebook regarding unauthenticated, anonymous access, particularly to resources located on the public Internet. In a perfect world (ok, my perfect world!), all access to and through the TMG firewall would be fully authenticated. Unfortunately, for a variety of reasons, this isn’t achievable. To start, authenticating all traffic to and through the TMG firewall would necessitate that all clients be configured as explicit web proxy clients. In addition, if non web-based protocols are allowed by firewall policy the Firewall Client would need to be distributed to all clients. While this is ideal if we’re designing a solution on paper, in the real world many administrators don’t have the luxury of forcing proxy configuration or installing the Firewall Client on all their systems. For example, some systems may not be under the administrator’s control or they may be required to support non web-based protocols on platforms other than Windows, for which the Firewall Client is not supported. Also, as veteran ISA and TMG firewall administrators know all too well, there are some applications that simply don’t play nice with an authenticating proxy, even with the Firewall Client installed. Applications that don’t leverage Winsock for network communication or that use IP-based protocols such as ICMP or GRE also prevent us from realizing our goal of authenticating all network traffic through TMG. Windows Update traffic also poses challenges for authenticating all TMG traffic, as the Windows Update service often makes requests to the Internet for updates in the background and perhaps even if there is no interactive user logged on.

Just because out of necessity some traffic has to be allowed through the TMG firewall anonymously doesn’t mean that undertaking an effort to reduce unauthenticated traffic isn’t a worthwhile project. If you’re interested in doing something like this, have a look at the Fastvue blog and read Scott Glew’s excellent article detailing how to use TMG Reporter to identify and reduce unauthenticated traffic on the Forefront TMG 2010 firewall. Not using TMG Reporter? You’re missing out! Download a free evaluation here!

Forefront TMG 2010 Protocols and Ports Reference

September 10, 2012 5 comments

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

August 22, 2012 9 comments

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.

Windows 8 Security from End to Edge And Beyond

It is with great pleasure that I can announce I have recently signed on with Syngress to be the technical reviewer for Tom Shinder and Yuri Diogenes’ new book about Windows 8 security. I’ve been spending a lot of time over the last few months getting to know Windows 8, both server and desktop. Until now I’ve been focused mostly on new features, specifically around the core networking and remote access capabilities (which are exceptional!). Working on this book with Tom and Yuri will be an excellent opportunity to learn about all of the wonderful new security features of the latest Microsoft operating system. As a network security specialist and former information security engineer for a Fortune 100 financial services institution, I’m hoping I can provide helpful and meaningful feedback to these two experienced and talented authors. I’ll post more details about the book when I can share them. Until then, watch this space as well as Tom and Yuri’s blogs for latest news about this new book!

Categories: General, Security