idnits 2.17.1 draft-ietf-ftpext-sec-consider-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '...tion, the server SHOULD confirm that t...' RFC 2119 keyword, line 132: '...Likewise, the client SHOULD verify the...' RFC 2119 keyword, line 150: '...3-5), the server SHOULD close the cont...' RFC 2119 keyword, line 152: '... the server MUST send a return code...' RFC 2119 keyword, line 180: '...ncryption scheme SHOULD be used whenev...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 14, 1998) is 9600 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-ietf-ftpext-ftp-over-ipv6-00 ** Downref: Normative reference to an Experimental RFC: RFC 1639 (ref. 'Pis94') ** Obsolete normative reference: RFC 793 (ref. 'Pos81') (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1700 (ref. 'RP94') (Obsoleted by RFC 3232) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 FTPEXT Working Group Mark Allman 2 Internet Draft NASA Lewis/Sterling Software 3 Expires: July 14, 1998 Shawn Ostermann 4 Ohio University 5 January 14, 1998 7 FTP Security Considerations 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other documents 19 at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite them other than as ``work in 21 progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 25 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Distribution of this document is unlimited. Please send comments 30 to the FTP Extension working group (FTPEXT-WG) of the Internet 31 Engineering Task Force (IETF) at . 32 Subscription address is . 33 Discussions of the group are archived at 34 . 36 Abstract 38 The specification for the File Transfer Protocol contains a number 39 of mechanisms that can be used to compromise network security. The 40 FTP specification allows a client to instruct a server to transfer 41 files to a third machine. This third-party mechanism, known as 42 proxy FTP, causes a well known security problem. The FTP 43 specification also allows an unlimited number of attempts at 44 entering a user's password. This allows brute force ''password 45 guessing'' attacks. This document provides suggestions for system 46 administrators and those implementing FTP servers that will decrease 47 the security problems associated with FTP. 49 1 Introduction 51 The File Transfer Protocol specification [PR85] provides a mechanism 52 that allows a client to establish a data connection and transfer a 53 file between two FTP servers. This "proxy FTP" mechanism can be 54 used to decrease the amount of traffic on the network; the client 55 instructs one server to transfer a file to another server, rather 56 than transfering the file from the first server to the client and 57 then from the client to the second server. This is particularly 58 useful when the client connects to the network using a slow link 59 (e.g., a modem). While useful, proxy FTP provides a security 60 problem known as a "bounce attack". In addition to the bounce 61 attack, FTP servers can be used by attackers to guess passwords 62 using brute force. 64 This paper provides information for FTP server implementers and 65 system administrators, as follows. Section 2 describes the FTP 66 "bounce attack". Section 3 provides suggestions for minimizing the 67 bounce attack. Section 4 provides suggestions for servers which 68 limit access based on network address. Section 5 provides 69 recommendations for limiting brute force "password guessing" by 70 clients. Next, section 6 provides a brief discussion of mechanisms 71 to improve privacy. Finally, section 7 provides a mechanism to 72 prevent user identity guessing. 74 2 The Bounce Attack 76 The version of FTP specified in the standard [PR85] provides a 77 method for attacking well known network servers, while making the 78 perpetrators difficult to track down. The attack involves sending 79 an FTP "PORT" command to an FTP server containing the network 80 address and the port number of the machine and service being 81 attacked. At this point, the original client can instruct the FTP 82 server to send a file to the service being attacked. Such a file 83 would contain commands relevant to the service being attacked (SMTP, 84 NNTP, etc.). Instructing a third party to connect to the service, 85 rather than connecting directly, makes tracking down the perpetrator 86 difficult and can circumvent network address based access 87 restrictions. 89 As an example, a client uploads a file containing SMTP commands to 90 an FTP server. Then, using an appropriate PORT command, the client 91 instructs the server to open a connection to a third machine's SMTP 92 port. Finally, the client instructs the server to transfer the 93 uploaded file containing SMTP commands to the third machine. This 94 allows the client to forge mail on the third machine without making 95 a direct connection. This makes it difficult to track attackers. 97 3 Protecting Against the Bounce Attack 99 The original FTP specification [PR85] assumes that data connections 100 will be made using the Transmission Control Protocol (TCP) [Pos81]. 101 TCP port numbers in the range 0 - 1023 are reserved for well known 102 services such as mail, network news and FTP control connections 103 [RP94]. The FTP specification makes no restrictions on the TCP port 104 number used for the data connection. Therefore, using proxy FTP, 105 clients have the ability to tell the server to attack a well known 106 service on any machine. 108 To avoid such bounce attacks, it is SUGGESTED that servers not open 109 data connections to TCP ports less than 1024. If a server receives 110 a PORT command containing a TCP port number less than 1024, the 111 SUGGESTED response is 504 (defined as "Command not implemented for 112 that parameter" by [PR85]). Note that this still leaves non-well 113 known servers (those running on ports greater than 1023) vulnerable 114 to bounce attacks. 116 Several proposals (e.g., [AO97] and [Pis94]) provide a mechanism 117 that would allow data connections to be made using a transport 118 protocol other than TCP. Similar precautions should be taken to 119 protect well known services when using these protocols. 121 4 Restricted Access 123 For some FTP servers, it is desirable to restrict access based on 124 network address. For example, a server might want to restrict 125 access to certain files from certain places (e.g., a certain file 126 should not be transferred out of an organization). In such a 127 situation, the server SHOULD confirm that the network address of the 128 remote hosts on both the control connection and the data connection 129 are within the organization before sending a restricted file. By 130 checking both connections, a server is protected against the case 131 when the control connection is established with a trusted host and 132 the data connection is not. Likewise, the client SHOULD verify the 133 IP address of the remote host after accepting a connection on a port 134 opened in listen mode to verify that the connection was made by the 135 expected server. 137 Note that restricting access based on network address leaves the FTP 138 server vulnerable to "spoof" attacks. In a spoof attack, for 139 example, an attacking machine could assume the host address of 140 another machine inside an organization and download files that are 141 not accessible from outside the organization. Whenever possible, 142 secure authentication mechanisms should be used, such as those 143 outlined in [HL97]. 145 5 Protecting Passwords 147 To minimize the risk of brute force password guessing through the 148 FTP server, it is SUGGESTED that servers limit the number of 149 attempts that can be made at sending a correct password. After a 150 small number of attempts (3-5), the server SHOULD close the control 151 connection with the client. Before closing the control connection 152 the server MUST send a return code of 421 ("Service not available, 153 closing control connection." [PR85]) to the client. In addition, it 154 is SUGGESTED that the server impose a 5 second delay before replying 155 to an invalid "PASS" command to diminish the efficiency of a brute 156 force attack. If available, mechanisms already provided by the 157 target operating system should be used to implement the above 158 suggestions. 160 An intruder can subvert the above mechanisms by establishing 161 multiple, parallel control connections to a server. To combat the 162 use of multiple concurrent connections, the server could either 163 limit the total number of control connections possible or attempt to 164 detect suspicious activity across sessions and refuse further 165 connections from the site. However, both of these mechanisms open 166 the door to "denial of service" attacks, in which an attacker 167 purposely initiates the attack to disable access by a valid user. 169 Standard FTP [PR85] sends passwords in clear text using the "PASS" 170 command. It is SUGGESTED that FTP clients and servers use alternate 171 authentication mechanisms that are not subject to eavesdropping 172 (such as the mechanisms being developed by the IETF Common 173 Authentication Technology Working Group [HL97]). 175 6 Privacy 177 All data and control information (including passwords) is sent 178 across the network in unencrypted form by standard FTP [PR85]. To 179 guarantee the privacy of the information FTP transmits, a strong 180 encryption scheme SHOULD be used whenever possible. One such 181 mechanism is defined in [HL97]. 183 7 Protecting Usernames 185 Standard FTP [PR85] specifies a 530 response to the USER command 186 when the username is rejected. If the username is valid and a 187 password is required FTP returns a 331 response instead. In order 188 to prevent a malicious client from determining valid usernames on a 189 server, it is suggested that a server always return 331 to the USER 190 command and then reject the combination of username and password for 191 an invalid username. 193 8 Conclusion 195 Using the above suggestions can decrease the security problems 196 associated with FTP servers without eliminating functionality. 198 Acknowledgments 200 We would like to thank Alex Belits, Jim Bound, William Curtin, 201 Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their 202 helpful comments on this paper. Also, we thank the FTPEXT WG 203 members who gave many useful suggestions at the Memphis IETF 204 meeting. 206 References 208 [AO97] Mark Allman and Shawn Ostermann. FTP Extensions for Variable 209 Protocol Specification, January 1998. I-D 210 draft-ietf-ftpext-ftp-over-ipv6-00.txt (work in progress). 212 [HL97] M. Horowitz and S. J. Lunt. FTP Security Extensions, 213 October 1997. RFC 2228. 215 [Pis94] D. Piscitello. FTP Operation Over Big Address Records 216 (FOOBAR), June 1994. RFC 1639. 218 [Pos81] J. Postel. Transmission Control Protocol, September 1981. 219 RFC 793. 221 [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP), 222 October 1985. RFC 959. 224 [RP94] J. Reynolds and J. Postel. Assigned Numbers, October 1994. 225 RFC 1700. 227 Author's Addresses: 229 Mark Allman 230 NASA Lewis Research Center/Sterling Software 231 21000 Brookpark Rd. MS 54-2 232 Cleveland, OH 44135 233 mallman@lerc.nasa.gov 235 Shawn Ostermann 236 School of Electrical Engineering and Computer Science 237 Ohio University 238 416 Morton Hall 239 Athens, OH 45701 240 ostermann@cs.ohiou.edu