8.2.1.1 Packet filtering characteristics of FTP

FTP uses two separate TCP connections: one to carry commands and results between the client and the server (commonly called the command channel), and the other to carry any actual files and directory listings transferred (the data channel). On the server end, the command channel uses well-known port 21, and the data channel normally uses well-known port 20. The client uses ports above 1023 for both the command and data channels.

To start an FTP session, 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 8.6 shows this kind of FTP connection.

Figure 8.6: A normal-mode FTP connection

Most FTP servers (particularly those used at major anonymous FTP sites on the Internet) and many FTP clients support an alternative mode that allows the client to open both the command and the data channels to the server. This mode is called "passive mode" or "PASV mode" (after the FTP command the client sends to the server to initiate this mode). If both your FTP client and the FTP server you're trying to connect to support passive mode, you can use it instead of the regular mode. This way, you can avoid start-of-connection filtering problems, because all connections will be opened from the inside, by the client.

To use passive mode, an FTP client allocates two TCP ports for its own use, and uses the first port to contact the FTP server, just as when using normal mode. However, instead of issuing the PORT command to tell the server the client's second port, the client issues the PASV command. This causes the server to allocate a second port of its own for the data channel (for architectural reasons, servers use random ports above 1023 for this, not port 20 as in normal mode; you couldn't have two servers on the same machine simultaneously listening for incoming PASV-mode data connections on port 20), and tell the client the number of that port. The client then opens the data connection from its port to the data port the server has just told it about. Figure 8.7 shows a passive-mode FTP connection.

Figure 8.7: A passive-mode FTP connection

Not all FTP clients support passive mode. If a given client does support passive mode, it will usually mention this 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 many WWW browsers (Netscape Navigator, for example) use passive mode. Chances are, your users will want to have these browsers anyway for WWW access, and you can show them how to use the browsers as FTP clients as well.

Because passive mode has only recently become popular, many times even servers that support passive mode have problems with it. You may find that combinations of servers and clients that work well with normal-mode transfers hang periodically when you do passive-mode transfers.

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, e.g., 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).

Some dynamic packet filtering implementations (such as FireWall-1 from CheckPoint Software) 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.

[6] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.

8.2.1.2 Proxying characteristics of FTP

Because of the problems with passive mode, and because of complications introduced in name service (the "double-reverse lookups" discussed in the "Domain Name Service (DNS)" section below), proxying is a particularly attractive solution for outbound FTP. Using a normal-mode proxied client allows you to talk reliably to external servers without having to allow incoming TCP connections for the data channel to any host except the bastion host doing the proxying. For this reason, you may choose to proxy FTP even if you allow most other protocols directly through the firewall via packet filtering. Both modified-client and modified-procedure proxies are available for FTP.

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).

The 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; they do 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 the 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 procedure 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 anonymous@host.some.net, 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.

Many 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 keeps you from using servers that don't support passive mode.

8.2.1.3 Providing anonymous FTP service

With anonymous FTP, a user logs in to the FTP server as "anonymous". The user is then asked for a password and is expected to enter his or her full email address in response. At most sites, this request is not enforced, however, and users can enter whatever they want, as long as it looks like an email address; even if the information is entered, it's usually just logged, not verified in any way beyond a superficial plausibility check (i.e., does it contain an at (@) sign?). Many standard FTP servers, like the ones shipped with most versions of UNIX, don't even log the information.

If you are providing anonymous FTP service, the challenge is to ensure that the anonymous FTP server makes available only the information that you want made available and that it doesn't give an outsider access to other, supposedly private, information on the machine.

In setting up anonymous FTP, one precaution you can take is to limit what other information is available on the machine that's providing anonymous FTP service. In this way, even if attackers get "outside" the anonymous FTP area on the machine, there is nothing of interest to them elsewhere on the machine (or reachable from the machine via NFS or some other mechanism).

Many FTP servers perform a chroot to the anonymous FTP area before the FTP server starts processing commands from an anonymous user. 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 chroot'd environment.

To deal with this problem, 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) 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.

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, obtain and follow CERT Advisory 93:10 (for information on obtaining CERT advisories, see Appendix A), which addresses setting up anonymous FTP servers to close the holes left by most of the vendor instructions.[7]

[7] 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; he assumes 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 an Archie server indexes them. Unless you have explicitly arranged to have your FTP site skipped, you should assume that it is being indexed; Archie is quite talented at finding sites.

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. You can also put up files in directories that have execute permission but not read 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.

8.2.1.4 Using the wuarchive FTP daemon

Many Internet sites - both major and minor - that provide anonymous FTP run the wuarchive version of the UNIX FTP server, developed at Washington University (the "wu" in the name) in St. Louis. This server provides a number of features that are especially useful for anonymous FTP servers. These include the following features and many others:

• 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 when he 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 chroot'ed 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 them the ability to look around at everything on your disks.

