FTPEXT Working Group                                         Mark Allman
Internet Draft                              NASA Lewis/Sterling Software
Expires: July 14, 1998                                   Shawn Ostermann
                                                         Ohio University
                                                        January 14, 1998


                      FTP Security Considerations
                <draft-ietf-ftpext-sec-consider-00.txt>


Status of this Memo

    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its areas,
    and its working groups.  Note that other groups may also distribute
    working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as ``work in
    progress.''

    To learn the current status of any Internet-Draft, please check the
    ``1id-abstracts.txt'' listing contained in the Internet- Drafts
    Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
    ftp.isi.edu (US West Coast).

    Distribution of this document is unlimited.  Please send comments
    to the FTP Extension working group (FTPEXT-WG) of the Internet
    Engineering Task Force (IETF) at <ftp-wg@hethmon.com>.
    Subscription address is <ftp-wg-request@hethmon.com>.
    Discussions of the group are archived at
    <URL:http://w3.hethmon.com/ftpext/>.

Abstract

    The specification for the File Transfer Protocol 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.

   Introduction

    The File Transfer Protocol specification [PR85] provides a mechanism
    that allows a client to establish a data connection and transfer a
    file between two FTP servers.  This "proxy FTP" mechanism can be

Allman and Ostermann                                            [Page 1]

INTERNET-DRAFT       FTP Security Considerations        January 14, 1998

    used to decrease the amount of traffic on the network; the client
    instructs one server to transfer a file to another server, rather
    than transfering 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".  In addition to the bounce
    attack, FTP servers can be used by attackers to guess passwords
    using brute force.

    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.  Finally, section 7 provides a mechanism to
    prevent user identity guessing.

   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
    allows the client to forge mail on the third machine without making
    a direct connection.  This makes it difficult to track attackers.

   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.


Allman and Ostermann                                            [Page 2]

INTERNET-DRAFT       FTP Security Considerations        January 14, 1998

    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., [AO97] 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.

   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].

   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.



Allman and Ostermann                                            [Page 3]

INTERNET-DRAFT       FTP Security Considerations        January 14, 1998

    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]).

   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].

   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.

   Conclusion

    Using the above suggestions can decrease the security problems
    associated with FTP servers without eliminating functionality.

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

    [AO97] Mark Allman and Shawn Ostermann.  FTP Extensions for Variable
        Protocol Specification, January 1998.  I-D
        draft-ietf-ftpext-ftp-over-ipv6-00.txt (work in progress).




Allman and Ostermann                                            [Page 4]

INTERNET-DRAFT       FTP Security Considerations        January 14, 1998

    [HL97] M. Horowitz and S. J. Lunt.  FTP Security Extensions,
        October 1997.  RFC 2228.

    [Pis94] D. Piscitello.  FTP Operation Over Big Address Records
        (FOOBAR), June 1994.  RFC 1639.

    [Pos81] J. Postel.  Transmission Control Protocol, September 1981.
        RFC 793.

    [PR85] J. Postel and J. Reynolds.  File Transfer Protocol (FTP),
        October 1985.  RFC 959.

    [RP94] J. Reynolds and J. Postel.  Assigned Numbers, October 1994.
        RFC 1700.

Author's Addresses:

    Mark Allman
    NASA Lewis Research Center/Sterling Software
    21000 Brookpark Rd.  MS 54-2
    Cleveland, OH  44135
    mallman@lerc.nasa.gov

    Shawn Ostermann
    School of Electrical Engineering and Computer Science
    Ohio University
    416 Morton Hall
    Athens, OH  45701
    ostermann@cs.ohiou.edu


























Allman and Ostermann                                            [Page 5]