RFC 2577

RFC 2577: FTP Security Considerations 🎀

okay bestie, this one is RFC 2577, titled FTP Security Considerations. It was published in May 1999 and sits in the Network Working Group stream. 🦋 Its category is Informational, so it's sharing knowledge with the Internet community and isn't a standard. The authors are M. Allman from NASA Glenn/Sterling Software and S. Ostermann from Ohio University. ✨ The title block doesn't list anything it obsoletes or updates.

---

Status of this Memo 💅

so this memo is here to provide information for the Internet community 🌸 It is NOT a standard of any kind, and nothing about it is an official spec. Also, anyone can distribute it as much as they want, because distribution of this memo is unlimited 🫶

Copyright Notice 🌈

Copyright (C) The Internet Society (1999). All Rights Reserved. 💜

Abstract ✨

okay bestie, the FTP spec has a few sneaky ways to mess with network security 😭. First, a client can tell a server to send files to a third machine. That's the proxy FTP thing, and it causes a well known security problem 💀. Second, there's no cap on how many times you can try a password, so brute force "password guessing" attacks are totally on the table 🙈. This doc gives system admins and FTP server builders some suggestions to shrink both problems 🫶.

1. Introduction 🦋

okay so the File Transfer Protocol specification (FTP) [PR85] lets a client open an FTP control connection and move a file between two FTP servers 📂. This "proxy FTP" trick cuts down on network traffic. The client tells one server to send a file to another server, instead of pulling the file down to the client and then pushing it up to the second server. It's super useful when the client is on a slow link, like a modem 🐢. BUT proxy FTP comes with a security problem called a "bounce attack" [CERT97:27] 😬. On top of that, FTP servers can be used by attackers to guess passwords with brute force.

this doc doesn't cover FTP used with strong security protocols like IP Security. Those security concerns should be documented, however they're out of scope here 🙅‍♀️.

this paper is for FTP server implementers and system admins, and here's the tea ☕. Section 2 describes the FTP "bounce attack". Section 3 gives suggestions for minimizing the bounce attack. Section 4 gives suggestions for servers that limit access based on network address. Section 5 has recommendations for limiting brute force "password guessing" by clients. Next, section 6 gives 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 gives an overview of other FTP security issues related to software bugs rather than protocol issues 🐛.

2. The Bounce Attack 🏹

the version of FTP in the standard [PR85] gives attackers a way to hit well known network servers while staying super hard to track down 👀. The attack goes like this: the attacker sends an FTP "PORT" command to an FTP server, and that command contains the network address and port number of the machine and service being targeted. Then the original client can tell the FTP server to send a file to the targeted service. That file would contain commands meant for that service (SMTP, NNTP, etc.). Because a third party is the one connecting, instead of the attacker connecting directly, the perpetrator is way harder to track and it can even dodge network-address-based access restrictions 🥷.

Here's an example, bestie. A client uploads a file full of SMTP commands to an FTP server 📨. Then, using an appropriate PORT command, the client tells the server to open a connection to a third machine's SMTP port. Finally, the client tells the server to send that uploaded SMTP file to the third machine. This may let the client forge mail on the third machine without ever making a direct connection 💀. Which is exactly why it's so hard to track attackers.

3. Protecting Against the Bounce Attack 🛡️

