In this chapter, you will explore the File Transfer Protocol (FTP). FTP is one of the cornerstones of the Internet, and it is an invaluable protocol for transferring files. FTP also is a useful protocol for sharing data, and using it wisely can help free up bandwidth on your local area network (LAN).
You will explore not only how FTP works, but also when it works best. You also look at the different implementations of FTP client and server software on different operating systems and examine their high and low points. The difference between FTP clients and servers also is addressed here. Over the course of this chapter, keep in mind that understanding the issues involved with logging into FTP and authenticating it are important. If any one issue stands out above all others, it would be this one, because a lax logon procedure to FTP can greatly compromise your entire LAN.
FTP is a component of the TCP/IP protocol stack. If you are familiar with the OSI seven-layer model, FTP functions at the application layer, at the same level as Telnet, the Simple Mail Transfer Protocol (SMTP), or any other TCP/IP application that interacts directly with the user. FTP specifications have been a key networking tool for more than two decades, and they have a proven track record in most major systems. The rise of the Internet as a tool for businesses and now the masses has greatly expanded use of FTP. Although once used only by systems experts and scientists, today FTP is popular among general users who have come to rely on it through their use of Web browsers and other similar programs.
Before I get into too much detail about FTP, an example describing how FTP works is in order. As I mentioned earlier, you use FTP to download and upload files across a local area network (LAN) or wide area network (WAN). As an example, imagine a user who wants to access a copy of a technical bulletin from a computer on her LAN and copy it to her own PC sitting at her desktop. Assume that this user's PC is running TCP/IP, and the system from which she wants to download the bulletin is on a UNIX file server named rocket. The file she wants is named bulletin.doc and is located in the directory /usr/docs. Following is an example of how the fictional user can download this file. Commands that appear in bold are those entered by the user.
C:\> cd temp C:\TEMP>dir Volume in drive C is HAMSTRBRAIN Volume Serial Number is 1234-ABCD Directory of C:\temp 04/24/96 08:57a <DIR> . 04/24/96 08:57a <DIR> .. 2 File(s) 0 bytes 300,638,720 bytes free C>\TEMP> ftp rocket Connected to rocket. 220 rocket FTP server (SunOS 4.1) ready. user (rocket:(none)): suzanne 331 Password required for suzanne Password: ****** 230 User suzanne logged in. ftp> cd /usr/docs 250 CWD command successful. ftp> dir 200 PORT command successful. 150 ASCII data connection for /bin/ls (196.32.43.4,1945) (0 bytes). -rw-r--r-- 1 paul staff 2644 Mar 6 12:54 bulletin.doc 226 ASCII Transfer complete. 68 bytes received in 0.01 seconds (6.80 kbytes/sec) ftp> ascii 200 Type set to A. ftp> get bulletin.doc 200 PORT command successful. 150 ASCII data connection for bulletin.doc (196.32.43.4,1946) (2644 bytes) 226 ASCII Transfer complete. 2705 bytes received in 0.05 seconds (54.10 Kbytes/sec) ftp> quit C:\TEMP> dir Volume in drive C is HAMSTRBRAIN Volume Serial Number is 1234-ABCD Directory of C:\temp 04/24/96 08:57a <DIR> . 04/24/96 08:57a <DIR> .. 04/26/96 11:59a 2,644 bulletin.doc 3 File(s) 2,644 bytes 300,134,912 bytes free
Let's review what happened on a line-by-line basis. First, the user, Suzanne, moves to the directory TEMP on the C drive on her PC and confirms that nothing is in it. Next, she uses the command ftp rocket to enter the FTP client program and open a connection with the server named rocket on her LAN. Rocket acknowledges that the connection is established and asks for a valid username and password. Note that Suzanne must have a valid login account on rocket to proceed with the FTP session. (FTP can be configured so that individuals without valid logons can gain access. This process is known as anonymous FTP and is addressed later in this chapter.) After the user successfully provides her logon name and password (I replaced her password with asterisks), rocket acknowledges that she has entered a correct name and password and passes control back to the FTP client program with a connection open between her system and rocket. Suzanne sees the FTP client program's prompt: ftp>.
Next, Suzanne uses the cd command from within FTP to change to the directory with the file she wants. Note that the cd command behaves within FTP much like cd does in UNIX or MS-DOS. The cd command moves Suzanne through the directory tree of the remote system. As far as FTP is concerned, the current working directory on her local machine is still C:\TEMP. Suzanne then uses the ls command to get a listing of the files within her current working directory on the remote system, which is /usr/docs. She successfully identifies her target file, bulletin.doc, as being in this directory.
Suzanne, knowing that this is a flat ASCII text file and not a specially formatted file, such as an MS Word document, uses the ascii command to set the communication mode as ascii rather than binary. (The significance of the mode is addressed later in this chapter; see the sections "ascii" and "binary.") She next uses the get command to get the file from the client and place it in her current working directory on her local machine. The FTP program provides some statistics with regard to the data transfer and informs Suzanne that her transfer is complete. She then uses the quit command to close her session with rocket and exit the FTP client program. A quick type of the dir command confirms that the file exists on her local system, and Suzanne is done.
The heart of FTP is in the commands get and put. get requests files from the FTP server to which the connection is made and downloads them to a directory on the local machine. put sends files from the local directory and puts them in a specified directory on the FTP server. Figure 27.1 illustrates this process.
Figure 27.1: A contrast of the get and put commands.
FTP is a protocol that involves two systems, one that requests a file transfer (the client) and one that then approves the request and does the sending or receiving (the server). These two systems have very different roles.
The client side of FTP is basically an interface to make FTP more usable for an end user. It provides an easy way for the end user to specify a transmission mode, from which directory to pull data, or other information pertinent to the FTP session. Every TCP/IP implementation comes with an FTP client program and is executable with the ftp command. Most PC and Macintosh-based TCP/IP packages have a graphical user interface (GUI) front end, so instead of typing the commands discussed earlier, you access FTP commands by using either pull-down menus or buttons the user clicks to invoke a particular FTP command. (An example later in this chapter shows an FTP client GUI and where commands typically may lie in a GUI.)
The server side of FTP does not run like the FTP client program. The FTP server functions in the background where it sleeps until an FTP client attaches to it. After an FTP client attaches to an FTP server program, the FTP server program wakes up, acknowledges that client, and handles the important task of authentication. The FTP server determines whether the username and password are correct and permits the client to proceed or denies access. (The "FTP Servers" section later in this chapter discusses how users and passwords are handled on a platform-by-platform basis.)
The FTP server program manifests itself in different ways on different
systems, but it does not exist as an executable program. Rather,
it is a process that exists on a server, as you can see in Table
27.1. What is important to remember here is that commands are
executed from within the FTP client program and that the FTP server
is not a program with which the end user deals directly.
| Platform | Implementation of FTP Server |
| UNIX | Daemon |
| MS-DOS | TSR that can be invoked as an executable |
| Windows NT | Service |
| Macintosh | Extension |
With the fundamentals of FTP clients and servers established, you're ready to examine some of the commands available within the FTP client program.
To begin an FTP session, you must run the FTP client program. In the sample FTP session earlier in this chapter, this occurred when Suzanne typed ftp rocket. Typically, you enter FTP in one of two ways:
It is clear that the FTP program has been entered when you see the prompt display (ftp>). GUIs to FTP are discussed later in this chapter.
If you need help or a list of what commands are available from within FTP, at the FTP prompt, type the command help or a single question mark (?). Doing so generates a list of all commands available from within FTP, as shown in Figure 27.2. If you want information about a specific command, typing help [command] yields a one-sentence description of the command.
Figure 27.2: Getting assistance for FTP commands.
As I mentioned earlier, you use the ascii command to set the transfer mode to ASCII data instead of binary. This mode for transfer of raw text or ASCII data is efficient and fast. It also is most often the default mode of FTP, because file transfers are much faster in ascii mode than in binary mode. Beware: Executable binary programs do not work when transmitted in ascii mode. If a program does not operate successfully after being sent or received via FTP, check to see if the program was transmitted in ascii mode. Users commonly make this mistake.
The binary command is the partner to ascii. It sets the transmission mode as binary, meaning data will be transferred byte-by-byte as opposed to ASCII-character-by-ASCII-character. Although binary guarantees that a file transfer is complete and error free, it also is more time-consuming than ascii mode. Using binary, however, is the only way to transfer binary executable files.
The bye command terminates an FTP session and exits from the FTP client program. It behaves identically to the quit command and exists to provide a set of commands familiar to users who have more exposure to mainframes than the PC or UNIX world.
The FTP command cd permits movement through the directory tree on the remote system to which it is connected. The cd command functions much like the cd command does in UNIX or MS-DOS. The command cd .. moves you up a level in the directory tree, and a single dot (.) specifies the current working directory. Both a forward slash and backward slash are supported as delimiters to separate directory levels and to provide tools consistent for both PC and DOS users (that is, cd /sales/files and cd \sales\files changes to the same directory). From within FTP, I recommend using the absolute pathname rather than relative pathnames unless you are simply moving up or down the directory tree to avoid getting lost. Explicitly using the cd command helps keep you from getting lost in a large or complicated directory tree.
The close command ends an FTP session with the server without exiting the FTP program. This way, you can work with FTP files from two or more systems without having to fire up the FTP client program each time. See the section called "open" later in this chapter.
The dir command functions exactly like the dir command in DOS. It permits you to see the contents of the current working directory on the remote system, providing the opportunity to confirm that a file is where you would expect it to be prior to downloading it.
The get command initiates an FTP pull command, which attempts to get a file from the current working directory on the remote system (directory movement controlled by cd) and pull it over to the current working directory on the local system (directory movement controlled by lcd). The get and the put commands are the heart and soul of FTP. The get command does not allow getting more than one file at a time. To transfer multiple files, refer to the mget and mput commands described later in this chapter.
The hash command is convenient for transferring large files. Typing the command hash toggles on or off the printing of a hash mark (#) each time a full buffer of data is transferred. Thus, during a large file transfer, there is screen activity, reassuring the user that the system is not hung, but just in the midst of a large file transfer.
All commands discussed earlier in this chapter deal with movement within the directory tree related to the directories of the remote system. What about directory movement on the local system from within the FTP client program? Up until now, each time you entered the FTP program, you "got" and "put" in the local directory you were in when you fired up the FTP program. Just as the cd command moves through the remote directory tree, lcd (local change directory) moves you within the directory on the local system. Its syntax is exactly like the cd command. If you type lcd and press Enter, the lcd command will tell you what local directory you are in.
The ls command lists the contents of a directory on the FTP server, much like the ls command within UNIX. It is redundant with the dir command discussed earlier. FTP was defined to be a usable system for people with exposure to many different operating systems. To ensure that a wide body of users find FTP usable, some commands are PC-based and UNIX-based, both yielding the same result. Although most PC users are familiar with the dir command and therefore don't need to use the ls command, it's there just in case.
The mget (multiple get) command retrieves multiple files from a remote system with just one request. It interprets asterisks as wildcards and prompts you for a yes or no response for each file. It has no recursive features, meaning that although you can use mget to copy all the files in a given directory (mget *), you cannot use mget to get all the files in a given directory and all directories beneath it. You must use mget for each directory, one at a time. You also cannot deactivate the interactive nature of mget; you have to respond Y (yes) or N (no) for every file individually. A big advantage of a graphically based FTP client is that the interactive nature of both mget and mput (described next) is handled by the GUI, and multiple file transfers may be easier than in a text-based FTP session, contingent on how robust the GUI is.
Just as mget gets multiple files, mput puts multiple files on the remote FTP system. Again, asterisks serve as wildcards, and mput is subject to the same limitations as mget is with regards to recursive directory trees and suppression of the interactive nature of the command. See the preceding section for more details.
Using the open command, you can open an FTP session from within the FTP client program. If you just completed a transfer session with a host named spanky, for example, and wanted to transfer some files from a different server named alfalfa, you could use the close command to close the session with spanky without quitting the FTP client program and type open alfalfa to open up an FTP session on the server named alfalfa.
put is the sister command to get. Just as get requests a file from an FTP server and transfers it to the current working directory on the client system, put sends a file from the current working directory on the local system and puts it in the current working directory on the remote system. It is a "push" type of operation as opposed to get, which is a "pull" operation. In other words, the command takes the file indicated on the local system and pushes it over the network to the current working directory on the FTP server.
The pwd command behaves exactly
like the UNIX command pwd.
It's also like typing the MS-DOS command cd
with no arguments. It identifies the present (or current) working
directory on the remote system.
| Tip |
To minimize confusion as far as the local current working directory, whenever you use the lcd command, use absolute paths instead of relative paths. Doing so makes it easier to keep track of the local present working directory. |
The quit command quits the FTP client program and closes any open sessions. It behaves identically to the bye command and again is there to provide commands familiar to a larger audience of users.
The user command permits you to send new user data to the remote FTP server in the middle of an open session. Assume, for example, you are logged in as user Mary, and you want to get a file that only user John has access to. If you know John's password, you can type the command user John, which prompts you for John's password. After you enter the correct password, you are logged in as user John and now can access the file.
Now that you are more familiar with some of the key FTP commands, Listing 27.1 shows a more detailed sample FTP session that highlights many of the commands just discussed.
Listing 27.1. A complex FTP session.
ringo% cd tmp4 ringo% ftp paul Connected to paul. 220 paul FTP server (SunOS 4.1) ready. Name (paul:victor): victor 331 Password required for victor. Password:****** 530 Login incorrect. Login failed. ftp> user sales 331 Password required for sales. Password:****** 230 User sales logged in. ftp> cd /sales/programs 250 CWD command successful. ftp> binary 200 Type set to I. ftp> hash Hash mark printing on (8192 bytes/hash mark). ftp> get forecast.exe 200 PORT command successful. 150 Binary data connection for forecast.exe (196.32.43.5,1398) (433599 bytes). ##################################################### 226 Binary Transfer complete. local: forecast.exe remote: forecast.exe 433599 bytes received in 2.5 seconds (1.7e+02 Kbytes/s) ftp> close 221 Goodbye. ftp> open george Connected to george. 220 george FTP server (SunOS 4.1) ready. Name (george:victor):[return] 331 Password required for victor. Password:***** 230 User victor logged in. ftp> cd /sales/files 250 CWD command successful. ftp> lcd / myfiles Local directory now /myfiles ftp> ascii 200 Type set to A. ftp> mget * mget data1? y 200 PORT command successful. 150 ASCII data connection for data1 (196.32.43.6,1401) (216799bytes). # 226 ASCII Transfer complete. local: data1 remote: data1 216799 bytes received in 2.5 seconds (85 Kbytes/s) mget data2? y 200 PORT command successful. 150 ASCII data connection for data2 (196.32.43.6,1402) (216799 bytes). # 226 ASCII Transfer complete. local: data2 remote: data2 216799 bytes received in 2.5 seconds (85 Kbytes/s) mget data3? n mget data4? y 200 PORT command successful. 150 ASCII data connection for data4 (196.32.43.6,1403) (216799 bytes). # 226 ASCII Transfer complete. local: data4 remote: data4 216799 bytes received in 2.5 seconds (85 Kbytes/s) mget data5? y 200 PORT command successful. 150 ASCII data connection for data5 (196.32.43.6,1404) (216799 bytes). # 226 ASCII Transfer complete. local: data5 remote: data5 216799 bytes received in 2.5 seconds (85 Kbytes/s) ftp> close 221 Goodbye. ftp> bye ringo%
In this example, the user is Victor. Victor wants to download a sales forecasting program from the marketing department's FTP server, which is named Paul. He then wants to download some forecasting data files from the sales department's FTP server, which is named George. Victor starts by trying to open an FTP session to the marketing FTP server from his local machine, which is named Ringo. Victor does not have a valid login on system Paul, so his attempt fails. Although Victor remains within the FTP program, he is not connected to a server. Victor then remembers that there is a shared account on that system named sales for all the salesmen, like Victor, to access. Using the user command to resend data to Paul, he authenticates successfully. Victor then uses the cd command to change directories to where the forecasting program, named forecast.exe, is located.
Because this is a binary executable program, Victor sets the mode to binary and then toggles hash marks on so that he can see the transfer of the file progress. Next, he uses the get command to download the file and notes that the hash marks move across the screen as the file is transferred. Having downloaded the file from Paul, Victor uses the close command to disconnect from server Paul but remains in the FTP program.
He now uses the open command to open George, the sales department's server. Victor uses the lcd command to move to a different location on his local system before starting the download. He also use cd to change to the correct directory to get his raw data files and then uses the mget command to get all the files in this directory interactively. He then chooses on a file-by-file basis which ones to download. He enters close to close his connection with server George and exits the FTP program through the bye command.
With this information, you should feel comfortable using FTP to get and put files from and on systems to your LAN.
FTP is useful to an intranet because it provides a general protocol to permit movement of files between systems that have completely different architectures or operating systems.
As a component of the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols, any computer that supports TCP/IP has an implementation of FTP (or at least the client program, as some TCP/IP packages do not contain an FTP server program) and thus can communicate with any other computer running a TCP/IP stack. FTP is the easiest way to move files between UNIX, Macintosh, and PC systems, provided they all have a TCP/IP stack and at least one of them is configured as an FTP server. The systems that hold files for FTP need not understand or be able to run a file to make it viable for sharing or downloading via FTP, as long as it was placed on the said system by binary FTP transfer and not ASCII. One system with a large hard drive can serve as a repository for data. Programs that operate on a variety of platforms can be made available to a variety of different system types from a single FTP server. In Figure 27.3, a large UNIX system is storing files that run on HP-UX, SunOS, Windows 3.1, and Macintosh. Even though the system itself cannot run the SunOS, Windows, or MacOS programs, it still serves as a central repository for all these programs while making them available for downloading.
Figure 27.3: A UNIX server sharing files that run on a wide variety of platforms via FTP.
FTP is the primary mode of transferring data over the Internet. Each time a file is downloaded over the Internet, FTP works "behind the scenes" performing the file transfer, which poses some interesting questions. Until now, you have seen examples of FTP where a user logs in to a system to use FTP by supplying a valid login name and a valid password. But how does a user download a file from an arbitrary Web page? How does a file get downloaded from Microsoft's home page to your system? Do you supply a password through your Web browser?
Because it is not possible for a systems administrator to maintain accounts for every person who may visit a public FTP server on the Internet, FTP functionality is provided for arbitrary users via anonymous FTP.
Review the FTP commands at the beginning of this chapter again. Here are the most basic and fundamental commands used to transfer data via FTP. There are many more commands that were not discussed in detail, such as delete, mkdir, and rename. Remember, FTP is a powerful tool. From within it, the seasoned user can delete, rename, and move files fairly effortlessly. If a systems administrator is going to share files with the general public, he or she does not want to give the Internet community this level of power via FTP. For this reason, it is a bad idea to create a general account with a generic name and password (like "guest") for the general public to use for FTP transfer. Anonymous FTP is a special FTP account with access to a limited number of commands and access to a limited area on your FTP server. Anonymous FTP makes only a small portion of the FTP server's file system visible. It is impossible to use cd to change to the top level of the FTP server (for example, cd /) from within anonymous FTP.
When it is configured correctly, anyone can FTP to your system by supplying anonymous as their login name. Although the user still is asked to supply a password, any password (or none) is accepted, and the user is granted access. Internet etiquette mandates that users should typically supply their e-mail addresses as passwords. By doing so, the systems administrator at the remote system knows who has been visiting his or her system. After logging in, the anonymous FTPer does not have complete access to the entire directory tree on the FTP server. Instead, the user has limited access to a public area where files can be accessed and, if configured as such, a place where files can be placed via FTP.
To illustrate how anonymous FTP operates and is administered, I will provide an example of how to configure a UNIX-based anonymous FTP server. If you're not familiar with UNIX, you may want to skip this section. PC and Macintosh systems are not configured from the command line; configuration usually is reduced to filling in dialog boxes, specifying information such as the anonymous user's home directory.
First, create a user logon named ftp that is a member of the group anonymous. Add a line to the /etc/group file specifying a new group with the name anonymous. Make sure that you assign it a unique Group ID (GID), one that is not used by any other accounts on the system. Next, add a user named ftp to the /etc/passwd file. It should have a unique User ID (UID) and should be a member of the group anonymous just created. The password entry for this account should consist of only a single asterisk (*), thus disabling the login. As a security precaution, you can set the login shell to /bin/false to make this account even harder to enter or break into. As an example, if you were going to reserve UID 50 and GID 60 for anonymous FTP, your group and password files would include the following lines:
/etc/group: anonymous:*:60 /etc/passwd: ftp:*:60:50::/home/ftp:/bin/false
Notice that I gave the account ftp a home directory of /home/ftp. Choose this home directory carefully! Only this home directory and the contents directly below it should be visible to those users who use the FTP site with the login of anonymous. When a user logs onto your system via anonymous FTP, a low-level system function named chroot is called. This command changes the root directory to whatever is referenced in the /etc/passwd file. In other words, the chroot call forces any reference to the top level of the directory tree ("/") to expand out to the home directory of the FTP account (/home/ftp, in this case), thereby sealing off all directories above this home directory, as shown in Figure 27.4.
Figure 27.4: How the chroot call changes the user's access and perpective of the file system.
After all directories above the FTP home directory are locked out, commands like ls are completely inaccessible. The ls command is used by the FTP client program to give directory listings with the dir and ls commands from within FTP, so somehow the system must access it. To do so, put a copy of this command and a few other files below the home directory of the FTP account. Make sure to place only a minimal number of commands and files at this level, reducing the number of potential tools available to break into the system. At a minimum, the program /bin/ls must be copied down to a subdirectory beneath the FTP home directory named bin (for example, ~ftp/bin). It must be set so that no one can read or write to it; in other words, it should only be executable, but executable by all groups. You can do this by setting the permissions on this file with the chmod command to 111.
If you want the ls command to provide information about what users own what files, copies of the /etc/passwd and /etc/group files must be accessible so that the system can match the UIDs and GIDs of a file with a certain user and group. The copy of the password file should have the encrypted password field replaced with an asterisk, and if your site is very security conscious, you can eliminate all entries from the ~ftp/etc/passwd file except for those corresponding to root, daemon, uucp, and ftp. By eliminating the other entries, nosy browsers cannot get to see a list of all the local users in the local version of the passwd file. Using the chmod command, change the mode of these two files to 444.
If you want to permit users to put files on your anonymous FTP site, you should also create a public directory (a standard name for this directory is ~ftp/pub) directly below the ftp home directory and make it writable by changing the mode of the directory to 755 by using the chmod command.
If you are unfamiliar with the chmod
command, it lets you control who can read, write (or remove!),
and execute a program. The first number describes the privileges
the owner of the file has. The second number describes the privileges
of the members of the group the file belongs to. The third number
indicates which privileges all other users have. Table 27.2 shows
what numbers correspond to what permissions.
| Permissions Granted | |
| Executable | |
| Writable | |
| Readable | |
| Readable and executable | |
| Readable, writable, and executable |
Before you can call your anonymous FTP site complete, give it a rigorous test to make sure that it operates as you expect. Try to get and put files both from places it should work and places it should fail. Try to break out of the FTP login, and make sure that the system is bulletproof before calling your job done.
You will now look at some of the differences between FTP clients on different hardware and software platforms. After I briefly describe what you may expect to see in different types of FTP clients, I will address some of the important criteria used in selecting an FTP client to suit your needs.
Typically, FTP from UNIX systems is handled at the command line. (Linux, an operating system freely available on the Internet, is functionally a derivative of UNIX. What works for UNIX works for Linux.) Although some decent GUIs may be available for UNIX, they rarely are used. UNIX has always been a command-line-based language, and the use of FTP within UNIX is similar from platform to platform. FTP comes built into UNIX's TCP/IP implementation and is free with UNIX.
To use FTP under MS-DOS and Windows 3.x, you need to purchase a TCP/IP package from a third party. Some of the more popular packages have been developed by FTP Systems (PC TCP), Spry, Inc. (AirConnect), and Wollengong Systems (Pathways).
Figure 27.5 shows what you see when you run the FTP Client GUI that is provided with the CuteFTP shareware package released by Alex Kunadze.
Figure 27.5: CuteFTP running the FTP Client GUI.
In Figure 27.5, notice that you have an icon-based image of the directory that you were in when you entered FTP. It is your local current working directory. You can reach most of your FTP commands through pull-down menus. To open a session with a system, choose FTP | Connection | Open. A dialog box appears, as shown in Figure 27.6, asking you what system to connect to, what username to log in as, and what password to supply.
Figure 27.6: Connecting to a remote system.
Upon correctly authenticating, you see a second icon-based directory tree, as shown in Figure 27.7. It is the current working directory on the remote system.
Figure 27.7: Seeing the directory tree on both the local and remote systems.
As far as getting and putting files, you do so in a drag-and-drop manner. Move through the different directory trees by clicking the icons, and when you want to transfer the file, hold down the mouse button as you select the file, and drag it to the directory to which you want to transfer it. You can find features such as binary and ASCII transfer, for example, under the Options menu.
Some client programs may have slightly different ways of transferring files, like buttons labeled get or put or two fixed subwindows, one for the local system and one for the remote system, with arrow buttons that transfer files in a given direction.
Windows NT and Windows 95 have a built-in TCP/IP stack, which has built-in FTP functionality much like UNIX. The implementation of FTP built into NT has no GUI; it has a command-line interface only. You can install third-party GUI-based FTP clients over NT's native TCP/IP stack, and this is done fairly often. This way, a GUI-based version of the FTP client is available. The example of the CuteFTP client shown in Figure 27.8 (shown later) is a good representation of the style of FTP graphically based clients you see in the NT world, along with the Windows 95 and Macintosh world.
Figure 27.8: Configuration of a Windows NT-based FTP server.
MacOS is much like Windows 3.1 in that you must purchase a third-party TCP/IP package that includes an implementation of FTP. Just like with MS-DOS and Windows, many firms like Wollengong Systems (MacPathways) and Intercom (TCP Connect II) provide TCP/IP packages. Like Windows 3.x and Windows NT, the Macintosh FTP clients are most often GUI-based, so the descriptions under MS-DOS/Windows 3.x apply.
As far as choosing the right FTP client, ergonomics is really the only important feature of the client package. How usable is it? Are the features that you need to modify a lot (for example, ascii or binary mode) easily accessible? How easy will it be to train your users on this package given its look and feel?
A greater issue exists, however. Most FTP clients come bundled as part of a TCP/IP implementation. You must evaluate the entire TCP/IP package as a whole. To purchase a top-end FTP program that runs over a poor TCP/IP stack would be a big mistake. Look at the other features of the package, and evaluate it as a whole.
Choosing the right FTP server for your needs is more important than choosing the FTP client software, because the FTP server actually deals with security. The FTP server handles security issues such as who can log into the server, who can download files from the server, and whether to enable anonymous FTP. Remember, any system that you want your users to connect to via FTP must have FTP server software running. In this section you will learn what differences to expect from FTP servers of different platforms and how they deal with security issues and anonymous FTP.
UNIX and Linux's TCP/IP stack includes a built-in FTP server. It has an FTP daemon that is typically configured as part of the system's startup procedure. Its implementation of anonymous FTP is robust and well documented by many books; you also can access online manual pages by typing man ftp or man ftpd.
UNIX is probably the operating system best suited for acting as an FTP server because UNIX-based FTP is directly tied in with UNIX user accounts and passwords, so account management and password authentication are handled by UNIX. Furthermore, within UNIX, each file has a specific owner who can set the privileges on who can or cannot read a certain file. This feature adds another level of security to FTP from within UNIX. Not only is access to the file system controlled by logging in, access to certain files can be restricted by setting the read and write privileges of the files accordingly.
Of course, one of the biggest pluses of a UNIX-based FTP server is that UNIX implementations of TCP/IP and FTP have a two-decade history in the implementation of mission-critical systems. Twenty years is a track record unmatched by any other operating system.
Just as MS-DOS and Windows have no built-in TCP/IP stack, they do not have a built-in FTP server either. When you're comparing FTP servers, pay close attention to how they handle validation of logins, anonymous FTP, and isolation of public areas of the file system. Because MS-DOS has no built-in user control, the only security in DOS-based FTP servers is what is built into the TCP/IP package.
I don't recommend using an MS-DOS system as an FTP server if the option on any UNIX system, such as a PC running Linux, is available because of these security issues. Although Windows 95 does have a built-in TCP/IP stack, it does not have a built-in FTP server service; thus, it behaves like a Windows NY FTP client and a Windows 3.1 FTP server.
Macintosh FTP servers are fairly few and far between but behave similarly to NT FTP servers. They are GUI based and typically enforce read and write privileges that exist on files and folders. These permissions are set through AppleTalk. Some access control from within the FTP extension is typically available if the Macintosh is running AppleTalk.
Although Windows NT has an FTP server built into its TCP/IP stack, and it provides most of the same functions as the UNIX FTP server, it is configured through a GUI rather than a command line. Windows NT is different from the UNIX implementation of FTP in a number of ways. Windows NT establishes only one directory, which is the default current working directory, upon connection for any user. Within UNIX, when a user connects to a server via FTP, the initial current working directory is set to the home entry in the user's entry in the /etc/passwd file.
Figure 27.8 shows the configuration screen for the FTP server
on Windows NT. As you can see, through this dialog box you can
control attributes like the maximum number of connections and
the idle time-out time. Limiting the number of users connected
to an FTP server can be very convenient so that the sheer volume
of people attempting to perform file transfers does not generate
unwieldy transfer times. As you also can see within the dialog
box, the option to make the anonymous FTP login something other
than anonymous is available
also, but because the login of anonymous
is an informal Internet standard, you probably should not change
it if you anticipate strangers connecting to your FTP server.
These features are not readily available within the UNIX implementation
of an FTP server.
| Note |
Although FTP is a part of TCP/IP, the FTP server service for Windows NT is not automatically installed when you install the TCP/IP suite from the NT CDs. It is a separate package that you need to install; you can find it on the NT Server CDs. |
On the flip side, the security of the NT FTP server is less robust. You can control read or write access on the partition level but not on the file-by-file level from within the FTP Server Security dialog box, as you can see in Figure 27.9. From within Windows NT, the user can set privileges of directories and files, but the procedure is not as straightforward as the chown or chmod commands within UNIX are. NT does have logging capabilities to track who is accessing the FTP server, both as "non-anonymous" standard users and as anonymous users.
Figure 27.9: Configuring security on a Windows NT FTP server.
Several third-party FTP servers are available for Windows NT, for a variety of costs and with a variety of features. Most of these are new and might have unique features that you won't see in the standard FTP server prevalent in UNIX. Based on the sensitivity of the data on your LAN and the amount you want to spend on an FTP server, an NT FTP server might be an efficient and leading-edge solution to your file-sharing needs. UNIX FTP is very stable but not very exciting or visually straightforward.
Now that the fundamentals of FTP have been addressed, the next question is, Why FTP? What should it be used for? Can you use some strategy to determine what should be shared and how? The answers to these questions depend on who your user community is and whether or not these users work within your firm. In the following sections, I answer these questions first from the standpoint of the Internet and then from the standpoint of your own intranet.
When you address sharing files over the Internet, you are talking about making files public to the entire Internet community-that is, what to make available via anonymous FTP.
Making files available for public access is one thing, but letting potential users or viewers know that the anonymous FTP site is there and available is another. To alert potential users and viewers, I suggest a pre-computer notion: Advertise! Of course, you can advertise in many ways, both electronically and nonelectronically. A rather simple method is to set the logon banner of your system to display an advertisement making users aware of your FTP. If your organization has a Web page on the Internet, you can place information on accessing your FTP site on the Web page. If nothing else, place your organization's Internet address on the FTP site or any printed media targeted at general users.
Before selecting data to place, be aware that anyone can connect to this system. So, make sure that the only data or executable that is shared is ready for public consumption and is error free.
Any customer support documentation is a valued addition to an FTP site. Posting this type of "raw" data here provides an easy way for your customers to get immediate support, regardless of the time of day or the burdens of the support staff. Troubleshooting documents, how-to documents, and Frequently Asked Questions (FAQs) documents are popular with anonymous FTP sites. Also, if you're running a business, consider placing price lists, product information, nonconfidential sales and marketing data, and even biographies of prominent staff members. This way, you get free publicity and advertising. Anything your business or organization wants to publicize should be on the FTP site.
Now consider binary executables or other forms of data that are not "raw." If you have any public domain or internally developed programs you want to share with the public, you can place them on an anonymous FTP site. You also can put demos or evaluation software on an FTP site, as Netscape did with its 2.0 beta software, and you can place free upgrades or utilities on the anonymous FTP site also. Once again, remember that what you place on this site is available for all the Internet to access, so make sure that nothing confidential appears in this data. If you have an internal FTP site with sensitive data, make sure that the two FTP sites are isolated from one another.
You should remember a few basic yet critical issues regarding anonymous FTP.
First, provide an index or table of contents. Make sure that one file named readme.txt, or TOC, carries an up-to-date index of what files are available via FTP and what they contain.
Second, unless you have a good reason, do not enable write privileges on your anonymous FTP site. Allowing write privileges is a sure way to have your system infected with a virus or Internet worm.
Also, ensure that the data you post is current. An outdated FTP site is a useless site and will not be visited frequently.
Finally, take a look at what files you can group (via Tar or PKZip) into one file and compress. Compressing files has two advantages. It reduces the space and bandwidth the file requires during downloading and on the FTP server. Additionally, grouped and compressed files allow a user retrieving a file to use the get command instead of the interactive and more cumbersome mget command.
Within an intranet, there is less concern about security because the site is not connected to the systems outside your local area network. Nevertheless, vigilance and awareness are mandatory when it comes to evaluating what data can be shared anonymously. You can post general internal toolkits or applications for users who want to download specific applications via FTP instead of installing new applications on individual systems. This approach is an efficient way to keep applications in an accessible location. Internal documentation, such as work standards, company policies, staff directories, and project notebooks can be made available. Be creative with the data you post.
As an example, at one large financial services firm, the Novell NetWare administrators loaded the all-important NetWare license and key executable file (SERVER.EXE) for each Novell server onto a UNIX-based FTP server, so any existing Novell server can be quickly regenerated in an emergency, even if the original installation media has disappeared.
Be aware of what format your data is in. If your user community is a group using UNIX, don't put Microsoft Word documents on your site. Make sure that any nonstandard data put on an FTP site is readable by the user community; if necessary, put the application needed to view the data on the FTP site also. Make sure that the file formats are well documented in your site's table of contents.
Also, the information you post is valuable only if it's accessible, so post with the least common denominator in mind. If your desktop system is a high-performance NT workstation, don't put 32-bit applications on a site to be shared by Windows 3.1 machines.
You should keep in mind a few issues regarding security and FTP. When you're thinking of setting up FTP, make certain that you understand all the issues behind system security before you enable it. As you've heard before, discretion is the better part of valor.
Look closely at the file system structure of your FTP server. Do you have the area reserved for anonymous FTP isolated correctly? Is it empty of any unnecessary files? Are you sure there are no symbolic links (which can be problematic for anonymous FTP because the chroot call may put the other side of the link in an area inaccessible to the FTPer) or NFS (Network File System) mounts below the home directory of the anonymous FTP account?
Is your system sufficiently isolated? If you have an FTP site connected to the Internet, is it sufficiently firewalled from the rest of your intranet? In general, try to minimize the number of points of intersection between your intranet and the Internet, as this will reduce the number of entry points a potential hacker can use to gain entry.
Controlling access to the FTP server has two sides: the physical and the digital. Physically, or geographically speaking, store the system in a secure place. Make sure that general members of your staff do not have access to the FTP server, reducing the chances that they might modify any system files or grant themselves a higher level of authority on the system. On the software side, do not put unnecessary accounts on the system. If only a handful of users are authorized to use FTP in your firm, do not put an account on there for every network user. You therefore should avoid distributing your account data to the FTP server by NIS, if you use NIS at your firm. NIS and NIS+ are services that permit many systems to share the same files-typically system files such as the password file-thus allowing the creation of a "master" password file that all systems can share. Watch log files carefully, and frequently audit who is connecting to your FTP server-from both the inside and the outside.
Also keep close tabs on who has access to what information. Check the permissions of all the systems files, and make sure that each user starts with read and write access only in the local and public area. If you permit your users to relax the access rights on their personal areas, make sure that they are aware of the risks and make sure that they cannot modify the privileges of the public area.
Whenever possible, configure your FTP server to time out after a period of inactivity. This reduces the risk of a user walking away from a system in the middle of an FTP session and leaving the system unattended and waiting to be compromised.
I must reiterate that you must exercise caution with anonymous FTP. Remember that with anonymous FTP, you cannot control who accesses files. Any auditing of users accessing your anonymous FTP server is based entirely on their honor when it comes to supplying their e-mail addresses as their passwords. Test your anonymous FTP site thoroughly before opening it up to the public. Try to delete files from within it, and try to move above the home directory of the anonymous FTP account to make sure that the anonymous FTPer does not have more privileges than you allow.
FTP is an integral part of TCP/IP and almost all local area networks. Due to the nature of FTP, it requires user authentication-logging in with account names and passwords. This authentication directly affects the systems administrator in two ways. It is an extra application that needs to be maintained and kept aligned with the current user community, and it is an additional security issue.
In this chapter, you learned about the mechanics of how FTP works and the risks of providing FTP functionality. In all probability, at a bare minimum, you will want to permit bidirectional FTP within your LAN ("getting" and "putting" FTP out of your LAN so that your staff can get files from the Internet). You may not want to allow the external community into your LAN via FTP. Either way, you should address this issue early so that, as your file transfer needs expand, you know what tools you want to implement and on what type of platform.