install and startup

If you install ProFTPD using distribution RPM packages such as the one for Red Hat, the required configuration entries are made in your proftpd.conf file. If you installed from compiled source code, you may have to modify the entries in the default proftpd.conf file provided. Make sure the FTP user and group specified in the proftpd.conf file actually exist.

You can download ProFTPD through the ProFTPD Web site at www.proftpd.net. You can use the official FTP site at ftp.proftpd.org or one of the associated mirror sites. The RPM package version will contain three packages: a core application, a standalone version, and an inetd version that will run on xinetd. Download and install the core package first. Then, depending on whether you want to run ProFTPD as a standalone or inetd process, install either the inetd or the standalone package.

proftpd-1.2.8-1.i686.rpm
proftpd-inetd-1.2.8-1.i686.rpm
proftpd-standalone-1.2.8-1.i686.rpm

You can run ProFTPD either as a standalone process or from xinetd. Make sure the appropriate entry is made in the ServerType directive in your proftpd.conf file. The standalone RPM package will install proftpd to run as a standalone server, setting the ServerType to standalone. On Red Hat systems, a startup script named proftpd is placed in the /etc/rc.d/inet.d directory that starts up the daemon when you boot your system. A standalone process is continually running. You can start, stop, and restart the server using the service command, as shown here:

service proftpd restart

To set the runlevels at which it will start automatically, you can use chkconfig or redhat-config-services. The following command sets proftpd to run automatically from runlevels 3 and 5:

chkconfig --level 35 proftpd on

The following command would disable proftpd:

chkconfig --del proftpd

If you want to run proftpd as an xinetd process, you first must change the ServerType to inetd and disable the proftpd startup script in the /etc/rc.d/inet.d directory. To run ProFTPD from xinetd, make sure to create an appropriate file for it in the /etc/xinetd.d directory. Currently, the proftpd inetd RPM package implements an in.proftpd link to the proftpd daemon. Use this link to invoke ProFTPD in the ProFTPD xinetd file. A simple ProFTPD xinetd file, named proftpd, would look like this:

# default: on
service proftp
{
        disable              = no
        socket_type          = stream
        wait                 = no
        user                 = root
        server               = /usr/sbin/in.proftpd
}

Use the chkconfig command with the off or on argument to disable or enable proftpd running under xinetd.

chkconfig proftpd on

proftpd.config and .ftpaccess

ProFTPD uses only one configuration file, named proftpd.conf, located in the /etc directory. Configuration entries take the form of directives. This format is purposely modeled on Apache configuration directives. With the directives, you can enter basic configuration information, such as your server name, or perform more complex operations, such as implementing virtual FTP hosts. The design is flexible enough to enable you to define configuration features for particular directories, users, or groups.

To configure a particular directory, you can use an .ftpaccess file with configuration options placed within that directory. These .ftpaccess options take precedence over those in the proftpd.conf directory. .ftpaccess files are designed to operate like .htaccess files in the Apache Web server that configure particular Web site directories. You can find a complete listing of ProFTPD configuration parameters at the ProFTPD Web site (www.proftpd.net) and in the ProFTPD documentation installed in /usr/doc as part of the ProFTPD software package. Several of the more commonly used parameters are listed in Table 21-4. When creating a new configuration, you should make a copy of the proftpd.conf configuration file and modify it. Then you can test its syntax using the proftpd command with the -c option and the name of the file.

proftpd -c newfile.conf

Different kinds of directives exist. Many set values, such as MaxClients, which sets the maximum number of clients, or NameServer, which sets the name of the FTP server. Others create blocks that can hold directives that apply to specific FTP server components. Block directives are entered in pairs: a beginning directive and a terminating directive. The terminating directive defines the end of the block and consists of the same name, beginning with a slash. Block directives take an argument that specifies the particular object to which the directives will apply. For the Directory block directive, you must specify a directory name to which it will apply. The <Directory mydir> block directive creates a block whose directives within it apply to the mydir directory. The block is terminated by a </Directory> directive. <Anonymous ftp-dir> configures the anonymous service for your FTP server. You need to specify the directory on your system used for your anonymous FTP service, such as /var/ftp. The block is terminated with the </Anonymous> directive. The <VirtualHost hostaddress> block directive is used to configure a specific virtual FTP server and must include the IP or the domain name address used for that server. </VirtualHost> is its terminating directive. Any directives you place within this block are applied to that virtual FTP server. The <Limit permission> directive specifies the kind of access you want to limit. It takes as its argument one of several keywords indicating the kind of permission to be controlled: WRITE for write access, READ for read access, STOR for transfer access (uploading), and LOGIN to control user login.

