Describing an alternative method to FTP over TLS by the use of WebDav over TLS published through ISA 2006 Firewall - Part 1

Carbonwind.net

Home

Blog

Articles

Books

Links

Tools

About

Contact

Disclaimer

Forefront TMG

ISA Server

Vyatta OFR

VPN

Virtualization

Firewalls

Cisco

Miscellaneous

Wireless

21.01.2008
Describing an alternative method to FTP over TLS by the use of WebDav over TLS published through ISA 2006 Firewall - Part 1 - Overview

In this article we will describe an alternative method to FTPS(FTP over TLS).

A lot of people use WebDav over TLS for viewing files and easily manage them(drag and drop). It's actually quite popular among universities for example.

The old FTP protocol does not meet the security requirements for transfering files over an insecure connection. FTP over TLS can perform secure file transfers. It uses SSL/TLS to encrypt the control and/or data channels. RFC4217 Securing FTP with TLS, an "Internet Official Protocol Standards" (STD 1), describes FTPS.

Before moving to WebDav let's first discuss FTP and FTPS. You can skip this part but I think is quite useful to put a couple of pictures along with a few comments about FTP and FTPS.

Note: FileZilla FTP Server and Serv-U FTP Server (Trial Version) were used as the FTP servers within this article. GlobalScape CuteFTP 8.1 Professional (Trial Version) served as the FTP client. The FTP server is using 192.168.22.58 as the IP address and the FTP client 192.168.22.70 respectively.

Without entering into a too technical dicussion let's quickly analyse FTP and FTPS.

As you might know FTP uses a control channel and a data channel. By default, FTP servers listen on TCP port 21 for incoming connections from FTP clients. So TCP port 21 is used for the control connection used to exchange FTP commands and control information. For the data connection, for Active FTP, TCP port 20 is used and for Passive FTP, a random TCP port is used on the server side. The data connection is used to transmit the files.

In case of Active FTP the client issues the "PORT" command specifying a port on which the server will connect back for the data connection. Then the server wil connect using the source TCP port 20 and the destination port which was specified by the client with the "PORT" command(see Figure1, a Wireshark capture).

Figure1: The FTP PORT Command

If the client is behind a firewall, this firewall(if unaware of the FTP protocol) will simply drop this connection because it appears as an inbound connection.

"A Firewall-Friendly" approach will be to use Passive FTP. In this case the FTP client will issue the "PASV" command to the server and the server will pick up a random port on which the client will connect back for the data connection(see Figure2).

Figure2: The FTP PASV Command

If the FTP server is behind a firewall doing NAT, the firewall must recognize FTP in order to allow the connection for the data channel. And that's not all. As you can see from Figure2, the server response to the "PASV" command contains an IP address. Since the server is behind a NAT device, it must be aware of the public IP address of that NAT device(some FTP servers let you manually specify it or can detect it by themselves or the FTP client, like the FileZilla FTP Client, can be configured to use the server external IP address instead of the local one received within the response to the PASV command). To overcome this issue the client can use the "EPSV" command ("Extended Passive Mode"). Doing so, the server will reply back only with the port number and the client assumes that it will connect to the same IP address that was originally connected to (see Figure3). Please refer to RFC2428 FTP Extensions for IPv6 and NATs, an "Internet Official Protocol Standards" (STD 1).

Figure3: The FTP EPASV Command

However not all the FTP servers currently support the EPSV command. We can draw a simple conclusion: we need more ports "open" on the firewall from a packet filtering point of view and also it is desirable to have an application filter for FTP. ISA 2006 Firewall comes with an application FTP filter, please read the following:
http://www.microsoft.com/technet/isa/2006/application_filters.mspx

As you can notice the simple FTP protocol can put some pressure on the firewall.

Talking about FTPS, some firewalls might simply throw in the towell due to fact that the control and data chanels are encrypted so the firewall can't inspect FTP traffic and thus recognize FTP commands.

But how FTPS work?

We have two modes: Explicit SSL(preferred mode as defined per RFC) and Implicit SSL(an old mode).

Implicit SSL means that the connection is secured by default and the client will connect to TCP port 990.

Explicit SSL means that security can be requested when desired with the "AUTH SSL" command (see Figure4 and Figure5). Note that the "AUTH TLS" command can be used too (see Figure6).

Figure4: FTPS PASV Requesting AUTH SSL

Figure5: FTPS PASV Starting the data connection

Figure6: FTPS PASV Requesting AUTH TLS

