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 [email protected]
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.
