File Transfer Protocol Services

Windows IT Pro

- Advertise

File Transfer Protocol Services
View the book table of contents

Author:	Tony Northrup
Published:	July 1998
Copyright:	1998
Publisher:	IDG Books

Abstract
This chapter will teach you both Microsoft Internet Information Server’s implementation of FTP services and the FTP standards IIS is based on. The author also offers troubleshooting tips to help you solve complicated FTP problems.

OVERVIEWING FTP SERVICES

FTP services have been provided with Windows NT since the first version, version 3.1. When IIS 1.0 was released, the FTP service was integrated into IIS, though it continued to run as a separate service.

It remained virtually untouched until IIS 4.0 was released. It can still be considered feature-poor, but it now supports multiple virtual servers, remedying a major drawback of earlier versions.

Microsoft’s Internet Information Server 4.0 provides a standard set of FTP server features. It has the capability to have a different FTP server directory structure for each IP address on the machine. It also has the capability to use virtual directories and, for the first time in version 4.0, virtual servers. These features allow the FTP file structure not to be bound by the physical file structure on the machine. The FTP service also supports assigning permissions using Windows NT’s built-in NTFS permissions and user accounts.

THE FTP MODEL

The File Transfer Protocol, commonly known as FTP, is another protocol made popular by the public Internet. FTP, as the name implies, allows files of any type to be transferred between a server and a client across a TCP/IP network. If this were the only functionality that FTP provided, it would have been rendered completely obsolete by the HTTP protocol. However, FTP provides for additional functionality that the HTTP protocol does not explicitly accommodate: file and directory management.

FTP, like HTTP and many other Internet protocols, makes use of English text commands between the client and server. This makes it an easy protocol to troubleshoot and to write programs to utilize. Another advantage of FTP is that it acts as a layer of abstraction between the client and the server’s operating system. While different vendor’s implementations of FTP may vary to some degree, an FTP server looks like any other FTP server, whether it is based on Windows NT or a flavor of UNIX.

FTP has existed in one form or another for more than thirty-five years. The current implementation of FTP is defined by RFC 959, though more than fifty RFCs relate to FTP in one way or another.

FTP Servers
Almost all network operating systems support FTP as a server. Windows NT, the focus of this book, has supported FTP services since version 3.1–long before an HTTP server was available. When Windows NT 3.1 was created, the FTP server was an attempt at UNIX compatibility and interoperability. Today, the FTP service is integrated into Microsoft’s Internet Information Server, which also includes HTTP services. Indeed, Microsoft has slowed development of its FTP service in favor of more modern technologies–the version of FTP included with IIS 2.0 and IIS 3.0 was almost identical to the original FTP released with NT 3.1.

As with most things on the Internet, Windows NT–based systems make up the minority. The majority of FTP sites on the Internet are hosted on UNIX-based systems. Nonetheless, the beauty of FTP is that any client can use any server–making the operating system unimportant.

FTP Clients
Every major desktop operating system includes support for the FTP protocol. Windows NT includes two separate programs for transferring files with FTP:

FTP: A command-line utility that allows full FTP functionality. It is not as commonly used as other alternatives because it has a clumsy user interface. However, it is flexible and can be used as part of batch files.
Internet Explorer: A graphical utility that supports only a subset of FTP’s functionality. In normal use, it only supports downloading files with the anonymous user account. It allows downloading a single file when provided with a full URL in the form of ftp://server.net/file.zip, and it allows navigation of the server’s file system when provided with a URL that does not include a filename.

Other common FTP clients include CuteFTP, WSFTP, and Netscape Navigator.

Working with FTP
If your work involves the Internet, you have to work with the FTP protocol. For network administrators, you have to understand the protocol well enough to configure your routers, proxy servers, and/or firewalls to handle it correctly. For ISPs, you have to know the implications of the protocol to troubleshoot problems that your clientele may have. For Webmasters, you have to understand the protocol to troubleshoot problems and to determine when it is appropriate to use FTP, and when it is not.

TROUBLESHOOTING
Troubleshooting FTP is a pleasure, at least compared to troubleshooting some other protocols. FTP is a very understandable protocol because all control communications occur in clear text. Problems you will run into using the FTP protocol usually fall into authentication or permissions categories.

Authentication problems include users who cannot log on, users who can log on but shouldn’t, and users who are authenticated but not authenticated with the correct permissions. One of the most common authentication problems with any protocol is the mistyped password. These problems carry over into FTP, but fortunately they are easy to troubleshoot. Consider the following scenario: You have just handed off the username and password to a new user, who is having problems FTPing into the server. Using a protocol analyzer, you could watch the commands as they are submitted to the FTP server, and verify that the user is typing the correct username and password. Later in this section I will detail exactly what you need to look for in the packets to distinguish the user’s username and password from all the other information being carried on the network.