Now the authentication and the "PASV" or "PORT" commands are protected by SSL. Therefore the firewall cannot sniff anymore the ports required by FTP in order to dynamically "open" up them.

However the control channel or the data channel can remain unprotected.

The data channel is secured by use of the "PBSZ" ("Protection Buffer Size") and "PROT" ("Data Channel Protection Leve"l) commands. See RFC2228 FTP Security Extensions, an "Internet Official Protocol Standards" (STD 1).

According to RFC2228:

"The PBSZ command is compulsory prior to any PROT command. This document also defines a data channel encapsulation mechanism for protected data buffers. For FTP-TLS, which appears to the FTP application as a streaming protection mechanism, this is not required. Thus, the PBSZ command MUST still be issued, but must have a parameter of '0' to indicate that no buffering is taking place and the data connection should not be encapsulated."

So the FTPS client will use the "PBSZ 0" command(no buffering) prior to the "PROT" command.

The FTPS client normally issues the "PROT P" command meaning that the protection level is set to "Private", this indicates that the data will be integrity and confidentiality protected.

But the client can issue the "PROT C" command (the protection level is "Clear") meaning that the data channel will carry the raw data of the file transfer, with no security applied. Therefore only the control channel is protected (the credentials are protected too).
Also the client can issue the "CCC (CLEAR COMMAND CHANNEL)" command meaning that the credentials, the "PBSZ" and "PROT" commands will be secured while the rest of the control session continues in plaintext, thus the "PASV" command will be sent in clear(see Figure7 and Figure8, now 192.168.22.70 represents the FTP server). Typically the "AUTH" (authentication needed), "USER" (specify user name), "PASS" (specify user's password), "PBSZ", and "PROT" commands would be protected within the TLS protocol and then the "CCC" command(also TLS protected) would be issued to return to a plaintext socket state.

Figure7: FTPS PASV CCC

Figure8: FTPS PASV CCC, the PASV command is sent in clear

Note that the use of the "CCC" command has serious security issues since an attacker could insert a command on the control stream, and the server would have no way to know that it was invalid. One scenario where the "PROT C" might be used is the case when the credentials must be protected but the data can be passed in clear.

Therefore it is unlikely that the firewall will see the needed FTP commands in order to properly allow FTPS communication.

Also the firewall cannot trully inspect (meaning application layer inspection) the FTPS traffic(in case you publish a FTPS server behind it) because it is encrypted thus the firewall is dumbed into stateful packet filtering mode which really does not give you much for your server these days (and TCP ports used for filtering are meaningless, you can pass "anything" over TCP port 21).

For a high security environment, a feasible scenario will be to first pre-authenticate the client at the firewall and then allow traffic to pass while the firewall is able to inspect/filter the encrypted traffic passing through it.

Also, if you connect to a remote FTPS server behind your firewall, if you do not know the exact port range used by the remote FTPS server(for Passive mode) you might need to allow through your firewall communications over TCP ports > 1023 to the IP adrress of the FTPS server(something you may not want). So a restrictive firewall policy might block your FTPS access.

FTPS allows you to request a client certificate, so you can use two level of authentication, TLS and user credentials(user name and password). But both the FTPS Server and Client must support this.

Enough about FTPS.

WebDAV(Web-based Distributed Authoring and Versioning) refers to a set of extensions to the HTTP (Hypertext Transfer Protocol) which allows users to download, upload, edit, rename or delete files(thus to manage files) on remote World Wide Web servers.

WebDav is described through the following RFCs:

We are going to use WebDAV over SSL to securely publish content to an IIS 6.0 (Internet Information Services) web server(Windows 2003 Standard R2 SP2).

WebDAV adds methods like "PROPFIND", "MOVE", "COPY", "MCKOL", "PROPPATCH", "LOCK" or "UNLOCK" to HTTP.

WebDAV uses port 80, the same port used by HTTP. Within this article we will tunnel WebDav over TLS thus TCP port 443 will be used. Already a contrast with FTPS where we need a couple of TCP ports, thus our firewall is starting to not feel the pressure. And when we are away behind a restrictive firewall we should be able to connect without any major problems.

With WebDAV you can edit files directly on the remote server, just as they were locally on your computer(with the right client on a fast network).

Also while allows multiple users to read a file, WebDAV lets only one user to modify a file at a time. So the file is locked(overwrite prevention) while it's being edited. And WebDav can be used for file storage(web-based) accessible from anywhere(you can easily download, upload, rename, move or delete files) which we want to achieve.

As you can see WebDav has certain advantages over FTP.

In the scenario described within this article, you have the following options for viewing/accessing data(Windows XP has a built-in WebDAV client):

Note: Figure9-14 show images while the IIS 6.0 server is behind the ISA 2006 Firewall.

- Use the web browser interface(see Figure9 and Figure10), so you can browse, list, save or open(supported files)

- “Open as Web Folder” from Internet Explorer(by selecting File/Open and checking the checkbox mentioned before), see Figure11. Here you can "upload" files too, rename or move.
- Add a Network Place in My Network Places thus creating a shortcut to the web folder(see Figure12). For example you can directly open Office documents(such as Word docs), edit them and save them to your Web Folder from within the application.

By Browser Interface
Figure9: IE 7.0 Web Browser Interface

Firefox
Figure10: Firefox 2.0 Web Browser Interface

Figure11: Accessing the Web Folders

Figure12: Accessing the Web Folders from My Network Places

However the Windows built-in WebDAV client migth have some bugs.

Talking about Linux Distributions, Figure13 shows CentOS(version 4.4) in action under the scenario from this article. The WebDav client used by CentOS is Neon 0.24.6.

Figure13: Accessing remote files through WebDavs on CentOS

To unleash the power of WebDav you can use the WebDrive application(version 7.34 was used within this article), see Figure14, which mounts a WebDAV site as a seperate drive, like W:. Then, any program or so can be used to open/edit your documents, you can upload and download files, browse and so on. Although WebDrive is not free(you can download a trial version to see it in action) immediately starts packin' and runs like a champ.

Figure14: WebDrive

Other OS's have their own WebDav clients, for example OS X( I can't discuss it because I do not have a Mac). We will talk more about various WebDav clients later.

