Mike Howells's Blog

Just another WordPress.com site

Archive for the ‘Firewalls’ Category

Allowing FTP over HTTP with Microsoft Forefront Threat Management Gateway

Posted by mikehowells on February 18, 2013

I’ve been working with Microsoft’s Forefront Threat Management Gateway (TMG) since it was released back in November 2009 and it continues to surprise me…

What I thought would be an easy protocol addition to an existing access rule turned out not to be the case.

I was notified of an issue whereby users were suddenly unable to access a FTP site that they had been using for years. Their method of accessing the FTP site was to enter the URL of the FTP site within the address line of Internet Explorer (IE) using this format: ftp://username:password@example.com

I found it interesting that this was working just fine with ISA Server 2004/2006 but suddenly did not work with TMG 2010. Considering that we just switched from ISA 2004/2006 to TMG 2010 it didn’t surprise me that something broke because I figured TMG is handling it differently, which it is.

When you access an FTP site within Internet Explorer, TMG treats it as “FTP Over HTTP” instead of just plain ‘ol vanilla FTP. Since this new protocol was not defined in any existing access rules I had to go into the Enterprise-level policy and add the “FTP Over HTTP” protocol to the access rule.

I selected my “FTP Access” rule at the Enterprise-level policy, went to the Protocols tab, selected Add and looked for the “FTP Over HTTP” protocol as I saw earlier. As hard as I looked, I could not locate this protocol!

2-18-2013 3-03-56 PM

I decided to open a case with Microsoft, who confirmed with me that this is a bug with TMG. Unfortunately, since TMG has been EOL’d (End-Of-Life’d) they have no plans to fix this.

The work-around to fix this problem is to add the access rule at the array-level. Unfortunately, this means a lot of manual work especially if you have numerous arrays to manage.

2-18-2013 4-15-21 PM

You can simply add the “FTP Over HTTP” access rule to your existing web access policy at the array-level. Or, more likely, you’ll want to create a separate access rule especially if you do not want everyone to have access to this protocol.

Shown here is the “FTP over HTTP Access” rule successfully added to the array-level policy:

2-18-2013 3-28-30 PM

When you log access to this rule you’ll notice another cool feature. You can see the developers of TMG anticipated that the password information for FTP sites are sent in clear-text and that this information may be easily viewed via the live logging session. So they remove the password during a live logging session as shown below:

2-18-2013 3-57-26 PM

There is one additional workaround available to you. If you do not want to create a special access rule in TMG to allow this behavior, you can make a change in Internet Explorer. Simply open Internet Explorer, select Tools, Internet Options, Advanced and scroll down to the Browsing section. In the Browsing section you will see a setting called “Enable FTP folder view (outside of Internet Explorer).” Checking this box will allow you to access FTP sites within Windows Explorer and it will not invoke the “FTP Over HTTP” protocol.

2-18-2013 4-03-34 PM

If you’d like to learn more about publishing FTP in ISA Server or TMG that a look at the following article. It is the most thorough discussion on FTP in ISA and TMG that I have seen:

http://microsoftguru.com.au/2010/08/27/troubleshooting-outbound-ftp-access-in-isa-tmg-server/

If you are interested in adding/allowing malware inspection for FTP access rules in TMG checkout the following article (normally this is not possible):

http://carbonwind.net/blog/post/Forefront-TMG-2010-Using-malware-inspection-and-URL-filtering-for-FTP-on-access-rules.aspx

Advertisements

Posted in Firewalls | Tagged: , , , , | 3 Comments »

Proxying requests to the published site using ISA Server or Threat Management Gateway

Posted by mikehowells on August 7, 2010

In ISA Server 2004\2006 or Forefront Threat Management Gateway 2010 the “Proxy requests to published site” setting is one of the most confusing yet simple configuration options when publishing a server.

When you publish a website using the website publishing rule feature the default setting is to select the “Requests appear to come from the Forefront TMG computer” radio button available in the To tab of the website publishing rule’s properties dialog box. This is what I would call the “safe” option but as we’ll find out not necessarily the correct option for your environment (see image below):

Note: The default setting for publishing non-web server publishing rules is set to “Requests appear to come from the original client.” More on this specific setting at the end of this article.

TMG Listener

TMG Listener

With the setting “Requests appear to come from the Forefront TMG computer,” the logic is as follows:

The request comes into TMG and TMG sends it back to the web server. When TMG does this it changes the “Source IP” address field in the IP Header to its Internal adapter IP address. When the web server sees this request (assume it’s on the same logical segment as TMG), it sees the source IP is TMG. The web server then checks its routing table and says “This address is directly accessible to me. All I have to do is ARP for this IP and if I get a ARP response, I’ll deliver it directly to that host.” The response is complete as far as the web server is concerned.

Now, with the setting “Requests appear to come from the original client,” the logic goes like this:

The request comes into TMG and TMG sends it back to the web server. When TMG does this it leaves the “Source IP” address field in the IP Header alone (i.e. the external client’s IP is maintained.) When the web server sees this request (assume it’s on the same logical segment as TMG) it sees the Source IP as someone on the Internet. The web server then checks it’s routing table and says “This address isn’t directly accessible to me. My routing table says that if I don’t have a more specific route I’ll just punt and send it to my default gateway. Let me ARP for the gateway and if I get a response, I’ll deliver it to that system”. The request is now done as far as the web server is concerned.

You can see this behavior by opening a command prompt and typing “netstat -ano” without the quotes. This command displays your current network connections. You will be able to see the internal TMG source IP address or the client source IP address depending on the setting you have in TMG.

