FTP Security Considerations
A short checklist of ways FTP servers can be abused, and how server authors and administrators can blunt each one.
Allman, M. and S. Ostermann, "FTP Security Considerations", RFC 2577, DOI 10.17487/RFC2577, May 1999, <https://www.rfc-editor.org/info/rfc2577>.
@misc{rfc2577,
series = {Request for Comments},
number = 2577,
howpublished = {RFC 2577},
publisher = {RFC Editor},
doi = {10.17487/RFC2577},
url = {https://www.rfc-editor.org/info/rfc2577},
author = {M. Allman and S. Ostermann},
title = {{FTP Security Considerations}},
pagetotal = 8,
year = 1999,
month = may,
} RFC text
Contents
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.
Abstract
The 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.
1 Introduction
The File Transfer Protocol specification (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.
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
may allow 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]). 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.
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 established with a trusted host and the data connection
is not. Likewise, the client should verify the IP address of the
remote host after accepting a connection on a port opened in listen
mode to verify that the connection was made by the expected server.
Note that restricting access based on network address leaves the FTP
server vulnerable 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 are
not 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. 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]).
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].
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. 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.
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 allocated by the server and "guess" the next one
that will be used. The attacker can make a connection to this port,
thus denying another legitimate client the ability to make a
transfer. Alternatively, the attacker can steal a file meant for a
legitimate user. In addition, an attacker can insert a forged file
into a data stream 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 using system dependent
mechanisms.
9 Software-Base Security Problems
The emphasis in this document is on protocol-related security issues.
There are a number of documented FTP security-related problems that
are due to poor implementation as well. Although the details of
these types of problems are beyond the scope of this document, it
should be pointed out that the following FTP features has been abused
in the past and should be treated with great care by future
implementers:
Anonymous FTP
Anonymous FTP refers to the ability of a client to connect to an
FTP server with minimal authentication and gain access to public
files. Security problems arise when such a user can read all
files on the system or can create files. [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.
10 Conclusion
Using the above suggestions can decrease the security problems
associated with FTP servers without eliminating functionality.
11 Security Considerations
Security issues are discussed throughout this memo.
Acknowledgments
We would like to thank Alex Belits, Jim Bound, William Curtin, Robert
Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their helpful
comments on this paper. Also, we thank the FTPEXT WG members who
gave many useful suggestions at the Memphis IETF meeting.
References
[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.
AI ELI5
On this page
§1Why FTP Needs Security Advice
The File Transfer Protocol (RFC 959) lets a client open a control connection and have one FTP server transfer a file directly to another server. This proxy FTP saves network traffic, which is handy when the client sits behind a slow link such as a modem.
The same feature allows a bounce attack, and FTP servers can also be used to guess passwords by brute force. RFC 2577 gives advice to FTP server implementers and system administrators. It does not cover FTP combined with strong security protocols such as IP Security.
FTP can ask one computer to send a file to another. That is useful, but a bad person can misuse it, so the authors wrote down ways to stop that.
§2The Bounce Attack
The attacker sends an FTP PORT command that names the address and port number of the machine and service to be attacked. The attacker then tells the FTP server to send a file to that service. The file can hold commands for the target service, such as SMTP or NNTP.
Because the FTP server makes the connection, the real attacker is hard to track down, and network-address-based access restrictions can be circumvented. The RFC's example: upload a file of SMTP commands, point the server at a third machine's SMTP port with PORT, then order the transfer. That can forge mail without a direct connection.
It is like asking a friendly delivery person to hand a rude note to someone else, so nobody can tell the note came from you.
- Upload file of commandsFor example, SMTP commands.
- PORT target-address,portNames the service to attack.
- Transfer the file
- Connects and sends fileThe target sees the FTP server, not the attacker.
§3Defending Against the Bounce Attack
FTP puts no limit on the TCP port used for a data connection, while ports 0 to 1023 are reserved for well known services. The RFC therefore suggests that servers not open data connections to TCP ports below 1024. A PORT command naming such a port should get reply 504, "Command not implemented for that parameter". Servers on ports above 1023 stay exposed.
Other precautions: protect uploaded files with proper file protections, since the attack usually needs an upload followed by a download, and take similar care if data connections use a protocol other than TCP. Disabling PORT is also an option, because most transfers can use PASV alone. The cost is losing proxy FTP.
The fix is a rule: do not deliver to the busiest, most important doors. If you never need to deliver for others, you can turn the service off.
§4Protecting Passwords and Usernames
To limit brute force guessing, servers should close the control connection after a small number of attempts (3 to 5), and must send reply 421 first. The RFC also suggests a 5 second delay before replying to an invalid PASS command. An intruder can open several parallel control connections, but limiting connections or refusing a suspicious site opens the door to denial of service against valid users.
Standard FTP sends passwords in clear text, so clients and servers should use authentication mechanisms that resist eavesdropping, such as those in RFC 2228. To stop attackers learning valid usernames, a server should always answer USER with 331 and reject the username and password pair later, instead of answering 530 for unknown names.
If someone keeps trying keys on your lock, make them stop after a few tries and wait a bit. Also, never tell them which names are real.
§5Address Checks and Port Stealing
A server that limits access by network address should check the remote address on both the control connection and the data connection. Otherwise a trusted host could open the control connection while a different host receives the data. Clients should likewise verify the address of whoever connects to a port they opened in listen mode. Address checks still allow spoof attacks, so secure authentication should be used when possible.
Port stealing works because many operating systems hand out dynamic ports in increasing order. An attacker makes a legitimate transfer, guesses the next port, and connects to it. That can block another client, steal a file, or insert a forged file. The mitigation is to use random local port numbers for data connections.
If tickets are handed out in order, a sneaky person can guess the next number and cut in line. Handing out random numbers makes that guessing hard.
§6Privacy and Software Bugs
Standard FTP sends all data and control information, including passwords, unencrypted. The RFC says a strong encryption scheme should be used whenever possible, and points to RFC 2228 for one.
Many documented FTP problems come from poor implementation rather than protocol design. The RFC names three features abused in the past: anonymous FTP that lets users read all files or create files, the optional SITE EXEC command that runs arbitrary commands on the server, and software installed with debugging features enabled. Implementers are told to review the relevant CERT advisories before release.
Plain FTP talks out loud where anyone can listen, so secret talk should be put in a code. Some features, like letting visitors run commands, need extra careful handling.