For those of you that have been installing Windows 2008 IIS7 systems with the new advanced FTP7 server know that one of the big new features is the suport of encrypted FTP through FTP over TLS/SLL
If you want more details on FTP7 you can check out the online tutorials at http://learn.iis.net/page.aspx/305/configuring-ftp-user-isolation/
However when pubulishing FTPS through ISA 2006 you’ll notice you get an error 500 Access denied.
To fully understand what’s happening we need 3 components
- Sniffer on the FTP client
- Monitoring on the ISA server system
- Sniffer on the FTP server
our setup:
PART 1: The authentication channel In this part well tackle the first issue we run into where the authenticaiton channel fails and we get the 550 Access is denied error.
Step1:
Try to connect to the FTP server from the FTP client and sniff at both ends. when we look at the packets we can clearly see what is happening:
we will first look at the packet trace and then make it easier for us by following the TCP stream.
1.1 packet view
As you can see the FTP client goes through the TCP handshake in the first 3 packets (SYN / SYN ACK / ACK)
Then the actual FTP communication starts, the first FTP command is the server identifying itself as an MS FTP server.
The client responcs to thes by saying AUTH TLS, it’s basically saying hellow friendly FTP server, i would like to start an encrypted TLS session. The clietn tries this twice but gets ACCESS IS DENIED packets back from the server.
When you look at the FTP server packets, ou can see the first 3 handshake packets, then the one packet where the server identifies himself but we never see another FTP packet comming into the FTP server with the AUTH TLS session.
1.2 follow view
If we to a TCP follow we can clearly see the the client sending the Auth SSL and the server never receiving these packets.
Step2:
Looking at the above information we can clearly see a responce 550 Access is denied being sent to the FTP client, but we can also see the packet did not originate from the FTP server. It’s clear then that not the FTP server but a device in the middle is generating this packet and sending it back to the client.
Using the information we have above lets look at the ISA log and see if we have any deny’s at that level.
At a first glance the traffic seems to be flowing normally, we see the ISA accept the first packet and then close the connection like it would do with any normal TCP connection that ended.
So where is theis Access Denied packet comming from. To find out a bit more we need to add an extra column to the ISA logging window called result code
once we add this column to the view we can see the the full details of what the ISA has been doing. To understand the meaning of each result code you can check out http://technet.microsoft.com/nl-be/library/bb838824(en-us).aspx
FWX_E_CONNECTION_KILLED => 0x80074E24 => ISA Server killed a connection.
Eventhough this type of end is not unusual it would seem that ISA took an active part in ending the session, and we know the only place the 550 Access is denied packet could have come from was the ISA.
This when we should start to look at the application filter within ISA. As you may know isa server is a layer 7 firewall meaning it does inspection at the application layer for a number of protocols. One of these protocols is FTP. You can view this on the add-ins tab
This means ISA understands the FTP protocol at the application layer and will recognise malformed commands with an FTP communication stream. According to the application filter dll we may or may not have configurable items.
As you can see in the comparison here the smtp filter has a way of adding and removing accepted commands. The FTP filter however does not, and all we can do is enable or disable it ( you can do this here and completely disable the filter for all ISA rules, or you can do it on each rule individually, this is what we will do)
The simple fact is that the FTP app filter in ISA does not support the AUTH TLS command in it’s current version 4.0 and the default reaction of an ISA on this type of fault is to respond with an Access denied. ISA server expects a default FTP command stream as listed below and there is no way for us to add accepted commadns.
It does not say, filterd by ISA as this would give potential hackers info you don’t want them to know.
The only way for us to solve this issue as of today in ISA 2006 will be to disable the FTP application filter on the rule. Traffic > properties > application filter
If we now retry our connection and sniff the traffic on the FTP server we can see the first packet with the identification string, the second packt is the FTP client saying hihg i want to do TLS authentication, the third packet is the server responding and saying ok lets do TLS and from there on the stream goes to an encrypted mode.
