Chapter 17. File Transfer, File Sharing, and Printing

17.1.4.1. Limiting access to information

Most Unix FTP servers perform a chroot to the anonymous FTP area before the FTP server starts processing commands from an anonymous user. Although Windows NT doesn't have a chroot mechanism, Windows NT FTP servers also provide a "virtual root", which is supposed to limit access given to anonymous users. To support both anonymous and user FTP, however, FTP servers need access to all files. This means that chroot, which is normally regarded as extremely safe, doesn't guarantee as much for an FTP server because the server is not always running in the chrooted environment. On Windows NT, the restrictions are provided entirely by the FTP server (rather than the operating system), which is an even weaker guarantee (and indeed, a number of Windows NT FTP servers have had problems with people using pathnames that include ".." to escape the restricted area).

To deal with this problem under Unix, you can modify inetd 's configuration so that instead of starting the FTP server directly, it chroots (using something like the chrootuid program described in Appendix B, "Tools") and then starts the FTP server. Normally, FTP runs with limited access only for anonymous users, and nonanonymous users have their normal access permissions. Doing the chroot before starting up the FTP server means that the nonanonymous users will also be limited; if you don't have any nonanonymous users of your FTP server (and you probably shouldn't), this is irrelevant.

Under Windows NT, you cannot get the operating system to enforce this sort of restriction. You should be sure that all filesystems on your FTP server are NTFS and use NTFS filesystem permissions to ensure that the account that is used for anonymous access does not have access to files that it should not be able to read. On the Microsoft FTP server that's part of the Internet Information Service and comes with Windows NT Server; that account is named IUSR_computername, and it is normally made part of the Guests group, which by default has almost universal read permissions. You should explicitly give Guests "No Access" to everything outside the anonymous FTP directories.

The details of setting up an anonymous FTP system vary depending on the operating system and the particular FTP daemon code in use. Start with the instructions (if any) in the manual pages for your FTP daemon; this should get you through most of the vendor-specific steps. Then, once you've performed all the steps there, if you are running Unix, obtain and follow CERT-CC Advisory 93:10 (for information on obtaining CERT-CC advisories, see Appendix A, "Resources"), which addresses setting up anonymous FTP servers to close the holes left by most of the vendor instructions.[70] (There doesn't seem to be an equivalent source of information for Windows NT FTP servers.)

[70]Many vendors ship instructions containing critical problems, ranging from security holes to missing steps that disable parts of FTP's functionality.

It's best to avoid putting files up for anonymous FTP if you don't want the entire world to read them. Use other methods of file transfer if possible. If not, you may want to use a modified FTP server, like the wuarchive server, which allows semianonymous access that requires an anonymous user to provide an additional password to get access to certain directories. (No such server appears to exist for Windows NT.) You can also put up files in directories that allow people to read the files without being able to do a directory listing; under Unix, you give execute permission but not read permission on the directory, while under Windows NT, you give read permission but not list permission. Doing so will let people who know the names transfer the files, but won't let people look to see what files exist.

Whatever method you choose, be sure that everybody at your site who can put files in the anonymous FTP directories knows not to put confidential files where they're world-readable. An easy way to do this is to prevent your internal users from writing to the anonymous FTP directories and to require them to ask a system administrator to make a file available.

17.1.4.2. Preventing people from using your server to distribute their data

Writable areas can be very useful, but they have a dark side. Such writable directories will (notice that we didn't say may) be found and used by "the underground" on the Internet as storage space and distribution areas for illicit material; this generally means pirated software packages or music and pornographic image files.

The folks who do this can be amazingly well organized and hard to track down. They have their own communication mechanisms for telling each other about new sites -- places they've found to store their stuff -- without revealing who they are. When they find a new site, they typically create a hidden subdirectory in which to store their files and images. They give the subdirectory an innocuous name such as ".. " (that's "dot dot space space"). When casually looking around an anonymous FTP area, you probably won't notice a name like this. It's particularly easy to miss on Unix systems because file and directory names beginning with "." are ignored by the Unix ls command, unless you give the command a special argument or run it as root.

On some sites in which intruders play this game, you can see a barter economy in operation. Someone leaves a note saying they're seeking a certain package or file and listing what they have to offer in exchange. A short time later, someone else comes along, uploads the requested files, and leaves another note telling the original poster what they want in return.

What's wrong with this misuse of your anonymous FTP areas? There are several problems:

• It consumes your resources, such as disk space and network bandwidth (particularly on your Internet connection), and it interferes with the legitimate use of those resources: it's a denial of service attack.

• It potentially exposes your site to legal action for assisting (even unwittingly) in copyright violations, software piracy, or perhaps sexual harassment, or even sexual exploitation of minors. Even if such actions are unlikely to succeed, your attorneys will probably tell you that they'd rather avoid the issue and not have to fight the battle in the first place.

• Even if no legal actions are undertaken, such an incident could generate significant negative publicity and embarrassment for your site or organization. Once your name has been linked to software piracy or child pornography in any way, you are in bad trouble regardless of how innocent your involvement was.

17.1.4.3. Preventing people from using your server to attack other machines

icrosoft's FTP server by default requires the IP address to be the same as the source address on the data channel and allows the client to specify only the standard FTP data port, or a port number above 1023. Few Unix servers provide this kind of functionality. If you run a server that does not implement limits, you should be sure that packet filters prevent the machine from acting as a useful port scanner. It should not be able to create arbitrary connections to other machines.

In some cases, intelligent packet filters are also vulnerable to this kind of attack. If an attacker connects to an FTP server and issues the Port command, the packet filter will usually open a hole for the requested connection. This hole will exist regardless of whether or not the FTP server actually obeys the command.

17.1.4.4. Using the wuarchive FTP daemon

• Better and more complete logging. It can log uploads, downloads, or every command sent to it; it can also keep track of the number of accesses by user classes (e.g., by anonymous users).

• Per-directory message files; these are shown to a user who visits that directory to provide relevant information about the directory's contents (for example, "This version is now obsolete").

• The ability to define classes of users; based on the account they log in to the server with, and/or the host from which they access, you can determine what files they have access to and when they can log in.

• Restrictions on certain classes of users. For example, wuarchive can limit the number of simultaneous anonymous users who are accessing the server; the limit can vary by time of day and day of the week. By using these restrictions, you control the load generated by the FTP server.

• The ability to compress, tar, and otherwise manipulate files automatically as they are transferred.

• Nonanonymous chrooted access, for users who need only limited access to your machines. This allows you to give a specific account access to files that are not accessible to "anonymous" without giving the account the ability to look around at everything on your disks.

Be aware that one cost of the additional power and complexity offered by wuarchive is a bigger potential for security problems. The bigger and more complex a program is, the more likely it is to contain bugs. If the program is security-critical (as the FTP server is), many of those bugs are likely to have security impacts. Some features of the wuarchive server may also interact badly with some clients (in particular, some poorly implemented clients do not deal well with the displayed messages and hang). Workarounds are available, but if a significant percentage of your users has these clients, you may want to avoid wuarchive.