the original FTP spec [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 spec puts no restrictions on the TCP port number used for the data connection 🤷‍♀️. So with proxy FTP, clients have the power to tell the server to attack a well known service on any machine. Main character energy, but make it villain-coded 😈.

To avoid these 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 (the ones running on ports greater than 1023) vulnerable to bounce attacks 😭.

Several proposals (e.g., [AOM98] and [Pis94]) offer a mechanism that would let data connections use a transport protocol other than TCP 🔄. Similar precautions should be taken to protect well known services when using these protocols.

Also, the bounce attack generally needs a perpetrator who can 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 another option for protecting against the bounce attack 🙅. Most file transfers can be made using only the PASV command [Bel94]. The downside is that you lose the ability to use proxy FTP, but honestly proxy FTP may not be necessary in a particular environment 💅.

4. Restricted Access 🚪

sometimes it's desirable for an FTP server to restrict access based on network address 🧐. For example, a server might want to limit access to certain files from certain places (like a file that should never be transferred out of an organization). In that situation, the server should confirm that the network addresses of the remote hosts on both the control connection and the data connection are inside the organization before sending a restricted file. Checking both connections protects the server from the case where the control connection is set up with a trusted host and the data connection isn't 🫣. Likewise, the client should verify the IP address of the remote host after accepting a connection on a port opened in listen mode, to make sure the connection came from the expected server ✅.

Note that restricting access based on network address still leaves the FTP server open to "spoof" attacks 🎭. In a spoof attack, for example, an attacking machine could assume the host address of another machine inside an organization and download files that aren't accessible from outside the organization. Whenever possible, secure authentication mechanisms should be used, such as those outlined in [HL97] 🔑.

5. Protecting Passwords 🔐

to minimize the risk of brute force password guessing through the FTP server, it is suggested that servers limit the number of attempts that 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. Before closing the control connection, the server must send a return code of 421 ("Service not available, closing control connection." [PR85]) to the client 👋. It's also suggested that the server impose a 5 second delay before replying to an invalid "PASS" command, which makes a brute force attack way less efficient 🐌. If available, mechanisms already provided by the target operating system should be used to implement the above suggestions 🧠.

okay but an intruder can get around all that by opening multiple, parallel control connections to a server 😤. To fight multiple concurrent connections, the server could either limit the total number of control connections possible, or try to detect suspicious activity across sessions and refuse further connections from that site. BUT both of these options open the door to "denial of service" attacks, where an attacker purposely starts the attack to lock out a valid user 🚫.

Standard FTP [PR85] sends passwords in clear text using the "PASS" command 😱. It's suggested that FTP clients and servers use alternate authentication mechanisms that aren't subject to eavesdropping (like the mechanisms being developed by the IETF Common Authentication Technology Working Group [HL97]) 🕵️‍♀️.

6. Privacy 🙈

All data and control information (including passwords) is sent across the network in unencrypted form by standard FTP [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]. Literally the most important thing in this whole section, so screenshot it 📸.

7. Protecting Usernames 👤

Standard FTP [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. Here's the problem: a malicious client could use that difference to figure out which usernames are real 👀. To stop that, 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. Sneaky, but make it make sense 🧩.

8. Port Stealing 🏴‍☠️

many operating systems assign dynamic port numbers in increasing order 🔢. By making a legitimate transfer, an attacker can observe the current port number the server allocated and "guess" the next one that will be used. The attacker can then connect to that port, which denies another legitimate client the ability to make a transfer. Alternatively, the attacker can steal a file meant for a legitimate user 😤. An attacker can also insert a forged file into a data stream that's thought to come from an authenticated client. This problem can be mitigated by making FTP clients and servers use random local port numbers for data connections, either by requesting random ports from the operating system or by using system-dependent mechanisms 🎲.

9. Software-Base Security Problems 💀

the emphasis in this document is on protocol-related security issues. There are a bunch of documented FTP security problems that come from poor implementation, too 🙃. The details of these are beyond the scope of this doc, but it should be pointed out that the following FTP features have been abused in the past and should be treated with great care by future implementers 🧨:

Anonymous FTP

Anonymous FTP is the ability of a client to connect to an FTP server with minimal authentication and get access to public files 📁. Security problems pop up when such a user can read all files on the system or create files. [CERT92:09] [CERT93:06]

Remote Command Execution

An optional FTP extension, "SITE EXEC", lets clients run 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 traced back 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 📚. Do your homework, bestie 🫶.

10. Conclusion 🎀

Using the above suggestions can decrease the security problems associated with FTP servers without eliminating functionality. Security glow-up with zero features lost 👑✨.

11. Security Considerations ✨

Okay so the security stuff is threaded through the whole memo, bestie 🔒 It's giving "read the entire thing, every part matters" energy 💅

Acknowledgments 🫶

Okay, big thank-yous to Alex Belits, Jim Bound, William Curtin, Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their super helpful comments on this paper 🌸 Also shoutout to the FTPEXT WG members who dropped so many useful suggestions at the Memphis IETF meeting 💜

References 📚

Here's the reading list, complete with every detail 🦋

• [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

Authors' Addresses 🎀

Mark Allman NASA Glenn Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135

EMail: mallman@grc.nasa.gov

Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701

EMail: ostermann@cs.ohiou.edu

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 💖