Both the RPM and tarball installations provide a default configuration with a readonly anonymous FTP area and full regular access to users on the system. This is a good starting point if all you want is to offer anonymous FTP access.

The configuration file for ProFTPD is /etc/proftpd.conf or $prefix/etc/proftpd.conf if installed from source. The anonymous FTP users are chroot()ed into the home directory of the FTP user, often something like /srv/ftp/.

proftpd.conf contains a number of configuration directives. A reference of all directives can be found at http://www.proftpd.org/docs/directives/configuration_full.html. The configuration file is divided up into a number of contexts, each dealing with its own aspect of ProFTPD:

The following sections present two example configurations for ProFTPD: a basic Unix FTP server setup and a more advanced one in which ProFTPD is using its own user database.

The example configuration provides us with both an anonymous access area and access to the whole filesystem for regular users:

ServerName      "ProFTPD Default Installation"
ServerType      standalone

ServerName specifies the banner text that the user sees when accessing the server. ServerType can be either standalone or inetd and specifies whether ProFTPD is listening for incoming connections by itself or is being run from (x)inetd.

DefaultServer                   on
Port                            21

DefaultServer on means that our server configuration applies to all interfaces of the host, and Port specifies the port ProFTPD is listening to (port 21 is the standard FTP port):

Umask                           022
MaxInstances                    30
User                            nobody
Group                           nogroup
AllowOverwrite                  on
<Limit SITE_CHMOD>
DenyAll
</Limit>

Umask is equivalent to the umask setting in the shell. MaxInstances is the upper limit on concurrent ProFTPD child processes; this limits the number of simultaneous users to 30. User and Group specify the user and group ProFTPD will run under when not doing privileged operations or running with the privileges of an authenticated user. AllowOverwrite on means that users are allowed to overwrite writable files. The <Limit> section blocks everybody from using the site chmod command.

<Anonymous ~ftp>
User                          ftp
Group                         ftp
UserAlias                     anonymous ftp
MaxClients                    10
DisplayLogin                  welcome.msg
DisplayFirstChdir             .message
<Limit WRITE>
DenyAll
</Limit>
</Anonymous>

This part of the configuration file sets up a read-only anonymous FTP in the FTP user’s home directory (often /srv/ftp) running as user ftp, with a maximum of 10 simultaneous users. DisplayLogin welcome.msg will display the contents of the file welcome.msg as the login banner, and DisplayFirstChdir .message will display the contents of the file .message in the current directory when the user first cds into it.

Here we look at a more complex setup in which the users allowed to log in to the FTP server are not taken from the regular Unix user database, but instead from a passwd file exclusive to ProFTPD. In addition, we provide limited anonymous access.

The proftpd.conf file looks like this:

ServerName                        "Acme ftp server"
ServerType                        standalone
DefaultServer                     on
ServerIdent on                    "FTP Server ready."
UseReverseDNS                     off
IdentLookups                      off
DeferWelcome                      on
Port                              21
MaxInstances                      30
User                              ftp
Group                             nogroup
Umask                             022

<Limit LOGIN>
   Order Deny,Allow
   AllowGroup ftpusers
</Limit>

AuthPAM off
AuthUserFile /etc/proftpd.passwd
AuthGroupFile /etc/proftpd.group
RequireValidShell off
DefaultRoot ~
DirFakeUser on ~
DirFakeGroup on ~

DisplayLogin                     welcome.msg
DisplayFirstChdir                .message

TransferLog        /var/log/xferlog

ScoreboardFile /var/lib/proftpd/scoreFile

<Directory />
  AllowOverwrite                on
</Directory>

<Anonymous /srv/ftp/anonymous>
  User                           ftp
  Group                          ftp
  # We want clients to be able to login with "anonymous" as well as "ftp"
  UserAlias                        anonymous ftp
  # Limit the maximum number of anonymous logins
  MaxClients                     15
  <Limit LOGIN>
    AllowAll
  </Limit>
  # Limit WRITE everywhere in the anonymous chroot
  <Limit WRITE>
    DenyAll
  </Limit>
  TransferRate RETR 40.0:1024
</Anonymous>

<Directory /srv/ftp/joe/upload>
  <Limit WRITE STOR DEL>
        AllowAll
  </Limit>
</Directory>

Let us first have a look at how users are handled. FTP is an old protocol that sends passwords unencrypted over the wire, so it is desirable to separate users with “real” accounts from users with FTP-only accounts. To do this, we use two configuration directives,

AuthUserFile /etc/proftpd.passwd
AuthGroupFile /etc/proftpd.group

to point ProFTPD at alternative passwd and group files. The format is the same as the regular Linux /etc/passwd and /etc/group files. The contents of /etc/proftpd.passwd for testing purposes are as follows:

