When using mobile computers, it is useful to have some sort of hybrid between these two options; a mobile computer may not be able to contact a file server to use a file that's located on the server, so local copies are desirable, but the mobile is unlikely to be reliably backed up and accessible to other people, so server-based files are desirable. Although there are various solutions to this situation, all of them involve using existing protocols designed for file transfer or for file sharing. The most common versions are programs like Microsoft's Briefcase, which use file sharing to synchronize files between a mobile computer and a server.
FTP is the de facto standard for file transfer on the Internet. In addition, some specialized protocols are used for applications where FTP is not suitable. TFTP is used by dedicated devices to transfer configuration files.
NFS is the de facto standard for file sharing under Unix, although AFS and DCE DFS are both used at some sites. CIFS/SMB and NetWare are used for file sharing under Microsoft network operating systems. AppleShare is the file sharing protocol for Apple Macintoshes. There are a wide variety of ways to mix and match these protocols (for instance, Unix machines can run SMB and NetWare, Microsoft and Apple machines can run NFS, and Microsoft servers can translate NetWare and AppleShare into SMB).
Printing is effectively a special case of file transfer, in which files are transferred to the printer. Not only does printing have most of the same security properties as file transfer, it is actually implemented as a special type of file transfer on many platforms, so we have included it here.
Anonymous FTP is by far the most common use of FTP on the Internet. Anonymous FTP servers are the standard mechanism for distributing source code, compiled programs, information, and other files that sites wish to make available to the Internet at large. If a site provides an anonymous FTP server, anyone on the Internet can initiate an FTP connection to the site, tell the FTP server that their login name is "anonymous", and access whatever files the server's owners have chosen to make available in a restricted area. This process is done automatically by most web browsers when they encounter a URL that begins "ftp:", so many people use FTP without being aware that they are doing so.
To start an FTP session in normal mode, a client first allocates two TCP ports for itself, each of them with a port number above 1024. It uses the first to open the command channel connection to the server and then issues FTP's PORT command to tell the server the number of the second port, which the client wants to use for the data channel. The server then opens the data channel connection. This data channel connection is backwards from most protocols, which open connections from the client to the server. This backwards open complicates things for sites that are attempting to do start-of-connection packet filtering to ensure that all TCP connections are initiated from the inside, because external FTP servers will attempt to initiate data connections to internal clients, in response to command connections opened from those internal clients. Furthermore, these connections will be going to ports known to be in an unsafe range. Figure 17-1 shows this kind of FTP connection.
ost FTP servers in widespread use support passive mode, but not all FTP clients do. If a given client does support passive mode, it will usually be mentioned as a feature in the documentation or description. Some clients support both normal and passive modes and provide the user some way to specify which mode to use. If you're having trouble finding passive-mode clients, it's useful to know that the built-in FTP clients in most web browsers (Netscape Navigator, for example) use passive mode. Chances are, your users will want to have these browsers anyway for web access, and you can show them how to use the browsers as FTP clients as well.
Different FTP servers have different strengths and weaknesses. You may find that combinations of servers and clients that work well with normal-mode transfers hang periodically when you do passive-mode transfers, or vice versa. You may also find some FTP servers that have difficulty with web browsers as FTP clients, even when they support other clients in passive mode.
If your FTP client (or one of the FTP servers you wish to communicate with) does not support passive mode, and you still want to allow FTP via packet filtering (rather than via proxy), you'll have to put a special-case exception in your packet filtering rules to allow the server to open the data channel back in to the client. If you do so, you will still be vulnerable to attackers launching a connection from port 20 on the attacker's end (nominally the FTP data channel, but you have no way to guarantee that on a machine you don't control) to a port above 1023 on your end (such as an X server, for example). Therefore, you should restrict this special-case exception as much as possible -- for example, by tying it to the address of the particular client or server that doesn't support passive mode. (Even an exception for a single server makes you vulnerable to forged connections from that server.)
Most dynamic packet filtering implementations monitor the commands sent over the FTP command channel and notice the PORT command the client sends to the server. This command tells the server on which port the client is listening for the server to open the data channel. These implementations also put in place a temporary (time-limited) exception in the packet filtering rules to allow the server to open the data channel back to the client.
|Incoming FTP request|
|Out||Int||Ext||TCP||21||>1023||Yes||Response to incoming request|
|Out||Int||Ext||TCP||20||>1023||||Data channel creation for incoming FTP request, normal mode|
|In||Ext||Int||TCP||>1023||20||Yes||Data channel responses for incoming FTP request, normal mode|
|In||Ext||Int||TCP||>1023||>1023||||Data channel creation for incoming FTP request, passive mode|
|Out||Int||Ext||TCP||>1023||>1023||Yes||Data channel responses for incoming FTP request, passive mode|
|Out||Int||Ext||TCP||>1023||21||||Outgoing FTP request|
|In||Ext||Int||TCP||21||>1023||Yes||Response to outgoing request|
|In||Ext||Int||TCP||20||>1023||||Data channel creation for outgoing FTP request, normal mode|
|Out||Int||Ext||TCP||>1023||20||Yes||Data channel responses for outgoing FTP request, normal mode|
|Out||Int||Ext||TCP||>1023||>1023||||Data channel creation for outgoing FTP request, passive mode|
|In||Ext||Int||TCP||>1023||>1023||Yes||Data channel responses for outgoing FTP request, passive mode|
The SOCKS package includes an FTP client for Unix that has been modified to use SOCKS. Because of the multiple simultaneous TCP connections involved in FTP, modifying other FTP clients yourself requires some work (more than modifying clients for straightforward single-connection protocols like SMTP and POP).
TIS FWTK provides a proxy FTP server that operates with modified clients or modified user procedures. It provides additional logging, operation denial, and user authentication features, giving you finer control than you can achieve with packet filters or SOCKS proxying.
If you want to use modified clients with the TIS FWTK FTP proxy server, you will need to do all of the modification yourself; the proxy server does not provide a modified client or even a client library. Using modified clients with the TIS FWTK FTP proxy server will also prevent you from running a standard FTP server on the machine you're using as the proxy server. Some versions of FWTK have had an FTP server that could act as a proxy server and a regular FTP server, but there have been some problems with it, and it's not clear that it will continue to be included with newer releases of the toolkit.
Some FTP clients are not sufficiently flexible to be used with modified user procedures involving the TIS FWTK FTP proxy server. The custom procedures users have to follow involve opening an FTP connection to the machine where the proxy server is running and then logging into the FTP proxy server as email@example.com, specifying the name of the host they really want to connect to as part of the login. Some FTP clients have "anonymous" simply hardcoded in or limit the length of the login field to something too short to contain "anonymous@" plus a reasonably long hostname.
Any commercial proxying packages will almost certainly support outbound FTP proxying because FTP is such a commonly used protocol on the Internet.
any sites use both proxy and packet filtering solutions for FTP. You can sometimes reduce the number of modified clients you need by using proxying to support normal-mode connections and packet filtering to support passive-mode connections. You can also use a combined solution for added security by using a proxy FTP server that uses passive mode to make external connections, regardless of the mode it uses to talk to the internal hosts; this converts all connections that cross the firewall to passive mode and allows you to tighten the packet filters that protect the host doing the proxying. On the other hand, it will prevent you from using servers that don't support passive mode.
There are three main ways you can limit the risks of providing anonymous FTP service:
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. (There doesn't seem to be an equivalent source of information for Windows NT FTP servers.)
Many vendors ship instructions containing critical problems, ranging from security holes to missing steps that disable parts of FTP's functionality.Unfortunately, one of the most common ways that anonymous users get access to files they shouldn't be able to see is that an internal user innocently puts the files up for anonymous FTP, on the assumption that this is somehow safe. Usually, the internal user is relying on security through obscurity, assuming that nobody will notice the files. This does not work well. People do notice, especially if the names of the new files are meaningful. At popular FTP sites, curious people poke around randomly, and they notice new files almost immediately and may transfer them out of pure curiosity. On less-visited FTP sites, files may remain unnoticed until some service indexes them. Unless you have explicitly arranged to have your FTP site skipped, you should assume that it is being indexed.
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.
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:
The problem with this approach under Unix is that all you're doing is keeping people from being able to see what's in the top-level directory. They can still see what's in subdirectories, and they can still access files and directories they create in the top-level directory if they communicate exact filenames among themselves (and they can, via their mailing lists and other communications channels).
Under Windows NT, since you can specify the permissions that files are created with, you do not have this problem. On the other hand, the filesystem will allow the creator to change those permissions; you are relying on there being no way for an anonymous FTP user to take advantage of it. Microsoft's FTP server does not allow users to change permissions, so there is no automatic problem. However, if the anonymous user has any further access (for instance, a bug allows them to cause the FTP server to execute arbitrary code, even with the anonymous user's normal user permissions), it may be possible to make files readable.
This approach doesn't keep people from uploading stuff to the writable directory you provide; it simply makes it more difficult for them to hide that stuff so that it escapes your notice. If you do this, you will still need to look at the writable area every day (and look at the contents of files, not just the names) to be sure everything is something that belongs there.
Here's what you do:
Beware that some FTP clients with graphical user interfaces will only let a user access a directory that the FTP client can see; they don't provide a way for the user to jump blindly to a directory that doesn't appear in a directory listing. Such clients won't work with this scheme because, by design, the client can't see the names of the subdirectories containing the actual data. This is not usually a problem for people coming in from Unix machines, and there are publicly available clients for most platforms that do not have this problem, so you may be able to work around this limitation.
ake sure that the new directory is on the same filesystem, so the operating system doesn't have to copy the data. Because of the way that the Unix filesystem works, this approach works even if the file is still being written when the "move" takes place, as long as the directory you're moving it to is on the same filesystem as the original directory ("moving" a file in such a case doesn't actually move the data; it merely renames the file). You should also be cautious about how you handle the original filename. People can create files with names that contain space, newlines, and other interesting characters that wreak havoc with carelessly written shell scripts.
This approach doesn't avoid denial of service attacks; people can still fill up your disk space. In fact, they may retry uploads multiple times (because the files keep mysteriously disappearing) and unintentionally fill up your disks.
This approach doesn't work as well on Windows NT because the FTP server opens files in a mode that does not allow any other process to access them. It's therefore impossible to move files while they are being written. On the other hand, people can't read them while they're being written, either, so you don't lose much by moving only files that are complete.
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.
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.
|16.9. Network News Transfer Protocol||17.2. Trivial File Transfer Protocol|
Copyright © 2002 O'Reilly & Associates. All rights reserved.