Debianhelp.co.uk


WU-Ftp Server installation and configuration

What is wu-ftpd ?

Wuarchive-ftpd, more affectionately known as WU-FTPD, is a replacement ftp daemon for Unix systems developed at Washington University (*.wustl.edu) by Chris Myers and later by Bryan D. O'Connor (who are no longer working on it or supporting it!). WU-FTPD is the most popular ftp daemon on the Internet, used on many anonymous ftp sites all around the world.

Download wu-ftpd

http://www.wu-ftpd.org/mirrors.html

wu-ftpd FAQ

http://www.wu-ftpd.org/wu-ftpd-faq.html

Installing wu-ftpd in Debian

# apt-get install wu-ftpd

Setting up wu-ftpd (2.6.2-23) ...
The anonymous FTP user has been successfully removed.
It's home directory, /home/ftp, has been left intact.
Starting FTP server: wu-ftpd.

At the time of installation it will ask you some questions about the setup you need to answer very carefully.

Anonymous FTP allows users to log in to the server using the username "anonymous" and their e-mail address as a password. This is usually used to give people access to public files.

If you accept here, a user called 'ftp' will be created, along with a home directory (which will be the root of the anonymous FTP area). The home directory will be populated with the binaries, libraries and configuration files necessary for anonymous FTP to work.

Do you want to allow anonymous ftp access?

After completing the installation you can see the default configuration files located at /etc/wu-ftpd

ftpaccess  ftpconversions  ftpservers  msg.deny  msg.nodns  msg.toomany  pathmsg  README  welcome.msg

There are three kinds of FTP logins that wu-ftpd provides:

anonymous FTP - one logs in with the username 'anonymous'

real FTP - log in with a real username and password and has access to the entire disk structure.

guest FTP - one logs in with a real user name and password, but the user is chroot'ed to his home directory and cannot escape from it. They are constrained to their home directory which also means that they don't have access to /bin/ls and other commands on the server. Thus a local minimalist environment must be set up.

Guest FTP Configuration

The file /etc/ftpaccess controls the configuration of ftp.

  # Don't allow system accounts to log in over ftp
  deny-uid %-99 %65534-
  deny-gid %-99 %65534-

  class   all   real,guest  *
  email webmaster@your-domain.com
  loginfails 5

  readme  README*    login
  readme  README*    cwd=*
  message /welcome.msg            login
  message .message                cwd=*

  compress       yes             all
  tar                yes             all
  chmod           no              guest,anonymous
  delete           no              anonymous    # delete files permission?
  overwrite       no              anonymous    # overwrite files permission?
  rename          no              anonymous    # rename files permission?
  delete           yes             guest        # delete files permission?
  overwrite       yes             guest        # overwrite files permission?
  rename          yes             guest        # rename files permission?
  umask           no              guest        # umask permission?

  log transfers anonymous,real inbound,outbound

  shutdown /etc/shutmsg

  passwd-check rfc822 warn

  # Must also create message file /etc/pathmsg of the guest directory.
  # In this case it refers to /home/user1/public_html/etc/pathmsg.
  path-filter  guest /etc/pathmsg  ^[-A-Za-z0-9_\.]*$  ^\.  ^-
  limit all 2
  noretrieve passwd .htaccess core    - Do not allow users to download files of these names
  limit-time * 20
  byte-limit in 5000      - Limit file size
  guestuser *    - Set system user default to be categorized as a "guest". A "real" user can roam              system.Guestuser is chrooted.
  realgroup regularuserx regularusery - Assign real user privileges to members of groups "regularuserx" and                                          "regularusery".Visibility of the whole file system and subject to regular UNIX file                                          permissions
  realuser user4            - Assign real user privileges to user id "user4".

  restricted-uid user1 user2 user3    - Restricts FTP to the specified directories
  guest-root /home/user1/public_html user1
  guest-root /home/user2/public_html user2
  guest-root /home/user3/public_html user3

Note:

user1, user2 and user3 refer to login accounts. Use the appropriate login name.
The above configuration disables anonymous FTP which allows anyone to perform an FTP login with the id anonymous and an email address as a password. To enable anonymous FTP, change the class directive to:

class all real,guest,anonymous *

Allow overide of deny-uid and/or deny-gid:

    allow-uid user-to-allow
    allow-gid group-to-allow

Optional configuration:

Create a group ftpchroot
Add users to this group
Use directive: guestgroup ftpchroot

File /home/user1/public_html/etc/pathmsg:

  A NOTE TO USERS UPLOADING FILES:

  File names may consist of letters (a-z, A-Z), numbers (0-9),
  an under score ("_"), dash ("-") or period (".") only.
  The file name may not begin with a period or dash.
  You have tried to upload a file with an inappropriate name.

The whole point of the chroot directory is to make the user's home directory appear to be the root of the filesystem (/) so one could not wander around the filesystem. Configuration of /etc/ftpaccess will limit the user to their respective directories while still offering access to /bin/ls and other system commands used in FTP operation.

As root:

  cd /home/user1
  mkdir public_html
  chown $1.$1 public_html
  touch .rhosts             - Security protection
  chmod ugo-xrw .rhosts

Configuring anonymous FTP

FTP daemon

Sites should ensure that they are using the most recent version of their FTP daemon.

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.

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:

Providing writable directories in your anonymous FTP configuration

There is a risk to operating an anonymous FTP service that permits users to store files. We strongly recommend that sites do not automatically create a "drop off" directory unless thought has been given to the possible risks of having such a service.

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.

Modified FTP daemon

If your site is planning to offer a "drop off" service, we suggest 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:

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.

Limit the amount of data transferred in one session.

Limit the overall amount of data transferred based on available disk space.

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

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.

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.

The system administrator should monitor this directory (~ftp/incoming) on a continuing basis to ensure that it is not being misused.