HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 22:28:27 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 24 Dec 1996 00:16:00 GMT ETag: "2f58d4-218d-32bf20c0" Accept-Ranges: bytes Content-Length: 8589 Connection: close Content-Type: text/plain Internet Engineering Task Force Mark Allman INTERNET DRAFT Shawn Ostermann File: draft-allman-ftp-sec-consider-00.txt Ohio University December 23, 1996 Expires: June 23, 1997 FTP Security Considerations Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The specification for the File Transfer Protocol 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. 1 Introduction The File Transfer Protocol specification [PR85] provides a mechanism that allows a client to establish a data 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 transfering 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 also provides a security problem, known as a "bounce attack". In addition to the bounce Expires: June 23, 1997 [Page 1] draft-allman-ftp-sec-consider-00.txt December 23, 1996 attack, FTP servers can be used by attackers to guess passwords using brute force. 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. Finally, section 5 provides recommendations for limiting brute force "password guessing" by clients. 2 The Bounce Attack The version of FTP specified in the standard [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 allows the client to forge mail on the third machine without making a direct connection. This makes it difficult to track attackers. 3 Protecting Against the Bounce Attack The original FTP specification [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]). Several proposals (e.g., [AO96] and [Pis94]) provide a mechanism that would allow data connections to be made using a transport Expires: June 23, 1997 [Page 2] draft-allman-ftp-sec-consider-00.txt December 23, 1996 protocol other than TCP. Similar precautions should be taken to protect well known services when using these protocols. 4 Restricted Access For some FTP servers, it is desirable to restrict access based on network address. For example, a server might want to restrict access to certain files from certain places (e.g., a certain file should not be transferred out of an organization). In such a situation, the server SHOULD confirm that the network address of the remote hosts on both the control connection and the data connection are within the organization before sending a restricted file. By checking both connections, a server is protected against the case when the control connection is trusted and the data connection is not. 5 Protecting Against Password Guessing To minimize the risk of brute force password guessing through the FTP server, it is SUGGESTED that servers limit the number of attempts which can be made at sending a correct password. After a small number of attempts (3-5), the server SHOULD close the control connection with the client. In addition, it is SUGGESTED that the server impose a 5 second delay before replying to an invalid "PASS" command. 6 Conclusion Using the above suggestions can decrease the security problems associated with FTP servers without eliminating functionality. Acknowledgments We would like to thank Alex Belits, Jim Bound, Robert Elz, Paul Hethmon and Alun Jones for their helpful comments on this paper. References [AO96] Mark Allman and Shawn Ostermann. FTP Extensions for Variable Protocol Specification, October 1996. I-D draft-allman-ftp-variable-03.txt (work in progress). [Pis94] D. Piscitello. FTP Operation Over Big Address Records (FOOBAR), June 1994. RFC 1639. [Pos81] J. Postel. Transmission Control Protocol, September 1981. RFC 793. [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP), October 1985. RFC 959. [RP94] J. Reynolds and J. Postel. Assigned Numbers, October 1994. RFC 1700. Expires: June 23, 1997 [Page 3] draft-allman-ftp-sec-consider-00.txt December 23, 1996 Author's Addresses: Mark Allman and Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701 mallman@cs.ohiou.edu ostermann@cs.ohiou.edu Expires: June 23, 1997 [Page 4]