With the setting for “Requests appear to come from original client” it is essential that the return path for the responses from the web server honor the incoming path of the request. In other words, if the request came in from TMG and this setting is enabled, then the response has to go out through TMG as well. In other words, if you select the option “Requests appear to come from the original client” you must have the web server’s default gateway set to the TMG’s internal IP address! This begs the question as to why can’t TMG’s response go out some other device for the response such as another internal router? There are two reasons for this:

1) If the other device is capable of stateful inspection, it will not have any state for the response from the web server since the original packet came in through TMG.

2) Even if that device doesn’t perform stateful inspection it most likley does NAT. As the response goes through that other device, the Source IP will get changed to the NAT device’s IP and by the time the original client gets the response, the Source IP is not who the client sent it’s request to and it will drop the response.

They say a picture is worth a thousand words and in this case a graphical representation of what is going on helps. Below are four graphs depicting the four possible scenarios.

Scenario 1: Requests appear to come from the TMG computer. Default Gateway is TMG.

The below graph shows a client request traversing through TMG with the default setting of “Requests appear to come from the Forefront TMG computer.” The default gateway of the web server is set to TMG. This configuration will work but the downside to this configuration is that the web log files will only contain the IP address of the TMG’s internal interface obfuscating the true source of the request. This is a surefire way to infuriate the marketing folks, which for some of you may actually be an enjoyable thing to do. This scenario is a safe option but totally unnecessary in my opinion. If the Web server’s default gateway is set to the TMG server then there is no reason to have the requests appear to come from the Forefront TMG computer unless you want to purposely obfuscate the IP addresses in the web log files.

Requests appear from TMG, DG=TMG

Requests appear from TMG, DG=TMG

Scenario 2: Requests appear to come from the TMG computer. Default Gateway is a router.

The below graph shows a client request traversing through TMG with the default setting of “Requests appear to come from the Forefront TMG computer.” The default gateway of the web server is set to another router. This configuration will work but you have the same downside to this configuration as scenario 1 in that the web log files will only contain the IP address of the TMG’s internal interface. You will typically encounter this scenario in larger enterprises where they likely have a more complex routing infrastructure and they want the web server’s default gateway set to a router for policy reasons.

Requests appear from TMG, DG=Router

Requests appear from TMG, DG=Router

Scenario 3: Requests appear to come from the original client. Default Gateway is TMG.

The below graph shows a client request traversing through TMG with the setting of “Requests appear to come from the original client.” The default gateway of the web server is set to TMG. This is the most common scenario and the one that I use almost exclusively. This configuration will work and the web log files will contain the client’s Source IP address. I can hear the marketing folks jumping for joy.

Requests appear from client, DG=TMG

Requests appear from client, DG=TMG

Scenario 4: Requests appear to come from the original client. Default Gateway is a router.

The below graph shows a client request traversing through TMG with the setting of “Requests appear to come from the original client.” The default gateway of the web server is set to a router. I’ve saved the worst scenario for last because this is the scenario where people get into trouble.  This scenario will not work because the client’s source IP address is maintained all the way to the TMG server but the TMG server forwards its response out through its default gateway breaking the chain of communication.

Requests appear from client, DG=Router

Requests appear from client, DG=Router

The question then becomes how can you maintain the client’s Source IP address in the web logs in this scenario?  The answer is to use the X-Forwarded-For HTTP header field.  This is a de facto standard for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer. Checkout the below article that describes how to use Winfrasoft’s X-Forwarded-For client for ISA and TMG server:

http://www.isaserver.org/tutorials/X-Forwarded-For-ISA-Firewall-Track-Originating-Client-Web-proxy-Chain-IIS.html

At the beginning of this article I briefly mentioned that the default setting for publishing non-web server protocol publishing rules is for the request to appear from the original client. So, the question then becomes why is this default setting different from publishing standard website publishing rule? I came across a possible scenario which may explain the reason. When publishing the latest version of a Microsoft CRM website you must use HTTPS.  Microsoft CRM uses forms-based (or claims-based) authentication so that you log in using a secure form to gain access to your CRM website. What if you want to securely publish CRM for multiple companies using a wildcard SSL certificate? You would purchase a wildcard SSL certificate (i.e. *.example.com) and then you would create a non-web server protocol publishing rule in TMG using the HTTPS protocol. This wildcard SSL certificate then allows you to host CRM for multiple companies such as company1.example.com, company2.example.com and so on using a single HTTPS web listener. Microsoft CRM has intelligence built into the form whereby it inspects the URL that you are sending it and then depending on the URL it will forward you to the proper CRM database on the back end. This behavior only appears to function properly when you have the HTTPS rule set to have requests appear to come from the original client. If you have the other setting applied where the TMG server replaces your source IP with its IP address you will no longer get a form to sign on with but instead you will be presented with a pop-up window to logon to the domain.

HTTPS Listener

HTTPS Listener

Posted in Firewalls | 8 Comments »

TMG vs UAG Confusion

Posted by mikehowells on July 7, 2010

Are you confused about the functional differences between TMG (Threat Management Gateway) and UAG (Unified Access Gateway)? You’re not alone.

Thomas Schinder (MSFT) sums it up nicely by mentioning that UAG is designed to be an Enterprise solution for remote access into internal corporate resources without supplying any outbound access.

TMG is designed for both inbound and outbound access but at a more comfortable price point for SMB’s.

Here is a good TechNet thread where numerous Microsoft’ees chime in with their opinion:

http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/b8d0e1fe-9ab6-4b88-a2cc-4ad016c45196

Posted in Firewalls | 1 Comment »