A sample of the standard proftpd.conf file installed as part of the ProFTPD software package is shown here. It establishes a single server and a single anonymous login. Notice the default ServerType is standalone. If you want to use xinetd to run your server, you must change this entry to inetd. Detailed examples of proftpd.conf files, showing various anonymous FTP and virtual host configurations, can be found with the ProFTPD documentation, located in /usr/share/doc, and on the ProFTPD Web site at www.proftpd.net.

ServerName         "ProFTPD Default Installation"
ServerType         standalone
DefaultServer      on
Port            21
Umask           022
MaxInstances    30
User          nobody
Group         nobody
<Directory /*>
       AllowOverwrite      on
</Directory>
# A basic anonymous configuration, with one incoming directory.
<Anonymous ~ftp>
  User            ftp
  Group           ftp
  RequireValidShell      off
  MaxClients         10
  UserAlias         anonymous ftp
  DisplayLogin         welcome.msg
  DisplayFirstChdir      .message
  # Limit WRITE everywhere in the anonymous chroot except incoming
  <Directory *>
     <Limit WRITE>
         DenyAll
     </Limit>
  </Directory>
  <Directory incoming>
     <Limit WRITE>
            AllowAll
     </Limit>
     <Limit READ>
            DenyAll
     </Limit>
  </Directory>
</Anonymous>

Authentication

Authentication of users in ProFTPD can be implemented either in PAM, LDAP, or SQL. For LDAP or SQL, you need to load the corresponding ProFTPD module. PAM authentication is the default (see Chapter 28 for more information on LDAP and PAM). Be sure that a /etc/pam.d/ftp file has been installed to provide PAM FTP support. ProFTPD also supports both standard passwords and shadow passwords. The default PAM authentication can be turned off by setting the AuthPAMAuthoritative directive to off, allowing other authentication methods such as LDAP to be used. If your server is further hidden in a local network by IP Masquerading techniques, you can use the MasqueradeAddress directive to specify its public host name, allowing its real host name to remain hidden.

Anonymous Access

You use the Anonymous configuration directive to create an anonymous configuration block in which you can place directives that configure your anonymous FTP service. The directive includes the directory on your system used for the anonymous FTP service. The ProFTPD daemon executes a chroot operation on this directory, making it the root directory for the remote user accessing the service. By default, anonymous logins are supported, expecting users to enter their e-mail address as a password. You can modify an anonymous configuration to construct more controlled anonymous services, such as guest logins and required passwords.

The following example shows a standard anonymous FTP configuration. The initial Anonymous directive specifies /var/ftp as the anonymous FTP home directory. The User directive specifies the user that the Anonymous FTP daemon will run as, and Group indicates its group. In both cases, FTP, the standard username, is used on most systems for anonymous FTP. A Directory directive with the * file-matching character then defines a Directory block that applies to all directories and files in /var/ftp. The * symbol matches on all filenames and directories. Within the Directory directive is a Limit directive that you use to place controls on a directory. The directive takes several arguments, including READ for read access and WRITE for write access. In this example, the Limit directive places restrictions on the write capabilities of users. Within the Limit directive, the DenyAll directive denies write permission, preventing users from creating or deleting files and effectively giving them only read access. A second Directory directive creates an exception to this rule for the incoming directory. An incoming directory is usually set up on FTP sites to let users upload files. For this directory, the first Limit directive prevents both READ and WRITE access by users with its DenyAll directive, effectively preventing users from deleting or reading files here. The second Limit directive allows users to upload files, however, permitting transfers only (STOR) with the AllowAll directive.

One important directive for anonymous FTP configurations is RequireValidShell. By default, the FTP daemon first checks to see if the remote user is attempting to log in using a valid shell, such as the BASH shell or the C shell. The FTP daemon obtains the list of valid shells from the /etc/shells file. If the remote user does not have a valid shell, a connection is denied. You can turn off the check using the RequireValidShell directive and the off option. The remote user can then log in using any kind of shell.

<Anonymous /var/ftp>
    User ftp
    Group ftp
    UserAlias anonymous ftp
    RequireValidShell off
 <Directory *>
       <Limit WRITE>
               DenyAll
       </Limit>
    </Directory>
     # The only command allowed in incoming is STOR
     # (transfer file from client to server)
    <Directory incoming>
       <Limit READ WRITE>
               DenyAll
       </Limit>
       <Limit STOR>
               AllowAll
       </Limit>
    </Directory>
 </Anonymous>

Recall that FTP was originally designed to let a remote user connect to an account of his or her own on the system. Users can log in to different accounts on your system using the FTP service. Anonymous users are restricted to the anonymous user account. However, you can create other users and their home directories that also function as anonymous FTP accounts with the same restrictions. Such accounts are known as guest accounts. Remote users are required to know the username and, usually, the password. Once connected, they have only read access to that account's files; the rest of the file system is hidden from them. In effect, you are creating a separate anonymous FTP site at the same location with more restricted access.

To create a guest account, first create a user and the home directory for it. You then create an Anonymous block in the proftpd.conf file for that account. The Anonymous directive includes the home directory of the guest user you create. You can specify this directory with a ~ for the path and the directory name, usually the same as the username. Within the Anonymous block, you use the User and Group directives to specify the user and group name for the user account. Set the AnonRequirePassword directive to on if you want remote users to provide a password. A UserAlias directive defines aliases for the username. A remote user can use either the alias or the original username to log in. You then enter the remaining directives for controlling access to the files and directories in the account's home directory. An example showing the initial directives is listed here. The User directive specifies the user as myproject. The home directory is ~myproject, which usually evaluates to /var/myproject. The UserAlias lets remote users log in with either the name myproject or mydesert.

<Anonymous ~myproject>
    User myproject
    Group other
    UserAlias mydesert myproject
    AnonRequirePassword on
    <Directory *>

You could just as easily create an account that requires no password, letting users enter in their e-mail addresses instead. The following example configures an anonymous user named mypics. A password isn't required, and neither is a valid shell. The remote user still needs to know the username, in this case mypics.

<Anonymous /var/mypics>
    AnonRequirePassword off
    User mypics
    Group nobody
    RequireValidShell off
    <Directory *>

The following example provides a more generic kind of guest login. The username is guest, with the home directory located at ~guest. Remote users are required to know the password for the guest account. The first Limit directive lets all users log in. The second Limit directive allows write access from users on a specific network, as indicated by the network IP address, and denies write access by any others.

<Anonymous ~guest>
  User            guest
  Group           nobody
  AnonRequirePassword      on
  <Limit LOGIN>
         AllowAll
  </Limit>
  # Deny write access from all except trusted hosts.
  <Limit WRITE>
         Order        allow,deny
         Allow        from 10.0.0.
         Deny         from all
  </Limit>
</Anonymous>

Virtual FTP Servers

The ProFTPD daemon can manage more than one FTP site at once. Using a VirtualHost directive in the proftpd.conf file, you can create an independent set of directives that configure a separate FTP server. The VirtualHost directive is usually used to configure virtual servers as FTP sites. You can configure your system to support more than one IP address. The extra IP addresses can be used for virtual servers, not independent machines. You can use such an extra IP address to set up a virtual FTP server, giving you another FTP site on the same system. This added server would use the extra IP address as its own. Remote users could access it using that IP address, instead of the system's main IP address. Because such an FTP server is not running independently on a separate machine but is, instead, on the same machine, it is known as a virtual FTP server or virtual host. This feature lets you run what appear to others as several different FTP servers on one machine. When a remote user uses the virtual FTP server's IP address to access it, the ProFTPD daemon detects that request and operates as the FTP service for that site. ProFTPD can handle a great many virtual FTP sites at the same time on a single machine.

You configure a virtual FTP server by entering a <VirtualHost> directive for it in your proftpd.conf file. Such an entry begins with the VirtualHost directive and the IP address, and ends with a terminating VirtualHost directive, </VirtualHost>. Any directives placed within these are applied to the virtual host. For anonymous or guest sites, add Anonymous and Guest directives. You can even add Directory directives for specific directories. With the Port directive on a standalone configuration, you can create a virtual host that operates on the same system but connects on a different port.

<VirtualHost 10.0.0.1>
      ServerName "My virtual FTP server"
</VirtualHost>

Xinetd and standalone configurations handle virtual hosts differently. Xinetd detects a request for a virtual host and then hands it off to an FTP daemon. The FTP daemon then examines the address and port specified in the request and processes the request for the appropriate virtual host. In the standalone configuration, the FTP daemon continually listens for requests on all specified ports and generates child processes to handle ones for different virtual hosts as they come in. In the standalone configuration, ProFTPD can support a great many virtual hosts at the same time.

The following example shows a sample configuration of a virtual FTP host. The VirtualHost directives use domain name addresses for its arguments. When a domain name address is used, it must be associated with an IP address in the network's domain name server. The IP address, in turn, has to reference the machine on which the ProFTPD daemon is running. On the ftp.mypics.com virtual FTP server, an anonymous guest account named robpics is configured that requires a password to log in. An anonymous FTP account is also configured that uses the home directory /var/ftp/virtual/pics.

<VirtualHost ftp.mypics.com>
   
  ServerName         "Mypics FTP Server"
  MaxClients         10
  MaxLoginAttempts      1
  DeferWelcome         on
  <Anonymous ~robpics>
    User         robpics
    Group        robpics
    AnonRequirePassword      on
  <Anonymous /var/ftp/virtual/pics>
    User         ftp
    Group        ftp
    UserAlias    anonymous ftp
  </Anonymous>
</VirtualHost>