Along the same lines, malformed usernames are a common source of authentication problems. It may be as simple as the user mistyping his or her name, or it may be more complicated. For example, some proxy servers simply strip out the backslash character from an FTP username, making it impossible for the user to log into FTP using a Windows NT domain user account (which must be submitted in the form DOMAIN\USERNAME). No matter what the problem, determining the exact data being submitted to the FTP server can, at the very least, eliminate a few possible sources of problems. This same technique can be used to verify that a user is logging onto FTP with the correct username and password and not using an FTP client configured to automatically log on with the anonymous user.

Permission problems are another common complaint of FTP users. These can be difficult to diagnose, because FTP client applications may replace the error message returned by the FTP server with something more user-friendly, such as Error: Command Failed. With the use of a protocol analyzer, you can determine exactly what the client is attempting to do with the server and exactly what error messages the server is returning to the client. By analyzing the protocol communications themselves, you can reduce the amount of time required to decode messages.

WRITING SCRIPTS AND APPLICATIONS THAT USE FTP
Many administrators may wish to automate certain tasks that use the FTP protocol. For example, an administrator may wish to write a script that will download several files from an FTP server on a regular basis. The administrator may even wish to create a script that checks for updated files in a directory and downloads them as needed.

Fortunately, there are many simple ways to script FTP commands. The simplest method is to use the FTP command with the -s operator. By executing a command in the form FTP -s:file.txt, the administrator can automate simple FTP tasks such as uploading or downloading a previously determined set of files.

If you require greater flexibility, Perl has a full library to simplify FTP communications. Most programming languages that include network support will include libraries for the FTP protocol, largely because of the long history and great stability of the protocol. If you are a truly gung-ho programmer, try writing FTP applications that work at the sockets level. Sure, you will waste a lot of time that could be used productively, but you will develop an extremely deep understanding of the protocols involved!

SNIFFING FTP
FTP is perhaps the easiest protocol to analyze using a sniffer. Commands and arguments are sent all at once in a single packet, so you do not have to piece traffic together from different packets as you may have to with the Telnet protocol, which sends characters as they are entered into the keyboard. All of the commands are in English (albeit many are severely abbreviated). Further, and this points to one of the major weaknesses of FTP, username and password are sent in clear text.

I will cover the way traffic flows in FTP in more detail in the next section, but it is useful to know that FTP exchanges commands with the server using TCP port 21. All data exchanges make use of TCP port 20. Therefore, it is simple to separate the commands, which are human-readable and make up the dialog between the client and the server, and the data transfer, which is probably just a bunch of binary data that nobody but a computer could make sense of. This is in contrast with the HTTP protocol, which uses TCP port 80 for all communications, commands, and data.

As Figure 17-1 shows, FTP is an excellent way to listen to other people’s passwords on a network. This is good news for malicious hackers, but bad news for us “good guys.” Anybody with a good understanding of the FTP protocol and the ways a network works can write a program that places the network interface card of a system into promiscuous mode and listens to all traffic on port 21. To grab usernames and passwords, it just has to listen to packets with the phrase “USER” (the FTP command that prefaces a valid username) and the phrase “PASS” (which prefaces a valid password). In this way, a host on a network could discretely collect usernames and passwords of any other machine on the same network segment.

This ease with which the service can be monitored is especially bad news for Windows NT, because it allows users to log onto the FTP service using a user account from a domain or from the local user database. Because of this, a stolen password can be used for much more than simply logging onto FTP: If an administrative password is stolen, it could be used on a domain controller to destroy an entire domain.

FTP Communications Flow
FTP, like most client-server protocols, is characterized by heavily asymmetric traffic patterns. Specifically, traffic generated by the client is typically much, much less than traffic generated by the server. For example, if a client downloads a 500K file from an anonymous FTP server (Internet-style), the client generates less than a dozen packets, each of minimal length. However, the server must transmit the entire file. This relationship is illustrated in Figure 17-2.

The FTP protocol is composed of two distinct communications channels. The first, the FTP Control channel, utilizes TCP port 21. This is a session-oriented dialog, initiated by the client. The second channel, the FTP Data channel, uses TCP port 20.

Once the client establishes a TCP connection to the FTP server, the server typically returns a welcome message (such as “220 ftp Microsoft FTP Service...”), which most FTP clients display on the console to the user. The FTP client must then offer to authenticate itself with the USER command. Unlike in a typical Telnet session, the FTP server does not prompt for a password.

Once the server receives the USER command from the client, it returns a message acknowledging receipt. A positive acknowledgement of 331 is considered a prompt for a password. The client then sends the PASS FTP command across the FTP Control channel, followed by a space and the actual password being submitted. Once again, the server acknowledges receipt with a positive or negative message.

If the client receives a positive message, it may now begin transferring files or issuing other commands that may perform tasks such as file and directory management. If the client requests a file be transferred (either direction), a FTP Data channel is opened from the server’s TCP port 20 to a port on the client that was specified at the time the file was requested. This is just opposite of what you would expect to happen–the server actually initiates a connection to the client to transfer data. Once this connection is established, the file is transferred through this communications channel, and the FTP Control channel typically waits until the transfer is completed to begin transferring other data.

Page: 1, 2, 3

ADS BY GOOGLE