There are many reasons for setting up an FTP server—ranging from sheer necessity to noble intentions. Whatever your reasons, you should plan carefully and consider the notes in this chapter.
The first thing to consider is how you plan to use the server. Who are the intended users? Will they best be served by a public or a private server?
The next major consideration is the software you plan to use. Does your vendor-supplied server meet your needs? Check the system manuals to determine whether you want to use that server or one of the other servers available on the Net. Three solid UNIX packages are available from the following sites:
ftp://uarchive.wustl.edu:/packages/wuarchive-ftpd
ftp://ftp.uu.net:/systems/unix/bsd-sources/libexec/ftpd
ftp://gatekeeper.dec.com:/pub/DEC/gwtools/ftpd.tar.gz
Next, sketch out an overview of how your server will be set up. This not only helps your own efforts, it makes the server easier for others to use. For example, you may want to diagram the layout in some detail. That is, create a tree structure on paper and draw in the branches you'll supply. Consider the following example:
——————PUB————————
| | |
| | |
GRAFIX MACINTOSH VIRUS
/ \ / \ / \
GIF TIFF SND GAMES PC OTHER
Add all the directories you think you might use, even if there is nothing in them yet; that way, people know what you are going to put there and will come back to look again. Adding all the directories may be a good idea, but stay reasonable. If the directories don't contain files after a few months, you should remove them.
The next step involves making decisions about access. Some sites provide an incoming directory that enables files to be put on the server anonymously. If you plan to use such a directory, remember that you have very little control over what is put there. Some sites become depositories for pirated software; others are flooded with GIFs.
The best way to deal with such security issues is to make your incoming directory execute-only; make sure that the directory has write and execute subdirectories (see the CERT "Security Notes" posted to the comp.security newsgroups or on ftp://ftp.cert.org/ for specifics). Of course, this practice may require more administration time than is available. As many FTP administrators can attest, the down side to having an incoming directory is that someone has to continuously check the directory.
Ultimately, you have to decide how much time you have to devote. An alternative to having an incoming directory is to use mail aliases (although this requires the extra work of encoding and decoding binaries). A separate alias can be set up for each topic (for example, UNIX, Windows, and network); if that does not provide sufficient granularity, you can use Procmail to filter the mail based on a subject line (use Archie to locate Procmail).
In addition to dealing with incoming files, you should set up an alias of ftp@your_ftp_server to deal with incoming mail. Using this alias is one way to keep mail related to your FTP site separate from other system mail. If this e-mail address is presented prominently—for example, in a top-level README file—people can inform you of problems with the server.
Another conventional alias is to set up an alternative name for your host in the form ftp.site.domain (for example, ftp.widgets.com). To set up such an alias (actually a cname record in a nameserver database), add the name to the nameserver that serves your site.
The procedure for installing software varies depending on the package, but the following steps provide an overview. As always, first consult the documentation distributed with your package.
You can do several things to make your server a more hospitable place. Foremost among the things you should consider is a recursive listing of the entire contents of your server. Depending on how many files reside on your server, this listing can take up considerable space. However, you can compress the listing to conserve space.
The listing should be called Ls-lR or FILELIST and should be placed in the top-level directory. On an active server, it should be updated weekly or biweekly; on less active servers, a monthly update may suffice. However, the listing should be updated at regular intervals so that users know when to check it (the frequency of the updates can be specified for users in a README file). If the updates are irregular, users are likely to perform their own recursive listings. Depending on the size of your server, these recursive listings can be a significant drain on resources (defeating one of the main purposes of making the file list available).
Another file you should place in the top-level directory is the README file. You can use the file to hold various information, such as the purpose of the site, the name and home phone number of the person maintaining the site, and an e-mail address to which users can send bug reports or comments. This file also can be used to point out other methods to retrieve information (Gopher, Web, mailserver, and so on), and whether your site "mirrors" other sites or archives. It also should contain information about any anomalies on your system—for example, if you have hacked the server.
Within each subdirectory, you can add another README or INDEX file to describe the contents of that directory. These files can become dated quickly, so it is a good idea to keep their descriptions fairly generic. For example, if you have a directory called amoeba that contains the current release of the mind-numbing Amoeba's Revenge game, you can point to AMOEBA.TAR.Z as the latest version (rather than listing the version number in the INDEX file). The AMEOBA.TAR.Z file could be a link to the latest version AMOEBA.5.3.TAR.Z, saving you the trouble of updating all the INDEX files—and saving users the guesswork of finding the most recent version.
TIP Regarding version numbers, it is a good idea to keep at least the previous release of a given program in case there are bugs with the current one. Keep your naming convention consistent—especially when the old and new versions are in the same directory. Often, the best way to do this is to include the version number in the name of the file or directory.
Finally, if you intend for your site to be public, make sure that people can find it: register the site with the Archie folks. (See Chapter 24, "Archie: An Archive of Archives," for details.)
Disks have a nasty habit of filling up, and FTP directories seem to have a hyperactive appetite for disk space. Unfortunately, cleaning up is not as simple as moving some files to tape. On an FTP server, the files must be on the disk or they are not accessible.
The solution is to use compression, which can save between 40 and 60 percent of your disk space. Compression also saves network bandwidth because fewer bytes are transferred. Of course, not all files benefit from compression—and there is the added inconvenience of compressing and decompressing the files—but if conventions are followed, compression is certainly worthwhile.
One thing to remember is that the type of compression used should be consistent, as well as appropriate, for the files being compressed. For example, UNIX files are traditionally compressed using the compress command (which appends a Z to the filename) but the GNU gzip program is now also popular. DOS files are usually compressed with the ZIP format; these files can be unzipped with PKUNZIP.
Although there are no definitive compression rules to follow, here are a few guidelines:
FTP has been around for a long time (by computer standards); most of its security issues have been thoroughly scrutinized. However, security is an ongoing concern because it is affected by OS upgrades, program changes, and file system modifications. Short of constructing a firewall, your best line of defense is vigilance.
Most FTP servers have a method of logging sessions—typically by specifying the -l option when ftpd is invoked. This option logs each session to syslog. The wuarchive ftpd has several options for logging, including user commands and file transfers (see the man page for details). Users of the FTP server who would abuse its services may be hesitant to do so if they know their activities are being logged. It is usually a good idea to put a message on the sign-on screen of your FTP server that you log all commands. The exact procedure for doing this depends on your FTP server, so check the documentation that came with it to see how to add such a message.
Of course, all the logging in the world won't help if the attackers gain root access (because they can then modify the logs). Therefore, your first line of defense must be careful scrutiny of your file permissions. Follow the file permission examples (provided earlier in this chapter) and make sure that they stay that way by running a script periodically. An example script can be found at the following address:
nic.sura.net:/pub/security/programs/unix/secure_ftp_script
In addition to ensuring that the file and directory permissions are secure, you should make sure that none of the entries from /etc/passwd appear in ~ftp/etc/passwd. Both the ~ftp/etc/passwd and ~ftp/etc/group files are used only to show ownership and group ownership for the dir or ls -l command. Neither are used for access privileges. Therefore, only the entries that must be there should be included.
Sites should make sure that the ~ftp/etc/passwd file contains no account names that are the same as those in the system's /etc/passwd file. These files should include only those entries relevant to the FTP hierarchy or necessary to show owner and group names. In addition, ensure that the password field, which follows the first colon, has been blocked. The following example of a passwd file from the anonymous FTP area on cert.org shows the use of asterisks (*) to block the password field:
ssphwg:*:3144:20:Site Specific Policy Handbook Working Group::
cops:*:3271:20:COPS Distribution::
cert:*:9920:20:CERT::
tools:*:9921:20:CERT Tools::
ftp:*:9922:90:Anonymous FTP::
nist:*:9923:90:NIST Files::
Another facet of FTP security is the ftpusers file. If this file exists, the daemon checks the names listed against the user logging in. If the name matches an entry, access is denied. If this file is not found (usually ~ftp/etc/ftpusers), any user meeting the other criteria is allowed access. You want to block access for certain user IDs for a few reasons. The first is when a user ID has special access to the system; someone using FTP into that user ID could cause great damage. The other reason is when no one will ever FTP into the account; why leave it open? The following users should be in ftpusers as a bare minimum:
root
bin
boot
daemon
digital
field
gateway
guest
nobody
operator
ris
sccs
sys
uucp
The wuarchive ftp server has the added feature of being able to permit access based on matching entries in a file (~ftp/etc/ftphosts).
FINAL RECOMMENDATION