draft-ietf-ftpext-sec-consider-02.txt

这是 关于FTP最新版本的PROFTP的 源码

    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
    

Expires: April, 1999                                            [Page 4]

draft-ietf-ftpext-sec-consider-02.txt                       October 1998

    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 legimate client the ability to make a
    transfer.  Alternativly, 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.


Expires: April, 1999                                            [Page 5]

draft-ietf-ftpext-sec-consider-02.txt                       October 1998

10  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

    [AOM98] Mark Allman, Shawn Ostermann, Craig Metz.  FTP Extensions
        for IPv6 and NATs, September 1998.  RFC 2428.

    [Bel94] Steve Bellovin.  Firewall-Friendly FTP, February 1994.  RFC
        1579.

    [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] 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.  http://www.iana.org.

Expires: April, 1999                                            [Page 6]

draft-ietf-ftpext-sec-consider-02.txt                       October 1998


Author's Addresses:
    
    Mark Allman
    NASA Lewis Research Center/Sterling Software
    21000 Brookpark Rd.  MS 54-2
    Cleveland, OH  44135
    [e-mail]

    Shawn Ostermann
    School of Electrical Engineering and Computer Science
    Ohio University    
    416 Morton Hall
    Athens, OH  45701
    [e-mail]








































Expires: April, 1999                                            [Page 7]