Network Working Group M. Allman Request for Comments: 2577 NASA Glenn/Sterling Software Category: Informational S. Ostermann Ohio University May 1999 FTP Security Considerations Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.
AbstractThe specification for the File Transfer Protocol (FTP) contains a number of mechanisms that can be used to compromise network security. The FTP specification allows a client to instruct a server to transfer files to a third machine. This third-party mechanism, known as proxy FTP, causes a well known security problem. The FTP specification also allows an unlimited number of attempts at entering a user's password. This allows brute force "password guessing" attacks. This document provides suggestions for system administrators and those implementing FTP servers that will decrease the security problems associated with FTP. PR85] provides a mechanism that allows a client to establish an FTP control connection and transfer a file between two FTP servers. This "proxy FTP" mechanism can be used to decrease the amount of traffic on the network; the client instructs one server to transfer a file to another server, rather than transferring the file from the first server to the client and then from the client to the second server. This is particularly useful when the client connects to the network using a slow link (e.g., a modem). While useful, proxy FTP provides a security problem known as a "bounce attack" [CERT97:27]. In addition to the bounce attack, FTP servers can be used by attackers to guess passwords using brute force.
This document does not contain a discussion of FTP when used in conjunction with strong security protocols, such as IP Security. These security concerns should be documented, however they are out of the scope of this document. This paper provides information for FTP server implementers and system administrators, as follows. Section 2 describes the FTP "bounce attack". Section 3 provides suggestions for minimizing the bounce attack. Section 4 provides suggestions for servers which limit access based on network address. Section 5 provides recommendations for limiting brute force "password guessing" by clients. Next, section 6 provides a brief discussion of mechanisms to improve privacy. Section 7 provides a mechanism to prevent user identity guessing. Section 8 discusses the practice of port stealing. Finally, section 9 provides an overview of other FTP security issues related to software bugs rather than protocol issues. PR85] provides a method for attacking well known network servers, while making the perpetrators difficult to track down. The attack involves sending an FTP "PORT" command to an FTP server containing the network address and the port number of the machine and service being attacked. At this point, the original client can instruct the FTP server to send a file to the service being attacked. Such a file would contain commands relevant to the service being attacked (SMTP, NNTP, etc.). Instructing a third party to connect to the service, rather than connecting directly, makes tracking down the perpetrator difficult and can circumvent network-address-based access restrictions. As an example, a client uploads a file containing SMTP commands to an FTP server. Then, using an appropriate PORT command, the client instructs the server to open a connection to a third machine's SMTP port. Finally, the client instructs the server to transfer the uploaded file containing SMTP commands to the third machine. This may allow the client to forge mail on the third machine without making a direct connection. This makes it difficult to track attackers. PR85] assumes that data connections will be made using the Transmission Control Protocol (TCP) [Pos81]. TCP port numbers in the range 0 - 1023 are reserved for well known services such as mail, network news and FTP control connections [RP94]. The FTP specification makes no restrictions on the TCP port number used for the data connection. Therefore, using proxy FTP,
clients have the ability to tell the server to attack a well known service on any machine. To avoid such bounce attacks, it is suggested that servers not open data connections to TCP ports less than 1024. If a server receives a PORT command containing a TCP port number less than 1024, the suggested response is 504 (defined as "Command not implemented for that parameter" by [PR85]). Note that this still leaves non-well known servers (those running on ports greater than 1023) vulnerable to bounce attacks. Several proposals (e.g., [AOM98] and [Pis94]) provide a mechanism that would allow data connections to be made using a transport protocol other than TCP. Similar precautions should be taken to protect well known services when using these protocols. Also note that the bounce attack generally requires that a perpetrator be able to upload a file to an FTP server and later download it to the service being attacked. Using proper file protections will prevent this behavior. However, attackers can also attack services by sending random data from a remote FTP server which may cause problems for some services. Disabling the PORT command is also an option for protecting against the bounce attack. Most file transfers can be made using only the PASV command [Bel94]. The disadvantage of disabling the PORT command is that one loses the ability to use proxy FTP, but proxy FTP may not be necessary in a particular environment.
not accessible from outside the organization. Whenever possible, secure authentication mechanisms should be used, such as those outlined in [HL97]. PR85]) to the client. In addition, it is suggested that the server impose a 5 second delay before replying to an invalid "PASS" command to diminish the efficiency of a brute force attack. If available, mechanisms already provided by the target operating system should be used to implement the above suggestions. An intruder can subvert the above mechanisms by establishing multiple, parallel control connections to a server. To combat the use of multiple concurrent connections, the server could either limit the total number of control connections possible or attempt to detect suspicious activity across sessions and refuse further connections from the site. However, both of these mechanisms open the door to "denial of service" attacks, in which an attacker purposely initiates the attack to disable access by a valid user. Standard FTP [PR85] sends passwords in clear text using the "PASS" command. It is suggested that FTP clients and servers use alternate authentication mechanisms that are not subject to eavesdropping (such as the mechanisms being developed by the IETF Common Authentication Technology Working Group [HL97]). PR85]. To guarantee the privacy of the information FTP transmits, a strong encryption scheme should be used whenever possible. One such mechanism is defined in [HL97]. PR85] specifies a 530 response to the USER command when the username is rejected. If the username is valid and a password is required FTP returns a 331 response instead. In order to prevent a malicious client from determining valid usernames on a server, it is suggested that a server always return 331 to the USER command and
then reject the combination of username and password for an invalid username. CERT92:09] [CERT93:06] Remote Command Execution An optional FTP extension, "SITE EXEC", allows clients to execute arbitrary commands on the server. This feature should obviously be implemented with great care. There are several documented cases of the FTP "SITE EXEC" command being used to subvert server security [CERT94:08] [CERT95:16] Debug Code Several previous security compromises related to FTP can be attributed to software that was installed with debugging features enabled [CERT88:01].
This document recommends that implementors of FTP servers with these capabilities review all of the CERT advisories for attacks on these or similar mechanisms before releasing their software. [AOM98] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998. [Bel94] Bellovin. S., "Firewall-Friendly FTP", RFC 1579, February 1994. [CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December, 1988 ftp://info.cert.org/pub/cert_advisories/ [CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability. April 27, 1992. ftp://info.cert.org/pub/cert_advisories/ [CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability. September 19,1997 ftp://info.cert.org/pub/cert_advisories/ [CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September 23, 1997. ftp://info.cert.org/pub/cert_advisories/ [CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration Vulnerability. September 23, 1997 ftp://info.cert.org/pub/cert_advisories/ [CERT97:27] CERT Advisory CA-97.27. FTP Bounce. January 8, 1998. ftp://info.cert.org/pub/cert_advisories/
[HL97] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997. [Pis94] Piscitello, D., "FTP Operation Over Big Address Records (FOOBAR), RFC 1639, June 1994. [Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [PR85] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985. [RP94] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. See also: http://www.iana.org/numbers.html
Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.