For information about obtaining the wuarchive FTP daemon, see Appendix B. Be sure that you are installing the genuine, most recent version. This program has in the past been distributed by attackers with added trap doors, and older versions may have security problems that have since been fixed.

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 clients do not deal well with the displayed messages and hang). There are workarounds available, but if a significant percentage of your users have these clients, you may want to avoid wuarchive.

8.2.1.5 Using the TIS FWTK FTP daemon

Instead of using the wuarchive version of the FTP server, you might consider using the FTP server from the TIS Internet Firewall Toolkit. The TIS FWTK FTP daemon has an emphasis different from that of the wuarchive daemon. The wuarchive version adds code in order to add features that support anonymous FTP. The TIS FWTK version, by contrast, concentrates on simplifying the server and making it more secure, stripping it down to the bare minimum capabilities necessary to provide anonymous FTP service. However, the maintainers of the FWTK have been considering removing it from the FWTK release, because despite all the work they've done on it, they're still not convinced that it's as secure as they'd like it to be (though it is almost certainly more secure than any alternative). It's possible that it will have been removed from the release by the time you read this.

You'll have to decide for yourself whether you really need the enhanced features provided by the wuarchive server (and are willing to accept the potential security implications of those features), or whether you'd rather have the enhanced security provided by the TIS FWTK server (assuming it's still available), at a cost of fewer features. Many users are accustomed to using wuarchive FTP and have come to depend on its features; it is probably not reasonable to attempt to run a major anonymous FTP site with the TIS FWTK server. For a site that provides only occasional anonymous FTP, however, the FWTK server is probably a more secure and reliable option.

8.2.1.6 Be careful of writable directories in the anonymous FTP area

Regardless of which FTP daemon you use, you'll have to confront a particularly troublesome issue raised by anonymous FTP servers: writable directories in the anonymous FTP area. Sites frequently provide writable space in this area, so that outsiders can upload files to them as well as download files from them; for example, a software company's customers might be asked to upload crash dump files (which are too big to conveniently send through email) so the company can do a crash analysis on them.

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; generally this means pirated software packages and pornographic image files.

The folks who do this are 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 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 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.

How can you protect your anonymous FTP areas from such misuse? The first question to ask yourself is this: do you really need to provide writable space in your anonymous FTP area? Often there are other acceptable ways (electronic mail, for example) for folks to send files to you. If you decide that you must provide writable space in your anonymous FTP area, there are a number of ways to limit your vulnerability, as we describe below.

The most obvious approach, if you're using a UNIX machine as your bastion host, is to make your "incoming" directory write-only (directory permissions 773 or 733 - that is, "rwxrwx-wx" or "rwx-wx-wx"). Make sure that the directory is owned by some user other than "ftp" (or whatever your anonymous FTP server runs as when doing anonymous FTP). If the mode is 773 instead of 733, then also make sure that the group of the directory is something other than the default group of the "ftp" login.

The problem with this approach 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. (Unfortunately, they can, via their mailing lists and other communications channels.)

Another approach is to disable the creation of directories and files with funny names (for example, files that begin with ".") in your anonymous FTP server. Depending on your server, you may be able to do this with a configuration file (for example, the wuarchive server lets you restrict anonymous users from deleting, overwriting, or creating certain types of files), or you may have to modify the server source code. (This is a nontrivial modification, which requires a reasonably competent C programmer.)

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 content of files, not just the names) to be sure everything is something that belongs there.

Another approach is used frequently by sites that want people to be able to upload files, but only by prearrangement. These sites take a page from the underground's own book by creating hidden writable subdirectories that you can only access if you know they're there. The attackers can't see them; they're unaware that there's a "there" there for their wares.

Here's what you do, assuming you're using a UNIX system for your FTP server:

1. Make an "incoming" directory.

2. Make a subdirectory there with a "secret" name, chosen in much the same way you'd choose a password - that is, something unguessable.

3. Make the subdirectory with the secret name be writable.

4. Make the parent directory (the incoming directory) mode execute-only (mode 111 - that is, --x--x--x).

For example:

unix# cd ~ftp/pub
unix# mkdir incoming
unix# cd incoming
unix# mkdir b2b_Free
unix# chmod a+w b2b_Free # or "chmod 0777 b2b_Free"
unix# cd ..
unix# chmod a=x incoming # or "chmod 0111 incoming"

