7
Network Working Group M. Allman
8
Request for Comments: 2577 NASA Glenn/Sterling Software
9
Category: Informational S. Ostermann
14
FTP Security Considerations
18
This memo provides information for the Internet community. It does
19
not specify an Internet standard of any kind. Distribution of this
24
Copyright (C) The Internet Society (1999). All Rights Reserved.
28
The specification for the File Transfer Protocol (FTP) contains a
29
number of mechanisms that can be used to compromise network security.
30
The FTP specification allows a client to instruct a server to
31
transfer files to a third machine. This third-party mechanism, known
32
as proxy FTP, causes a well known security problem. The FTP
33
specification also allows an unlimited number of attempts at entering
34
a user's password. This allows brute force "password guessing"
35
attacks. This document provides suggestions for system
36
administrators and those implementing FTP servers that will decrease
37
the security problems associated with FTP.
41
The File Transfer Protocol specification (FTP) [PR85] provides a
42
mechanism that allows a client to establish an FTP control connection
43
and transfer a file between two FTP servers. This "proxy FTP"
44
mechanism can be used to decrease the amount of traffic on the
45
network; the client instructs one server to transfer a file to
46
another server, rather than transferring the file from the first
47
server to the client and then from the client to the second server.
48
This is particularly useful when the client connects to the network
49
using a slow link (e.g., a modem). While useful, proxy FTP provides
50
a security problem known as a "bounce attack" [CERT97:27]. In
51
addition to the bounce attack, FTP servers can be used by attackers
52
to guess passwords using brute force.
58
Allman & Ostermann Informational [Page 1]
60
RFC 2577 FTP Security Considerations May 1999
63
This document does not contain a discussion of FTP when used in
64
conjunction with strong security protocols, such as IP Security.
65
These security concerns should be documented, however they are out of
66
the scope of this document.
68
This paper provides information for FTP server implementers and
69
system administrators, as follows. Section 2 describes the FTP
70
"bounce attack". Section 3 provides suggestions for minimizing the
71
bounce attack. Section 4 provides suggestions for servers which
72
limit access based on network address. Section 5 provides
73
recommendations for limiting brute force "password guessing" by
74
clients. Next, section 6 provides a brief discussion of mechanisms
75
to improve privacy. Section 7 provides a mechanism to prevent user
76
identity guessing. Section 8 discusses the practice of port
77
stealing. Finally, section 9 provides an overview of other FTP
78
security issues related to software bugs rather than protocol issues.
82
The version of FTP specified in the standard [PR85] provides a method
83
for attacking well known network servers, while making the
84
perpetrators difficult to track down. The attack involves sending an
85
FTP "PORT" command to an FTP server containing the network address
86
and the port number of the machine and service being attacked. At
87
this point, the original client can instruct the FTP server to send a
88
file to the service being attacked. Such a file would contain
89
commands relevant to the service being attacked (SMTP, NNTP, etc.).
90
Instructing a third party to connect to the service, rather than
91
connecting directly, makes tracking down the perpetrator difficult
92
and can circumvent network-address-based access restrictions.
94
As an example, a client uploads a file containing SMTP commands to an
95
FTP server. Then, using an appropriate PORT command, the client
96
instructs the server to open a connection to a third machine's SMTP
97
port. Finally, the client instructs the server to transfer the
98
uploaded file containing SMTP commands to the third machine. This
99
may allow the client to forge mail on the third machine without
100
making a direct connection. This makes it difficult to track
103
3 Protecting Against the Bounce Attack
105
The original FTP specification [PR85] assumes that data connections
106
will be made using the Transmission Control Protocol (TCP) [Pos81].
107
TCP port numbers in the range 0 - 1023 are reserved for well known
108
services such as mail, network news and FTP control connections
109
[RP94]. The FTP specification makes no restrictions on the TCP port
110
number used for the data connection. Therefore, using proxy FTP,
114
Allman & Ostermann Informational [Page 2]
116
RFC 2577 FTP Security Considerations May 1999
119
clients have the ability to tell the server to attack a well known
120
service on any machine.
122
To avoid such bounce attacks, it is suggested that servers not open
123
data connections to TCP ports less than 1024. If a server receives a
124
PORT command containing a TCP port number less than 1024, the
125
suggested response is 504 (defined as "Command not implemented for
126
that parameter" by [PR85]). Note that this still leaves non-well
127
known servers (those running on ports greater than 1023) vulnerable
130
Several proposals (e.g., [AOM98] and [Pis94]) provide a mechanism
131
that would allow data connections to be made using a transport
132
protocol other than TCP. Similar precautions should be taken to
133
protect well known services when using these protocols.
135
Also note that the bounce attack generally requires that a
136
perpetrator be able to upload a file to an FTP server and later
137
download it to the service being attacked. Using proper file
138
protections will prevent this behavior. However, attackers can also
139
attack services by sending random data from a remote FTP server which
140
may cause problems for some services.
142
Disabling the PORT command is also an option for protecting against
143
the bounce attack. Most file transfers can be made using only the
144
PASV command [Bel94]. The disadvantage of disabling the PORT command
145
is that one loses the ability to use proxy FTP, but proxy FTP may not
146
be necessary in a particular environment.
150
For some FTP servers, it is desirable to restrict access based on
151
network address. For example, a server might want to restrict access
152
to certain files from certain places (e.g., a certain file should not
153
be transferred out of an organization). In such a situation, the
154
server should confirm that the network address of the remote hosts on
155
both the control connection and the data connection are within the
156
organization before sending a restricted file. By checking both
157
connections, a server is protected against the case when the control
158
connection is established with a trusted host and the data connection
159
is not. Likewise, the client should verify the IP address of the
160
remote host after accepting a connection on a port opened in listen
161
mode to verify that the connection was made by the expected server.
163
Note that restricting access based on network address leaves the FTP
164
server vulnerable to "spoof" attacks. In a spoof attack, for
165
example, an attacking machine could assume the host address of
166
another machine inside an organization and download files that are
170
Allman & Ostermann Informational [Page 3]
172
RFC 2577 FTP Security Considerations May 1999
175
not accessible from outside the organization. Whenever possible,
176
secure authentication mechanisms should be used, such as those
179
5 Protecting Passwords
181
To minimize the risk of brute force password guessing through the FTP
182
server, it is suggested that servers limit the number of attempts
183
that can be made at sending a correct password. After a small number
184
of attempts (3-5), the server should close the control connection
185
with the client. Before closing the control connection the server
186
must send a return code of 421 ("Service not available, closing
187
control connection." [PR85]) to the client. In addition, it is
188
suggested that the server impose a 5 second delay before replying to
189
an invalid "PASS" command to diminish the efficiency of a brute force
190
attack. If available, mechanisms already provided by the target
191
operating system should be used to implement the above suggestions.
193
An intruder can subvert the above mechanisms by establishing
194
multiple, parallel control connections to a server. To combat the
195
use of multiple concurrent connections, the server could either limit
196
the total number of control connections possible or attempt to detect
197
suspicious activity across sessions and refuse further connections
198
from the site. However, both of these mechanisms open the door to
199
"denial of service" attacks, in which an attacker purposely initiates
200
the attack to disable access by a valid user.
202
Standard FTP [PR85] sends passwords in clear text using the "PASS"
203
command. It is suggested that FTP clients and servers use alternate
204
authentication mechanisms that are not subject to eavesdropping (such
205
as the mechanisms being developed by the IETF Common Authentication
206
Technology Working Group [HL97]).
210
All data and control information (including passwords) is sent across
211
the network in unencrypted form by standard FTP [PR85]. To guarantee
212
the privacy of the information FTP transmits, a strong encryption
213
scheme should be used whenever possible. One such mechanism is
216
7 Protecting Usernames
218
Standard FTP [PR85] specifies a 530 response to the USER command when
219
the username is rejected. If the username is valid and a password is
220
required FTP returns a 331 response instead. In order to prevent a
221
malicious client from determining valid usernames on a server, it is
222
suggested that a server always return 331 to the USER command and
226
Allman & Ostermann Informational [Page 4]
228
RFC 2577 FTP Security Considerations May 1999
231
then reject the combination of username and password for an invalid
236
Many operating systems assign dynamic port numbers in increasing
237
order. By making a legitimate transfer, an attacker can observe the
238
current port number allocated by the server and "guess" the next one
239
that will be used. The attacker can make a connection to this port,
240
thus denying another legitimate client the ability to make a
241
transfer. Alternatively, the attacker can steal a file meant for a
242
legitimate user. In addition, an attacker can insert a forged file
243
into a data stream thought to come from an authenticated client.
244
This problem can be mitigated by making FTP clients and servers use
245
random local port numbers for data connections, either by requesting
246
random ports from the operating system or using system dependent
249
9 Software-Base Security Problems
251
The emphasis in this document is on protocol-related security issues.
252
There are a number of documented FTP security-related problems that
253
are due to poor implementation as well. Although the details of
254
these types of problems are beyond the scope of this document, it
255
should be pointed out that the following FTP features has been abused
256
in the past and should be treated with great care by future
261
Anonymous FTP refers to the ability of a client to connect to an
262
FTP server with minimal authentication and gain access to public
263
files. Security problems arise when such a user can read all
264
files on the system or can create files. [CERT92:09] [CERT93:06]
266
Remote Command Execution
268
An optional FTP extension, "SITE EXEC", allows clients to execute
269
arbitrary commands on the server. This feature should obviously
270
be implemented with great care. There are several documented
271
cases of the FTP "SITE EXEC" command being used to subvert server
272
security [CERT94:08] [CERT95:16]
276
Several previous security compromises related to FTP can be
277
attributed to software that was installed with debugging features
282
Allman & Ostermann Informational [Page 5]
284
RFC 2577 FTP Security Considerations May 1999
287
This document recommends that implementors of FTP servers with these
288
capabilities review all of the CERT advisories for attacks on these
289
or similar mechanisms before releasing their software.
293
Using the above suggestions can decrease the security problems
294
associated with FTP servers without eliminating functionality.
296
11 Security Considerations
298
Security issues are discussed throughout this memo.
302
We would like to thank Alex Belits, Jim Bound, William Curtin, Robert
303
Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their helpful
304
comments on this paper. Also, we thank the FTPEXT WG members who
305
gave many useful suggestions at the Memphis IETF meeting.
309
[AOM98] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions
310
for IPv6 and NATs", RFC 2428, September 1998.
312
[Bel94] Bellovin. S., "Firewall-Friendly FTP", RFC 1579, February
315
[CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December,
316
1988 ftp://info.cert.org/pub/cert_advisories/
318
[CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability.
319
April 27, 1992. ftp://info.cert.org/pub/cert_advisories/
321
[CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability.
323
ftp://info.cert.org/pub/cert_advisories/
325
[CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September
326
23, 1997. ftp://info.cert.org/pub/cert_advisories/
328
[CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration
329
Vulnerability. September 23, 1997
330
ftp://info.cert.org/pub/cert_advisories/
332
[CERT97:27] CERT Advisory CA-97.27. FTP Bounce. January 8, 1998.
333
ftp://info.cert.org/pub/cert_advisories/
338
Allman & Ostermann Informational [Page 6]
340
RFC 2577 FTP Security Considerations May 1999
343
[HL97] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
346
[Pis94] Piscitello, D., "FTP Operation Over Big Address Records
347
(FOOBAR), RFC 1639, June 1994.
349
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
352
[PR85] Postel, J. and J. Reynolds, "File Transfer Protocol
353
(FTP)", STD 9, RFC 959, October 1985.
355
[RP94] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
356
RFC 1700, October 1994. See also:
357
http://www.iana.org/numbers.html
362
NASA Glenn Research Center/Sterling Software
363
21000 Brookpark Rd. MS 54-2
366
EMail: mallman@grc.nasa.gov
370
School of Electrical Engineering and Computer Science
375
EMail: ostermann@cs.ohiou.edu
394
Allman & Ostermann Informational [Page 7]
396
RFC 2577 FTP Security Considerations May 1999
399
Full Copyright Statement
401
Copyright (C) The Internet Society (1999). All Rights Reserved.
403
This document and translations of it may be copied and furnished to
404
others, and derivative works that comment on or otherwise explain it
405
or assist in its implementation may be prepared, copied, published
406
and distributed, in whole or in part, without restriction of any
407
kind, provided that the above copyright notice and this paragraph are
408
included on all such copies and derivative works. However, this
409
document itself may not be modified in any way, such as by removing
410
the copyright notice or references to the Internet Society or other
411
Internet organizations, except as needed for the purpose of
412
developing Internet standards in which case the procedures for
413
copyrights defined in the Internet Standards process must be
414
followed, or as required to translate it into languages other than
417
The limited permissions granted above are perpetual and will not be
418
revoked by the Internet Society or its successors or assigns.
420
This document and the information contained herein is provided on an
421
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
422
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
423
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
424
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
425
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
429
Funding for the RFC Editor function is currently provided by the
450
Allman & Ostermann Informational [Page 8]
added
removed
lib/inets/doc/archive/rfc2577.txt
