idnits 2.17.1 draft-ietf-ftpext-sec-consider-02.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-25) 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1579 (ref. 'Bel94') ** 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. -------------------------------------------------------------------------------- 2 FTPEXT Working Group Mark Allman 3 Internet Draft NASA Lewis/Sterling Software 4 Expires: October, 1998 Shawn Ostermann 5 Ohio University 6 April, 1999 8 FTP Security Considerations 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as ``work in 22 progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 26 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Distribution of this document is unlimited. Please send comments 31 to the FTP Extension working group (FTPEXT-WG) of the Internet 32 Engineering Task Force (IETF) at . 33 Subscription address is . 34 Discussions of the group are archived at 35 . 37 Abstract 39 The specification for the File Transfer Protocol contains a number 40 of mechanisms that can be used to compromise network security. The 41 FTP specification allows a client to instruct a server to transfer 42 files to a third machine. This third-party mechanism, known as 43 proxy FTP, causes a well known security problem. The FTP 44 specification also allows an unlimited number of attempts at 45 entering a user's password. This allows brute force "password 46 guessing" attacks. This document provides suggestions for system 47 administrators and those implementing FTP servers that will decrease 48 the security problems associated with FTP. 50 1 Introduction 52 The File Transfer Protocol specification [PR85] provides a mechanism 53 that allows a client to establish an FTP control connection and 54 transfer a file between two FTP servers. This "proxy FTP" mechanism 55 can be used to decrease the amount of traffic on the network; the 56 client instructs one server to transfer a file to another server, 57 rather than transferring the file from the first server to the 58 client and then from the client to the second server. This is 59 particularly useful when the client connects to the network using a 60 slow link (e.g., a modem). While useful, proxy FTP provides a 61 security problem known as a "bounce attack" [CERT97:27]. In 62 addition to the bounce attack, FTP servers can be used by attackers 63 to guess passwords using brute force. 65 This document does not contain a discussion of FTP when used in 66 conjunction with strong security protocols, such as IP Security. 67 These security concerns should be documented, however they are out 68 of the scope of this document. 70 This paper provides information for FTP server implementers and 71 system administrators, as follows. Section 2 describes the FTP 72 "bounce attack". Section 3 provides suggestions for minimizing the 73 bounce attack. Section 4 provides suggestions for servers which 74 limit access based on network address. Section 5 provides 75 recommendations for limiting brute force "password guessing" by 76 clients. Next, section 6 provides a brief discussion of mechanisms 77 to improve privacy. Section 7 provides a mechanism to prevent user 78 identity guessing. Section 8 discusses the practice of port 79 stealing. Finally, section 9 provides an overview of other FTP 80 security issues related to software bugs rather than protocol 81 issues. 83 2 The Bounce Attack 85 The version of FTP specified in the standard [PR85] provides a 86 method for attacking well known network servers, while making the 87 perpetrators difficult to track down. The attack involves sending 88 an FTP "PORT" command to an FTP server containing the network 89 address and the port number of the machine and service being 90 attacked. At this point, the original client can instruct the FTP 91 server to send a file to the service being attacked. Such a file 92 would contain commands relevant to the service being attacked (SMTP, 93 NNTP, etc.). Instructing a third party to connect to the service, 94 rather than connecting directly, makes tracking down the perpetrator 95 difficult and can circumvent network-address-based access 96 restrictions. 98 As an example, a client uploads a file containing SMTP commands to 99 an FTP server. Then, using an appropriate PORT command, the client 100 instructs the server to open a connection to a third machine's SMTP 101 port. Finally, the client instructs the server to transfer the 102 uploaded file containing SMTP commands to the third machine. This 103 may allow the client to forge mail on the third machine without 104 making a direct connection. This makes it difficult to track 105 attackers. 107 3 Protecting Against the Bounce Attack 109 The original FTP specification [PR85] assumes that data connections 110 will be made using the Transmission Control Protocol (TCP) [Pos81]. 111 TCP port numbers in the range 0 - 1023 are reserved for well known 112 services such as mail, network news and FTP control connections 113 [RP94]. The FTP specification makes no restrictions on the TCP port 114 number used for the data connection. Therefore, using proxy FTP, 115 clients have the ability to tell the server to attack a well known 116 service on any machine. 118 To avoid such bounce attacks, it is suggested that servers not open 119 data connections to TCP ports less than 1024. If a server receives 120 a PORT command containing a TCP port number less than 1024, the 121 suggested response is 504 (defined as "Command not implemented for 122 that parameter" by [PR85]). Note that this still leaves non-well 123 known servers (those running on ports greater than 1023) vulnerable 124 to bounce attacks. 126 Several proposals (e.g., [AOM98] and [Pis94]) provide a mechanism 127 that would allow data connections to be made using a transport 128 protocol other than TCP. Similar precautions should be taken to 129 protect well known services when using these protocols. 131 Also note that the bounce attack generally requires that a 132 perpetrator be able to upload a file to an FTP server and later 133 download it to the service being attacked. Using proper file 134 protections will prevent this behavior. However, attackers can also 135 attack services by sending random data from a remote FTP server 136 which may cause problems for some services. 138 Disabling the PORT command is also an option for protecting against 139 the bounce attack. Most file transfers can be made using only the 140 PASV command [Bel94]. The disadvantage of disabling the PORT 141 command is that one loses the ability to use proxy FTP, but proxy 142 FTP may not be necessary in a particular environment. 144 4 Restricted Access 146 For some FTP servers, it is desirable to restrict access based on 147 network address. For example, a server might want to restrict 148 access to certain files from certain places (e.g., a certain file 149 should not be transferred out of an organization). In such a 150 situation, the server should confirm that the network address of the 151 remote hosts on both the control connection and the data connection 152 are within the organization before sending a restricted file. By 153 checking both connections, a server is protected against the case 154 when the control connection is established with a trusted host and 155 the data connection is not. Likewise, the client should verify the 156 IP address of the remote host after accepting a connection on a port 157 opened in listen mode to verify that the connection was made by the 158 expected server. 160 Note that restricting access based on network address leaves the FTP 161 server vulnerable to "spoof" attacks. In a spoof attack, for 162 example, an attacking machine could assume the host address of 163 another machine inside an organization and download files that are 164 not accessible from outside the organization. Whenever possible, 165 secure authentication mechanisms should be used, such as those 166 outlined in [HL97]. 168 5 Protecting Passwords 170 To minimize the risk of brute force password guessing through the 171 FTP server, it is suggested that servers limit the number of 172 attempts that can be made at sending a correct password. After a 173 small number of attempts (3-5), the server should close the control 174 connection with the client. Before closing the control connection 175 the server must send a return code of 421 ("Service not available, 176 closing control connection." [PR85]) to the client. In addition, it 177 is suggested that the server impose a 5 second delay before replying 178 to an invalid "PASS" command to diminish the efficiency of a brute 179 force attack. If available, mechanisms already provided by the 180 target operating system should be used to implement the above 181 suggestions. 183 An intruder can subvert the above mechanisms by establishing 184 multiple, parallel control connections to a server. To combat the 185 use of multiple concurrent connections, the server could either 186 limit the total number of control connections possible or attempt to 187 detect suspicious activity across sessions and refuse further 188 connections from the site. However, both of these mechanisms open 189 the door to "denial of service" attacks, in which an attacker 190 purposely initiates the attack to disable access by a valid user. 192 Standard FTP [PR85] sends passwords in clear text using the "PASS" 193 command. It is suggested that FTP clients and servers use alternate 194 authentication mechanisms that are not subject to eavesdropping 195 (such as the mechanisms being developed by the IETF Common 196 Authentication Technology Working Group [HL97]). 198 6 Privacy 200 All data and control information (including passwords) is sent 201 across the network in unencrypted form by standard FTP [PR85]. To 202 guarantee the privacy of the information FTP transmits, a strong 203 encryption scheme should be used whenever possible. One such 204 mechanism is defined in [HL97]. 206 7 Protecting Usernames 208 Standard FTP [PR85] specifies a 530 response to the USER command 209 when the username is rejected. If the username is valid and a 210 password is required FTP returns a 331 response instead. In order 211 to prevent a malicious client from determining valid usernames on a 212 server, it is suggested that a server always return 331 to the USER 213 command and then reject the combination of username and password for 214 an invalid username. 216 8 Port Stealing 218 Many operating systems assign dynamic port numbers in increasing 219 order. By making a legitimate transfer, an attacker can observe the 220 current port number allocated by the server and ``guess'' the next 221 one that will be used. The attacker can make a connection to this 222 port, thus denying another legimate client the ability to make a 223 transfer. Alternativly, the attacker can steal a file meant for a 224 legitimate user. In addition, an attacker can insert a forged file 225 into a data stream thought to come from an authenticated client. 226 This problem can be mitigated by making FTP clients and servers use 227 random local port numbers for data connections, either by requesting 228 random ports from the operating system or using system dependent 229 mechanisms. 231 9 Software-Base Security Problems 233 The emphasis in this document is on protocol-related security 234 issues. There are a number of documented FTP security-related 235 problems that are due to poor implementation as well. Although the 236 details of these types of problems are beyond the scope of this 237 document, it should be pointed out that the following FTP features 238 has been abused in the past and should be treated with great care by 239 future implementers: 241 Anonymous FTP 243 Anonymous FTP refers to the ability of a client to connect to an 244 FTP server with minimal authentication and gain access to public 245 files. Security problems arise when such a user can read all 246 files on the system or can create files. [CERT92:09] [CERT93:06] 248 Remote Command Execution 250 An optional FTP extension, "SITE EXEC", allows clients to 251 execute arbitrary commands on the server. This feature should 252 obviously be implemented with great care. There are several 253 documented cases of the FTP "SITE EXEC" command being used to 254 subvert server security [CERT94:08] [CERT95:16] 256 Debug Code 258 Several previous security compromises related to FTP can be 259 attributed to software that was installed with debugging 260 features enabled [CERT88:01]. 262 This document recommends that implementors of FTP servers with these 263 capabilities review all of the CERT advisories for attacks on these 264 or similar mechanisms before releasing their software. 266 10 Conclusion 268 Using the above suggestions can decrease the security problems 269 associated with FTP servers without eliminating functionality. 271 Acknowledgments 273 We would like to thank Alex Belits, Jim Bound, William Curtin, 274 Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their 275 helpful comments on this paper. Also, we thank the FTPEXT WG 276 members who gave many useful suggestions at the Memphis IETF 277 meeting. 279 References 281 [AOM98] Mark Allman, Shawn Ostermann, Craig Metz. FTP Extensions 282 for IPv6 and NATs, September 1998. RFC 2428. 284 [Bel94] Steve Bellovin. Firewall-Friendly FTP, February 1994. RFC 285 1579. 287 [CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December, 288 1988 ftp://info.cert.org/pub/cert_advisories/ 290 [CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability. 291 April 27, 1992. ftp://info.cert.org/pub/cert_advisories/ 293 [CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability. 294 September 19,1997 ftp://info.cert.org/pub/cert_advisories/ 296 [CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September 297 23, 1997. ftp://info.cert.org/pub/cert_advisories/ 299 [CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration 300 Vulnerability. September 23, 1997 301 ftp://info.cert.org/pub/cert_advisories/ 303 [CERT97:27] CERT Advisory CA-97.27. FTP Bounce. January 8, 304 1998. ftp://info.cert.org/pub/cert_advisories/ 306 [HL97] M. Horowitz and S. J. Lunt. FTP Security Extensions, 307 October 1997. RFC 2228. 309 [Pis94] D. Piscitello. FTP Operation Over Big Address Records 310 (FOOBAR), June 1994. RFC 1639. 312 [Pos81] J. Postel. Transmission Control Protocol, September 1981. 313 RFC 793. 315 [PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP), 316 October 1985. RFC 959. 318 [RP94] J. Reynolds and J. Postel. Assigned Numbers, October 1994. 319 RFC 1700. http://www.iana.org. 321 Author's Addresses: 323 Mark Allman 324 NASA Lewis Research Center/Sterling Software 325 21000 Brookpark Rd. MS 54-2 326 Cleveland, OH 44135 327 mallman@lerc.nasa.gov 329 Shawn Ostermann 330 School of Electrical Engineering and Computer Science 331 Ohio University 332 416 Morton Hall 333 Athens, OH 45701 334 ostermann@cs.ohiou.edu