[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
 
 discussions
- read forum
- new topic
- search
 

 meetings
- meetings list
- recent additions
- add your info
 
 top 100 sites
- visit top sites
- sign up now
- members
 
 webmasters

- add your url
- add domain
- search box
- link to us

 
 projects
- our projects
- free email
 
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : Anonymous FTP Activity

Title: Anonymous FTP Activity
Released by: CERT
Date: 14th June 1993
Printable version: Click here
-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1



===========================================================================

CA-93:10                        CERT Advisory

                                July 14, 1993

                            Anonymous FTP Activity



Last revised: October 8, 1997

              Attached copyright statement

- ---------------------------------------------------------------------------



The CERT Coordination Center has been receiving a continuous stream of

reports from sites that are experiencing unwanted activities within their

anonymous FTP areas.  We recognize that this is not a new problem, and we

have been striving to handle requests for assistance on a one-to-one basis

with the reporting administrator. However, since this activity does not seem

to be diminishing, CERT believes that a broad distribution of information

concerning this problem and corresponding solution suggestions should help

to address the widespread nature of this activity.



We are seeing three types of activity regarding anonymous FTP areas.



   A. Improper configurations leading to system compromise.



   B. Excessive transfer of data causing deliberate over-filling of

      disk space thus leading to denial of service.



   C. Use of writable areas to transfer copyrighted software and other

      sensitive information.



This advisory provides an updated version of the anonymous FTP configuration

guidelines that is available from CERT.  The purpose of these guidelines is

to assist system administrators at sites that offer anonymous FTP services.

These guidelines are intended to aid a system administrator in configuring

anonymous FTP capabilities so as to minimize unintended use of services or

resources.  Systems administrators should be aware that anonymous FTP

capabilities should be configured and managed according to the policies

established for their site.



You may obtain future copies of these guidelines through anonymous FTP from

cert.org in /pub/tech_tips/anonymous_ftp.



- ---------------------------------------------------------------------------





                ANONYMOUS FTP CONFIGURATION GUIDELINES



Anonymous FTP can be a valuable service if correctly configured and

administered. The first section of this document provides general guidance in

initial configuration of an anonymous FTP area.  The second section addresses

the issues and challenges involved when a site wants to provide writable

directories within their anonymous FTP areas. The third section provides

information about previous CERT advisories related to FTP services.



The following guidelines are a set of suggested recommendations that have been

beneficial to many sites. CERT recognizes that there will be sites that have

unique requirements and needs, and that these sites may choose to implement

different configurations.



I.  Configuring anonymous FTP



    A. FTP daemon



       Sites should ensure that they are using the most recent version

       of their FTP daemon.



    B. Setting up the anonymous FTP directories



       The anonymous FTP root directory (~ftp) and its subdirectories

       should not be owned by the ftp account or be in the same group as

       the ftp account.  This is a common configuration problem.  If any of

       these directories are owned by ftp or are in the same group as the

       ftp account and are not write protected, an intruder will be able to

       add files (such as a .rhosts file) or modify other files.  Many sites

       find it acceptable to use the root account.  Making the ftp root

       directory and its subdirectories owned by root, part of the system

       group, and protected so that only root has write permission will help

       to keep your anonymous FTP service secure.



       Here is an example of an anonymous FTP directory setup:



           drwxr-xr-x  7   root    system  512 Mar 1       15:17 ./

           drwxr-xr-x 25   root    system  512 Jan 4       11:30 ../

           drwxr-xr-x  2   root    system  512 Dec 20      15:43 bin/

           drwxr-xr-x  2   root    system  512 Mar 12      16:23 etc/

           drwxr-xr-x 10   root    system  512 Jun 5       10:54 pub/



       Files and libraries, especially those used by the FTP daemon and

       those in ~ftp/bin and ~ftp/etc, should have the same protections

       as these directories.  They should not be owned by ftp or be in the

       same group as the ftp account; and they should be write protected.



    C. Using proper password and group files



       We strongly advise that sites not use the system's /etc/passwd file as

       the password file or the system's /etc/group as the group file in the

       ~ftp/etc directory.  Placing these system files in the ~ftp/etc

       directory will permit intruders to get a copy of these files.

       These files are optional and are not used for access control.



       We recommend that you use a dummy version of both the ~ftp/etc/passwd

       and ~ftp/etc/group files. These files should be owned by root. The

       dir command uses these dummy versions to show owner and group

       names of the files and directories instead of displaying arbitrary

       numbers.



       Sites should make sure that the ~/ftp/etc/passwd file contains no

       account names that are the same as those in the system's /etc/passwd

       file.  These files should include only those entries that are relevant

       to the FTP hierarchy or needed to show owner and group names. In

       addition, ensure that the password field has been cleared.  The

       examples below show the use of asterisks (*) to clear the password

       field.



       Below is an example of a passwd file from the anonymous FTP area on

       cert.org:



           ssphwg:*:3144:20:Site Specific Policy Handbook Working Group::

           cops:*:3271:20:COPS Distribution::

           cert:*:9920:20:CERT::

           tools:*:9921:20:CERT Tools::

           ftp:*:9922:90:Anonymous FTP::

           nist:*:9923:90:NIST Files::



       Here is an example group file from the anonymous FTP area on cert.org:



           cert:*:20:

           ftp:*:90:





II. Providing writable directories in your anonymous FTP configuration



    There is a risk to operating an anonymous FTP service that permits

    users to store files.  CERT strongly recommends that sites do not

    automatically create a "drop off" directory unless thought has been

    given to the possible risks of having such a service.  CERT has received

    many reports where these directories have been used as "drop off"

    directories to distribute bootlegged versions of copyrighted software or

    to trade information on compromised accounts and password files.  CERT

    has also received numerous reports of files systems being maliciously

    filled causing denial of service problems.



    This section discusses three ways to address these problems. The first is

    to use a modified FTP daemon. The second method is to provide restricted

    write capability through the use of special directories. The third method

    involves the use of a separate directory.



    A. Modified FTP daemon



       If your site is planning to offer a "drop off" service, CERT suggests

       using a modified FTP daemon that will control access to the "drop off"

       directory.  This is the best way to prevent unwanted use of writable

       areas. Some suggested modifications are:



       1. Implement a policy where any file dropped off cannot

          be accessed until the system manager examines the file

          and moves it to a public directory.

       2. Limit the amount of data transferred in one session.

       3. Limit the overall amount of data transferred based on

          available disk space.

       4. Increase logging to enable earlier detection of abuses.



       For those interested in modifying the FTP daemon, source code is

       usually available from your vendor. Public domain sources are

       available from:



          wuarchive.wustl.edu   ~ftp/packages/wuarchive-ftpd

          ftp.uu.net            ~ftp/systems/unix/bsd-sources/libexec/ftpd

          gatekeeper.dec.com    ~ftp/pub/DEC/gwtools/ftpd.tar.Z



       The CERT Coordination Center has not formally reviewed, evaluated,

       or endorsed the FTP daemons described.  The decision to use the FTP

       daemons described is the responsibility of each user or organization,

       and we encourage each organization to thoroughly evaluate these

       programs before installation or use.



    B. Using protected directories



       If your site is planning to offer a "drop off" service and is unable

       to modify the FTP daemon, it is possible to control access by using a

       maze of protected directories.  This method requires prior coordination

       and cannot guarantee protection from unwanted use of the writable FTP

       area, but has been used effectively by many sites.



       Protect the top level directory (~ftp/incoming) giving only execute

       permission to the anonymous user (chmod 751 ~ftp/incoming).  This will

       permit the anonymous user to change directory (cd), but will not allow

       the user to view the contents of the directory.



           drwxr-x--x  4   root    system  512 Jun 11      13:29 incoming/



       Create subdirectories in the ~ftp/incoming using names known only

       between your local users and the anonymous users that you want to

       have "drop off" permission.  The same care used in selecting passwords

       should be taken in selecting these subdirectory names because the

       object is to choose names that cannot be easily guessed.  Please do not

       use our example directory names of jAjwUth2 and MhaLL-iF.



           drwxr-x-wx 10   root    system  512 Jun 11      13:54 jAjwUth2/

           drwxr-x-wx 10   root    system  512 Jun 11      13:54 MhaLL-iF/



       This will prevent the casual anonymous FTP user from writing files in

       your anonymous FTP file system.  It is important to realize that this

       method does not protect a site against the result of intentional or

       accidental disclosure of the directory names.  Once a directory name

       becomes public knowledge, this method provides no protection at all

       from unwanted use of the area.  Should a name become public, a site

       may choose to either remove or rename the writable directory.



    C. Using a single disk drive



       If your site is planning to offer a "drop off" service and is

       unable to modify the FTP daemon, it may be desirable to limit

       the amount of data transferred to a single file system mounted

       as ~ftp/incoming.



       If possible, dedicate a disk drive and mount it as ~ftp/incoming.

       If this dedicated disk becomes full, it will not cause a denial

       of service problem.



       The system administrator should monitor this directory (~ftp/incoming)

       on a continuing basis to ensure that it is not being misused.





III. Related CERT Advisories



    The following CERT Advisories directly relate to FTP daemons or impact

    on providing FTP service:



        CA-93:06.wuarchive.ftpd.vulnerability

        CA-92:09.AIX.anonymous.ftp.vulnerability

        CA-88:01.ftpd.hole



    Past advisories are available for anonymous FTP from cert.org.





- ---------------------------------------------------------------------------





If you believe that your system has been compromised, contact the CERT

Coordination Center or your representative in FIRST (Forum of Incident

Response and Security Teams).



Internet E-mail: cert@cert.org

Telephone: 412-268-7090 (24-hour hotline)

           CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4),

           and are on call for emergencies during other hours.



CERT Coordination Center

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213-3890



Past advisories, information about FIRST representatives, and other information

related to computer security are available for anonymous FTP from cert.org

(192.88.209.5).



Copyright 1993 Carnegie Mellon University. Conditions for use, disclaimers,

and sponsorship information can be found in

http://www.cert.org/legal_stuff.html and http://info.cert.org/pub/legal_stuff .

If you do not have FTP or web access, send mail to cert@cert.org with

"copyright" in the subject line.



CERT is registered in the U.S. Patent and Trademark Office.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Revision History



October 8, 1997  Attached copyright statement



-----BEGIN PGP SIGNATURE-----

Version: PGP for Personal Privacy 5.0

Charset: noconv



iQA/AwUBOBS/JFr9kb5qlZHQEQIbZwCg/RyXtxXaoPjObDXA6b/lyI22M4QAoLP6

rrphPBNRw9wigB2cMTLUw5nz

=n1pN

-----END PGP SIGNATURE-----








(C) 1999-2000 All rights reserved.