Publishing WebDav over TLS through ISA 2006 Firewall enable us to use features like SSL bridging, pre-authentication, HTTP filtering or user level control.

Actually adding ISA 2006 Firewall into equation gives us a high secure method for transfering files.

Since ISA pre-authenticates any client, no packet will reach the IIS server before ISA accepts the user credentials. Also ISA does SSL bridging meaning that you actually terminate the TLS tunnel on ISA and ISA initiates another TLS connection to the IIS server. In this way ISA is able to do HTTP filtering(normaly encrypted traffic cannot be inspected by the firewall) which is a key security feature these days. Since you know what HTTP methods are good for your WebDav server you can instruct ISA to allow only these methods. Thus if for example ISA is set not to allow the "DELETE" method, when the client will use it, it will blocked at the firewall and therefore it will never reach the IIS server.

So with ISA 2006 Firewall the high security scenario becomes immediately feasible.

Figure15 shows the network diagram.

Figure15: The Network Diagram

ISA 2006 Firewall has three NICs: WAN(External Network), LAN(Internal Network) and DMZ(Authenticated DMZ). Also ISA is a domain member.

As you can see the WebDav server is located on an authenticated DMZ meaning that it is a domain member. Therefore you need to allow intradomain communication through ISA between the DMZ and the Internal Network.

Why ? Is really necessary to have this authenticated DMZ(instead of a normal DMZ) ?

Maybe not. However you can gain advanced control over what your users do by using domain accounts. ISA pre-authenticates the clients and then delegates credentials to the IIS server using domain credentials. Very simple and efficient. Most likely this scenario applies very well in the case of private corporate FTPS like access.

Using NTFS permissions on the IIS 6.0 server with domain accounts you can centrally manage access to the folders published. In fact every user can end-up with his/her own home directory while other general folders can use Domain Groups permissions(more restrictive). Therefore you can easily achieve a granular control on the IIS server.

With ISA 2006 pre-authentication you can do more than only limit who's accessing the WebDav server. You can "multiply" your web publishing rule(meaning simply copy and paste) and then apply the "new" web publishing rule to another set of users. Say Rule 1 will allow multiple HTTP methods for a group of users(power users) while for another group of users with Rule 2 you can allow only a few HTTP methods(block "DELETE", "PUT", "COPY" and "MOVE" for example). Thus this group can only view and secure download data while they cannot delete, upload, duplicate or rename files on the server. Rules are processed from top to down. It is assumed that the appropiate NTFS permissions are set on the WebDav server. But with ISA you have the chance to block the unwanted/dangerous actions at the firewall. We will discuss later all these.

In Part 2 we will configure the IIS server.