Users can now upload files to the writable directory only if they know (presumably because you've told them) its secret, password-like name. You can create as many of these secret subdirectories as necessary, and you can change or delete them as often as necessary. If your site creates a top-level index of your FTP area (such as a file containing the output of "ls -lR ~ftp"), you need to make sure that the hidden directories don't appear in the index. The easiest way to do that is to run the indexing command as the "ftp" user, so that it has the same permissions that someone using anonymous FTP would have.

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.

There is one other approach you might take, particularly if you find that your anonymous FTP area is already being abused and you're curious to see what people are uploading there. Basically, you run a short shell script once a minute as a cron job that moves files from the writable incoming directory to another directory outside the anonymous FTP area. This will ensure that the intruders won't be able to see what's been uploaded. You may need to rename files when you move them to avoid overwriting files with the same name. Because the files aren't there to look at, it's easy for people to unintentionally create name conflicts (particularly if they're sending you crash dumps, which probably all start out having the same name).

Make 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).

This doesn't avoid denial of service attacks; people can still fill up your disk space. In fact, they may retry downloads multiple times (because the files keep mysteriously disappearing) and unintentionally fill up your disks.

8.2.1.7 Summary of recommendations for FTP

• If you have FTP clients that properly support passive mode, then allow internal hosts to contact external FTP servers via packet filtering. This is only safe if you can filter on the TCP ACK bit, so that you can allow only outgoing TCP connections from ports above 1023 to ports above 1023.

• If you have FTP clients that don't support passive mode, then use an FTP proxy server such as the one in the TIS Internet Firewall Toolkit.

• Consider providing FTP access via both packet filtering and proxies, supporting passive mode via packet filtering and normal mode via proxies.

• If you want to allow incoming FTP, use packet filters to allow incoming FTP only to your bastion host.

• If you allow incoming FTP (anonymous or user), use an up-to-date FTP server.

• If you allow anonymous FTP users to write files, protect the writable area so it can't be used to transfer files between third parties.

• Be careful about who within your organization can put up files for anonymous FTP, and make sure they understand what they're doing.

• If you want to allow nonanonymous FTP, see Chapter 10, Authentication and Inbound Services for a discussion of the password and authentication issues involved.

8.2.2.1 Packet filtering characteristics of TFTP

TFTP is a UDP-based protocol. Servers listen on port 69 for the initial client-to-server packet to establish the TFTP session, then use a port above 1023 for all further packets during that session. Clients use ports above 1023.

[8] UDP packets do not have ACK bits.

8.2.2.2 Proxying characteristics of TFTP

TFTP does not lend itself well to proxying. Because TFTP clients are often implemented in hardware, with no users involved, neither modified clients nor modified user procedures are generally implementable. A transparent proxy could easily support TFTP, providing the same extremely minimal amount of security achievable if you allow TFTP through packet filters.

8.2.2.3 Summary of TFTP recommendations

• Do not allow TFTP across your firewall.

8.2.3.1 Packet filtering characteristics of FSP

FSP is intentionally difficult to suppress with packet filtering. Filtering out all UDP services except those you need, and restricting those to specific hosts, will pretty well get rid of it except on the hosts you're allowing other UDP services to. If you want to allow FSP, that's extremely simple; allowing UDP packets to and from a host, at any port number, will allow it to be an FSP server and/or client.

FSP is a UDP-based protocol. There is no "standard" port number that the server runs on; anyone running a server chooses the port that server will use. If they have root access, they often choose port 21, the UDP equivalent of the TCP port used by FTP; if they don't have root access, they have to use a port above 1023, and there's no predicting what it will be. Clients generally use ports above 1023.

[9] FSP does not have standard port numbers, although people running FSP servers often put them on port 21 if they have root access (paralleling FTP servers, which use TCP port 21). Clients usually use ports above 1023, but not always.

[10] UDP packets do not have ACK bits.

8.2.3.2 Proxying characteristics of FSP

Using generic proxies to proxy a UDP-based application with no standard port number is as difficult as trying to suppress it with packet filters. No standard proxy package supports FSP. A dedicated FSP proxy would be possible to write.

8.2.3.3 Summary of FSP recommendations

• Do not allow FSP across your firewall. Block all UDP except for specific services you wish to intentionally allow, such as DNS.

8.2.4.1 Packet filtering characteristics of UUCP

UUCP over TCP is obviously a TCP-based service. Servers use port 540. Clients use ports above 1023.

[12] ACK is not set on the first packet of this type (establishing connection) but will be set on the rest.

8.2.4.2 Proxying characteristics of UUCP

UUCP is a store-and-forward protocol, and as such is not used with general-purpose proxies; instead, it's configured to effectively do its own proxying. It is a straightforward single-connection protocol used with a small number of clients, and thus is well-suited to both modified-client and modified-procedure proxying. On the other hand, it is rare for people to want to proxy it, so there are no widely available proxies specifically written for it. Generic proxy servers, such as the plug-gw program in the TIS FWTK, should work if you can decide which real server to connect to based on which client the connection request is coming from (in other words, if all connections are to the same server, or if a given client host always connects to the same server).

8.2.4.3 Summary of UUCP recommendations

• You probably do not need to allow UUCP over TCP at your site. If you do wish to use it, use packet filters to limit access to a bastion host.