home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2016 / linuxmafia.com.tar / linuxmafia.com / pub / linux / security / anonymous-ftp-config < prev    next >
PGP Signed Message  |  1997-10-06  |  10KB  |  213 lines
  1. -----BEGIN PGP SIGNED MESSAGE-----
  2.  
  3.         ANONYMOUS FTP CONFIGURATION GUIDELINES
  4.  
  5. Anonymous FTP can be a valuable service if correctly configured and
  6. administered. The first section of this document provides general guidance in
  7. initial configuration of an anonymous FTP area.  The second section addresses
  8. the issues and challenges involved when a site wants to provide writable
  9. directories within their anonymous FTP areas. The third section provides
  10. information about previous CERT advisories related to FTP services.
  11.  
  12. The following guidelines are a set of suggested recommendations that have been
  13. beneficial to many sites. We recognize that there will be sites that have
  14. unique requirements and needs, and that these sites may choose to implement
  15. different configurations.
  16.  
  17. I.  Configuring anonymous FTP
  18.  
  19.     A. FTP daemon
  20.  
  21.        Sites should ensure that they are using the most recent version
  22.        of their FTP daemon.
  23.  
  24.     B. Setting up the anonymous FTP directories
  25.  
  26.        The anonymous FTP root directory (~ftp) and its subdirectories 
  27.        should not be owned by the ftp account or be in the same group as
  28.        the ftp account.  This is a common configuration problem.  If any of 
  29.        these directories are owned by ftp or are in the same group as the 
  30.        ftp account and are not write protected, an intruder will be able to 
  31.        add files (such as a .rhosts file) or modify other files.  Many sites
  32.        find it acceptable to use the root account.  Making the ftp root 
  33.        directory and its subdirectories owned by root, part of the system 
  34.        group, and protected so that only root has write permission will help 
  35.        to keep your anonymous FTP service secure.
  36.  
  37.        Here is an example of an anonymous FTP directory setup:
  38.  
  39.            drwxr-xr-x  7   root    system  512 Mar 1       15:17 ./
  40.            drwxr-xr-x 25   root    system  512 Jan 4       11:30 ../
  41.            drwxr-xr-x  2   root    system  512 Dec 20      15:43 bin/
  42.            drwxr-xr-x  2   root    system  512 Mar 12      16:23 etc/
  43.            drwxr-xr-x 10   root    system  512 Jun 5       10:54 pub/
  44.  
  45.        Files and libraries, especially those used by the FTP daemon and
  46.        those in ~ftp/bin and ~ftp/etc, should have the same protections
  47.        as these directories.  They should not be owned by ftp or be in the 
  48.        same group as the ftp account; and they should be write protected.
  49.  
  50.     C. Using proper password and group files
  51.  
  52.        We strongly advise that sites not use the system's /etc/passwd file as 
  53.        the password file or the system's /etc/group as the group file in the 
  54.        ~ftp/etc directory.  Placing these system files in the ~ftp/etc 
  55.        directory will permit intruders to get a copy of these files. 
  56.        These files are optional and are not used for access control.
  57.  
  58.        We recommend that you use a dummy version of both the ~ftp/etc/passwd 
  59.        and ~ftp/etc/group files. These files should be owned by root. The
  60.        dir command uses these dummy versions to show owner and group
  61.        names of the files and directories instead of displaying arbitrary 
  62.        numbers.
  63.  
  64.        Sites should make sure that the ~/ftp/etc/passwd file contains no 
  65.        account names that are the same as those in the system's /etc/passwd 
  66.        file.  These files should include only those entries that are relevant 
  67.        to the FTP hierarchy or needed to show owner and group names. In 
  68.        addition, ensure that the password field has been cleared.  The 
  69.        examples below show the use of asterisks (*) to clear the password 
  70.        field.
  71.  
  72.        Below is an example of a passwd file from the anonymous FTP area on
  73.        cert.org:
  74.  
  75.            ssphwg:*:3144:20:Site Specific Policy Handbook Working Group::
  76.            cops:*:3271:20:COPS Distribution::
  77.            cert:*:9920:20:CERT::
  78.            tools:*:9921:20:CERT Tools::
  79.            ftp:*:9922:90:Anonymous FTP::
  80.            nist:*:9923:90:NIST Files::
  81.  
  82.        Here is an example group file from the anonymous FTP area on cert.org:
  83.  
  84.            cert:*:20:
  85.            ftp:*:90:
  86.  
  87.  
  88. II. Providing writable directories in your anonymous FTP configuration
  89.  
  90.     There is a risk to operating an anonymous FTP service that permits 
  91.     users to store files. We strongly recommend that sites do not 
  92.     automatically create a "drop off" directory unless thought has been 
  93.     given to the possible risks of having such a service. The CERT incident
  94.     response staff has received many reports where these directories have been
  95.     used as "drop off" directories to distribute bootlegged versions of
  96.     copyrighted software or to trade information on compromised accounts and
  97.     password files. The CERT staff has also received reports of file systems
  98.     being maliciously filled causing denial of service problems.  
  99.  
  100.     This section discusses three ways to address these problems. The first is 
  101.     to use a modified FTP daemon. The second method is to provide restricted 
  102.     write capability through the use of special directories. The third method
  103.     involves the use of a separate directory.
  104.  
  105.     A. Modified FTP daemon
  106.  
  107.        If your site is planning to offer a "drop off" service, we suggest
  108.        using a modified FTP daemon that will control access to the "drop off" 
  109.        directory.  This is the best way to prevent unwanted use of writable
  110.        areas. Some suggested modifications are:
  111.  
  112.        1. Implement a policy where any file dropped off cannot 
  113.           be accessed until the system manager examines the file 
  114.           and moves it to a public directory.
  115.        2. Limit the amount of data transferred in one session.
  116.        3. Limit the overall amount of data transferred based on 
  117.           available disk space.
  118.        4. Increase logging to enable earlier detection of abuses.
  119.  
  120.        For those interested in modifying the FTP daemon, source code is 
  121.        usually available from your vendor. Public domain sources are 
  122.        available from:
  123.  
  124.           wuarchive.wustl.edu   ~ftp/packages/wuarchive-ftpd
  125.           ftp.uu.net            ~ftp/systems/unix/bsd-sources/libexec/ftpd
  126.           gatekeeper.dec.com    ~ftp/pub/DEC/gwtools/ftpd.tar.Z
  127.  
  128.        The CERT Coordination Center has not formally reviewed, evaluated, 
  129.        or endorsed the FTP daemons described.  The decision to use the FTP 
  130.        daemons described is the responsibility of each user or organization, 
  131.        and we encourage each organization to thoroughly evaluate these 
  132.        programs before installation or use. 
  133.  
  134.     B. Using protected directories
  135.  
  136.        If your site is planning to offer a "drop off" service and is unable 
  137.        to modify the FTP daemon, it is possible to control access by using a 
  138.        maze of protected directories.  This method requires prior coordination
  139.        and cannot guarantee protection from unwanted use of the writable FTP 
  140.        area, but has been used effectively by many sites.
  141.  
  142.        Protect the top level directory (~ftp/incoming) giving only execute 
  143.        permission to the anonymous user (chmod 751 ~ftp/incoming).  This will 
  144.        permit the anonymous user to change directory (cd), but will not allow 
  145.        the user to view the contents of the directory.
  146.  
  147.        drwxr-x--x  4   root    system  512 Jun 11      13:29 incoming/
  148.  
  149.        Create subdirectories in the ~ftp/incoming using names known only 
  150.        between your local users and the anonymous users that you want to 
  151.        have "drop off" permission.  The same care used in selecting passwords
  152.        should be taken in selecting these subdirectory names because the 
  153.        object is to choose names that cannot be easily guessed.  Please do not
  154.        use our example directory names of jAjwUth2 and MhaLL-iF.
  155.  
  156.            drwxr-x-wx 10   root    system  512 Jun 11      13:54 jAjwUth2/
  157.            drwxr-x-wx 10   root    system  512 Jun 11      13:54 MhaLL-iF/
  158.  
  159.        This will prevent the casual anonymous FTP user from writing files in 
  160.        your anonymous FTP file system.  It is important to realize that this 
  161.        method does not protect a site against the result of intentional or 
  162.        accidental disclosure of the directory names.  Once a directory name 
  163.        becomes public knowledge, this method provides no protection at all 
  164.        from unwanted use of the area.  Should a name become public, a site 
  165.        may choose to either remove or rename the writable directory.
  166.  
  167.     C. Using a single disk drive
  168.  
  169.        If your site is planning to offer a "drop off" service and is
  170.        unable to modify the FTP daemon, it may be desirable to limit
  171.        the amount of data transferred to a single file system mounted
  172.        as ~ftp/incoming.  If possible, dedicate a disk drive and mount 
  173.        it as ~ftp/incoming.
  174.  
  175.        The system administrator should monitor this directory (~ftp/incoming)
  176.        on a continuing basis to ensure that it is not being misused.
  177.  
  178.  
  179. III. Related CERT Advisories
  180.  
  181.     The following CERT Advisories directly relate to FTP daemons or impact
  182.     on providing FTP service:
  183.  
  184.         CA-95:16.wu-ftpd.vul
  185.         CA-93:06.wuarchive.ftpd.vulnerability
  186.         CA-92:09.AIX.anonymous.ftp.vulnerability
  187.         CA-88:01.ftpd.hole
  188.  
  189.     Past advisories are available from
  190.     ftp://info.cert.org/pub/cert_advisories 
  191.     http://www.sei.cmu.edu/technology/cert.cc.html
  192.  
  193. - ------------------------------------------------------------------------------
  194.  
  195. Copyright 1995 Carnegie Mellon University. Conditions for use, disclaimers,
  196. and sponsorship information can be found in
  197. http://www.cert.org/legal_stuff.html and ftp://ftp.cert.org/pub/legal_stuff .
  198. If you do not have FTP or web access, send mail to cert@cert.org with
  199. "copyright" in the subject line.
  200.  
  201. CERT is registered in the U.S. Patent and Trademark Office.
  202.  
  203.  
  204. -----BEGIN PGP SIGNATURE-----
  205. Version: 2.6.2
  206.  
  207. iQCVAwUBNDjWGnVP+x0t4w7BAQHHfwP9FZpRc1202+MEb95BdPPt1A5PjLkb9aaN
  208. lpQ8BwRzUO+CGERev4UaICiSuuLzyk4cTgrGVtnDfoXB1lUTVfF52Yenz0godBzN
  209. tUfJv/EkBHmFaprrlrWHiw6E70eYiJl+F4t1hbDk2YaimbHLtQ/WvELkDknSqoeS
  210. bq8JF60sweU=
  211. =PPQG
  212. -----END PGP SIGNATURE-----
  213.