FTP is the File Transfer Protocol. An FTP client makes a TCP/IP connection to an FTP server (TCP port 21), and authenticates (or in the case of an anonymous server, supplies an e-mail address). The client can list, put, or retrieve files.

Most client/server protocols use just one server port, whereas FTP uses two—one is a control connection for handling commands (port 21), and the other is a data connection (port 20) for transferring data. The data connection can be active or passive. The server initiates an active connection based on a port number specified by the client, whereas the client initiates a passive connection based on a port number specified by the FTP server. This has implications for your ability to successfully firewall FTP as the firewall must dynamically allow data connections based on information transferred via the command connection. This requires the firewall to be able to decode FTP command connections properly and track FTP protocol state transitions. The data connection takes place over an ephemeral port (that is, a port greater than 1024). Standard routers don't normally offer this level of sophistication, which means that network administrators have to implement very relaxed ACLs.

FTP Risks

The FTP protocol design is tricky to secure. The base FTP specification can be found in RFC 959—however, there are many extensions. Firewall vendors hate it, warez peddlers love it, and security practitioners try to avoid it.

Some of the risks of running FTP are

· As with TELNET, there is no encryption so the MITM attacks apply.

· As with Telnet, many FTP daemons announce system/daemon version information when a client connects. This is an information leak.

· RFC-compliant FTP daemons permit port-bouncing attacks. Port bouncing is a technique whereby an attacker instructs a remote FTP server to port scan an unrelated system through judicious use of the FTP PORT command. The victim machine sees connections from the FTP server, hence the attacker doesn't get the blame. Bounce attacks can also be used to bypass basic packet-filtering devices and export restrictions on software downloads.

This is an old problem, and some vendors eventually broke with RFC compliance to prevent this. Other vendors still ship FTP daemons susceptible to this "feature." Hobbit is credited with discovering this weakness. His paper can be viewed online here: http://www.insecure.org/nmap/hobbit.ftpbounce.txt.

· The FTP protocol is hard to firewall properly. To set up the data connection, TCP/IP addressing information is passed down the control connection. To figure out the correct address/port pair to allow through, the firewall must carefully monitor the control con nection. Basic packet-filtering devices don't have the application layer protocol intelligence to do this, and, therefore, large holes have to be punched in network ACLs just to support FTP. A second, more serious problem is the difficulty firewalls seem to have correctly understanding the application dialogue between client and server. This can be exploited to attack other network services running on the same system with the FTP server.

Note

Originally reported by Mikael Olsson, the same problem was independently discovered by John McDonald (also known as Horizon) and Thomas Lopatic. This was against Checkpoint FW1 and a Solaris FTP server, but the principle applies to any other combination where the firewall incorrectly parses the FTP control stream.

· FTP servers that ship with proprietary distributions typically provide very little access control capability.

· Access control can be confusing and prone to procedural failure. Some FTP daemons consult a file called ftpusers, which contains a list of users who may not use FTP. This tends to confuse novice administrators and, even in experienced hands, leads to new users not being included; that is, when a new user is added to the system, he gets FTP access by default. If your site policy is based on the least-privilege principle, this is not helpful.

· Writable, anonymous FTP servers are incredibly hard to secure. Allowing anyone to write to your filesystem is hard to do securely.

· The default umask setting on many FTP daemons results in newly created files accessible to everyone. This is commonly a result of inheriting an weak umask from inetd (the daemon that spawns the FTP deamon).

· By default, many proprietary FTP daemons do not log client connections.

Securing FTP

If you want to offer anonymous FTP services to untrusted clients, give serious consideration to using a dedicated, standalone system (on its own DMZ off the firewall). This isolates any break-in to the FTP service only. And, as the old saying goes, "A chain is only as strong as its weakest link."

The server should be stripped down. Only the FTP service should be accessible to the untrusted clients (for example, the Internet).

A popular alternative to running a proprietary FTP daemon is the Washington University FTP daemon available from http://www.wu-ftpd.org/. This enhanced FTP server provides additional functionality useful for minimizing abuse. However, it has a spotted history security wise. If you choose to run it, be prepared to upgrade in a hurry when the next major hole is discovered, and every script kiddy is trawling the Internet looking for vulnerable wu-ftpd installations.

Alternatively, evaluate the benefits of running a cut-down FTP daemon. Dan Bernstein has written a drop-in FTP replacement called Publicfile, designed and written with security as its primary goal. It is ideal for anonymous FTP. The download page is http://cr.yp.to/publicfile.html. Publicfile can also serve as a very basic Web server—serving static content only.

If at all possible, avoid running an anonymous writable FTP server altogether. You're likely to end up acting as a mirror for pirated software hidden in surreptitiously named directories. Not only that but write access to the filesystem aids an attacker who can leverage even a minor misconfiguration on your part. For a pretty comprehensive list of anonymous FTP abuses, check out http://www.uga.edu/ucns/wsg/security/FTP/anonymous_ftp_abuses.html.

Various schemes have been proposed to date, but none seem to be bulletproof. However, that said, you could do worse than follow CERT's advice given here: http://www.bristol.ac.uk/is/computing/advice/networks/documentation/anonftp/anonftp.html

Finally, activate FTP daemon logging and make sure that syslog is configured to log LOG_DAEMON messages. (Check your ftpd man page for the specific logging facility used.)