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.
