As per Relevance of the word provides, we have this rfc below:
Network Working Group M.
Request for Comments: 2577 NASA Glenn/Sterling
Category: Informational S.
Ohio
May 1999
FTP Security
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The specification for the File Transfer Protocol (FTP) contains
number of mechanisms that can be used to compromise network security
The FTP specification allows a client to instruct a server
transfer files to a third machine. This third-party mechanism,
as proxy FTP, causes a well known security problem. The
specification also allows an unlimited number of attempts at
a user's password. This allows brute force "password guessing
attacks. This document provides suggestions for
administrators and those implementing FTP servers that will
the security problems associated with FTP
1
The File Transfer Protocol specification (FTP) [PR85] provides
mechanism that allows a client to establish an FTP control
and transfer a file between two FTP servers. This "proxy FTP
mechanism can be used to decrease the amount of traffic on
network; the client instructs one server to transfer a file
another server, rather than transferring the file from the
server to the client and then from the client to the second server
This is particularly useful when the client connects to the
using a slow link (e.g., a modem). While useful, proxy FTP
a security problem known as a "bounce attack" [CERT97:27].
addition to the bounce attack, FTP servers can be used by
to guess passwords using brute force
Allman & Ostermann Informational [Page 1]
RFC 2577 FTP Security Considerations May 1999
This document does not contain a discussion of FTP when used
conjunction with strong security protocols, such as IP Security
These security concerns should be documented, however they are out
the scope of this document
This paper provides information for FTP server implementers
system administrators, as follows. Section 2 describes the
"bounce attack". Section 3 provides suggestions for minimizing
bounce attack. Section 4 provides suggestions for servers
limit access based on network address. Section 5
recommendations for limiting brute force "password guessing"
clients. Next, section 6 provides a brief discussion of
to improve privacy. Section 7 provides a mechanism to prevent
identity guessing. Section 8 discusses the practice of
stealing. Finally, section 9 provides an overview of other
security issues related to software bugs rather than protocol issues
2 The Bounce
The version of FTP specified in the standard [PR85] provides a
for attacking well known network servers, while making
perpetrators difficult to track down. The attack involves sending
FTP "PORT" command to an FTP server containing the network
and the port number of the machine and service being attacked.
this point, the original client can instruct the FTP server to send
file to the service being attacked. Such a file would
commands relevant to the service being attacked (SMTP, NNTP, etc.).
Instructing a third party to connect to the service, rather
connecting directly, makes tracking down the perpetrator
and can circumvent network-address-based access restrictions
As an example, a client uploads a file containing SMTP commands to
FTP server. Then, using an appropriate PORT command, the
instructs the server to open a connection to a third machine's
port. Finally, the client instructs the server to transfer
uploaded file containing SMTP commands to the third machine.
may allow the client to forge mail on the third machine
making a direct connection. This makes it difficult to
attackers
3 Protecting Against the Bounce
The original FTP specification [PR85] assumes that data
will be made using the Transmission Control Protocol (TCP) [Pos81].
TCP port numbers in the range 0 - 1023 are reserved for well
services such as mail, network news and FTP control
[RP94]. The FTP specification makes no restrictions on the TCP
number used for the data connection. Therefore, using proxy FTP
Allman & Ostermann Informational [Page 2]
RFC 2577 FTP Security Considerations May 1999
clients have the ability to tell the server to attack a well
service on any machine
To avoid such bounce attacks, it is suggested that servers not
data connections to TCP ports less than 1024. If a server receives
PORT command containing a TCP port number less than 1024,
suggested response is 504 (defined as "Command not implemented
that parameter" by [PR85]). Note that this still leaves non-
known servers (those running on ports greater than 1023)
to bounce attacks
Several proposals (e.g., [AOM98] and [Pis94]) provide a
that would allow data connections to be made using a
protocol other than TCP. Similar precautions should be taken
protect well known services when using these protocols
Also note that the bounce attack generally requires that
perpetrator be able to upload a file to an FTP server and
download it to the service being attacked. Using proper
protections will prevent this behavior. However, attackers can
attack services by sending random data from a remote FTP server
may cause problems for some services
Disabling the PORT command is also an option for protecting
the bounce attack. Most file transfers can be made using only
PASV command [Bel94]. The disadvantage of disabling the PORT
is that one loses the ability to use proxy FTP, but proxy FTP may
be necessary in a particular environment
4 Restricted
For some FTP servers, it is desirable to restrict access based
network address. For example, a server might want to restrict
to certain files from certain places (e.g., a certain file should
be transferred out of an organization). In such a situation,
server should confirm that the network address of the remote hosts
both the control connection and the data connection are within
organization before sending a restricted file. By checking
connections, a server is protected against the case when the
connection is established with a trusted host and the data
is not. Likewise, the client should verify the IP address of
remote host after accepting a connection on a port opened in
mode to verify that the connection was made by the expected server
Note that restricting access based on network address leaves the
server vulnerable to "spoof" attacks. In a spoof attack,
example, an attacking machine could assume the host address
another machine inside an organization and download files that
Allman & Ostermann Informational [Page 3]
RFC 2577 FTP Security Considerations May 1999
not accessible from outside the organization. Whenever possible
secure authentication mechanisms should be used, such as
outlined in [HL97].
5 Protecting
To minimize the risk of brute force password guessing through the
server, it is suggested that servers limit the number of
that can be made at sending a correct password. After a small
of attempts (3-5), the server should close the control
with the client. Before closing the control connection the
must send a return code of 421 ("Service not available,
control connection." [PR85]) to the client. In addition, it
suggested that the server impose a 5 second delay before replying
an invalid "PASS" command to diminish the efficiency of a brute
attack. If available, mechanisms already provided by the
operating system should be used to implement the above suggestions
An intruder can subvert the above mechanisms by
multiple, parallel control connections to a server. To combat
use of multiple concurrent connections, the server could either
the total number of control connections possible or attempt to
suspicious activity across sessions and refuse further
from the site. However, both of these mechanisms open the door
"denial of service" attacks, in which an attacker purposely
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
authentication mechanisms that are not subject to eavesdropping (
as the mechanisms being developed by the IETF Common
Technology Working Group [HL97]).
6
All data and control information (including passwords) is sent
the network in unencrypted form by standard FTP [PR85]. To
the privacy of the information FTP transmits, a strong
scheme should be used whenever possible. One such mechanism
defined in [HL97].
7 Protecting
Standard FTP [PR85] specifies a 530 response to the USER command
the username is rejected. If the username is valid and a password
required FTP returns a 331 response instead. In order to prevent
malicious client from determining valid usernames on a server, it
suggested that a server always return 331 to the USER command
Allman & Ostermann Informational [Page 4]
RFC 2577 FTP Security Considerations May 1999
then reject the combination of username and password for an
username
8 Port
Many operating systems assign dynamic port numbers in
order. By making a legitimate transfer, an attacker can observe
current port number allocated by the server and "guess" the next
that will be used. The attacker can make a connection to this port
thus denying another legitimate client the ability to make
transfer. Alternatively, the attacker can steal a file meant for
legitimate user. In addition, an attacker can insert a forged
into a data stream thought to come from an authenticated client
This problem can be mitigated by making FTP clients and servers
random local port numbers for data connections, either by
random ports from the operating system or using system
mechanisms
9 Software-Base Security
The emphasis in this document is on protocol-related security issues
There are a number of documented FTP security-related problems
are due to poor implementation as well. Although the details
these types of problems are beyond the scope of this document,
should be pointed out that the following FTP features has been
in the past and should be treated with great care by
implementers
Anonymous
Anonymous FTP refers to the ability of a client to connect to
FTP server with minimal authentication and gain access to
files. Security problems arise when such a user can read
files on the system or can create files. [CERT92:09] [CERT93:06]
Remote Command
An optional FTP extension, "SITE EXEC", allows clients to
arbitrary commands on the server. This feature should
be implemented with great care. There are several
cases of the FTP "SITE EXEC" command being used to subvert
security [CERT94:08] [CERT95:16]
Debug
Several previous security compromises related to FTP can
attributed to software that was installed with debugging
enabled [CERT88:01].
Allman & Ostermann Informational [Page 5]
RFC 2577 FTP Security Considerations May 1999
This document recommends that implementors of FTP servers with
capabilities review all of the CERT advisories for attacks on
or similar mechanisms before releasing their software
10
Using the above suggestions can decrease the security
associated with FTP servers without eliminating functionality
11 Security
Security issues are discussed throughout this memo
We would like to thank Alex Belits, Jim Bound, William Curtin,
Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their
comments on this paper. Also, we thank the FTPEXT WG members
gave many useful suggestions at the Memphis IETF meeting
[AOM98] Allman, M., Ostermann, S. and C. Metz, "FTP
for IPv6 and NATs", RFC 2428, September 1998.
[Bel94] Bellovin. S., "Firewall-Friendly FTP", RFC 1579,
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.
23, 1997. ftp://info.cert.org/pub/cert_advisories
[CERT95:16] CERT Advisory CA-95:16. wu-ftpd
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
Allman & Ostermann Informational [Page 6]
RFC 2577 FTP Security Considerations May 1999
[HL97] Horowitz, M. and S. Lunt, "FTP Security Extensions",
2228, October 1997.
[Pis94] Piscitello, D., "FTP Operation Over Big Address
(FOOBAR), RFC 1639, June 1994.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981.
[PR85] Postel, J. and J. Reynolds, "File Transfer
(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.
Authors'
Mark
NASA Glenn Research Center/Sterling
21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135
EMail: mallman@grc.nasa.
Shawn
School of Electrical Engineering and Computer
Ohio
416 Morton
Athens, OH 45701
EMail: ostermann@cs.ohiou.
Allman & Ostermann Informational [Page 7]
RFC 2577 FTP Security Considerations May 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Allman & Ostermann Informational [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