joe:$1$KdLsLL1G$LNGq21xp9l/4vhF/l/0N1.:20000:20000:Joe User:/srv/ftp/joe:

The password is “qwerty” in cleartext and is hashed using the ftpasswd utility that can be found in the contrib directory in the ProFTPD tarball. /etc/proftpd.group contains only a single line: ftpusers:x:20000: This is used in conjunction with the

<Limit LOGIN>
Order Deny,Allow
AllowGroup ftpusers
</Limit>

section in the configuration file to block regular users from logging in and to allow only members of our special group ftpusers to log in. Notice that this is not the same as the legacy file /etc/ftpusers, which can be used for listing system users who are not allowed to use FTP. The documentation states that the file specified in AuthUserFile replaces the system /etc/passwd file, but this seems not to be the case currently — hence the special group to only allow users listed in our alternative passwd file.

It is possible to have multiple users in /etc/proftpd.passwd with the same Unix numeric user ID. This is useful if you want to provide FTP access for a huge number of users without running out of user IDs. To make files appear to be owned by the currently authenticated user and group, we put in the:

DirFakeUser on ~
DirFakeGroup on ~

directives. This is only for cosmetic purposes to give users the nice fuzzy feeling that they in fact own their files. The ScoreboardFile directive specifies the location of the file used for runtime session information. This file is required for utilities such as ftpwho and ftpcount to work. This completes the main server configuration.

The next part of the config file is a read-only <Anonymous> context for users anonymous and ftp in /srv/ftp/anonymous, with a maximum of 15 concurrent users. There is also a download rate limit specified by the TransferRate RETR 40.0:1024 directive. The numbers mean that the download rate is limited to 40 KB per second for all files larger than 1 KB.

The last context of the config file specifies a writable directory /upload for the user joe. By default nothing is writable for any user because of the <Limit WRITE> directive in the main server context, so user joe is granted the special privilege to be allowed to upload files to his upload directory.

ProFTPD supports virtual hosting via the <VirtualHost> context. The FTP protocol unfortunately does not support host-based virtual hosting, unlike, for example, HTTP, but it is still possible to serve different ports or network interfaces with different configurations. All this will, of course, only work if ProFTPD is run in standalone mode; if run from inetd, the ports and interfaces that are listened to are in the hands of inetd and not ProFTPD.

Let’s look at an example with a few virtual hosts configured:

ServerName         "Acme FTP Server"
ServerType         standalone

### Main server config
# Set the user and group that the server normally runs at.
User               nobody
Group              nogroup
MaxInstances       30

# Global creates a "global" configuration that is shared by the
# main server and all virtualhosts.

<Global>
  # Umask 022 is a good standard umask
  # to prevent new dirs and files
  # from being group and world writable.
  Umask            022
</Global>

### Virtual server running on our internal interface
<VirtualHost 127.0.0.1>
  ServerName  "Acme Internal FTP"
  MaxClients       10
  DeferWelcome     on
  <Limit LOGIN>
    DenyAll
  </Limit>
  <Anonymous /srv/ftp/anonymous-internal>
    User           ftp
    Group          ftp
    AnonRequirePassword  off
    # We want clients to be able to login
    # with "anonymous" as well as "ftp"
    UserAlias      anonymous ftp
    <Limit LOGIN>
      AllowAll
    </Limit>
    # Limit WRITE everywhere in the anonymous chroot
    <Limit WRITE>
      DenyAll
    </Limit>
  </Anonymous>
</VirtualHost>

### Another virtual host on port 4000
<VirtualHost 192.168.1.5>
  ServerName  "Acme Internal FTP upload"
  Port             4000
  MaxClients       10
  MaxLoginAttempts 1
  DeferWelcome     on
  <Limit LOGIN>
    DenyAll
  </Limit>
  <Anonymous /srv/ftp/anonymous-upload>
    User           ftp
    Group          ftp
    AnonRequirePassword  off
    # We want clients to be able to login with
    # "anonymous" as well as "ftp"
    UserAlias      anonymous ftp
    <Limit LOGIN>
      AllowAll
    </Limit>
    # We only allow upload
    <Limit STOR CWD XCWD>
      AllowAll
    </Limit>
    <Limit READ DELE MKD RMD XMKD XRMD>
      DenyAll
    </Limit>
  </Anonymous>
</VirtualHost>

The example is a pretty standard main server that allows Unix users access to the filesystem. The interesting parts are the two <VirtualHost> sections. The first one is an anonymous-only server listening to the localhost (127.0.0.1) interface (not particularly useful, I admit), and the second one is an anonymous-only, write-only server listening to port 4000 on the 192.168.1.5 interface.