Professional FTP Daemon: ProFTPD

 < Day Day Up > 



ProFTPD is based on the same design as the Apache Web server, implementing a similar simplified configuration structure and supporting such flexible features as virtual hosting. ProFTPD is an open source project made available under a GPL license. You can download the current version from its Web site at www.proftpd.net or www.proftpd.org. There you will also find detailed documentation including FAQs, user manuals, and sample configurations. Check the site for new releases and updates.

RPM packages are available for many distributions, including Red Hat, and from www.proftpd.net. Unlike when installing other FTP daemons, you do not need to set up special subdirectories of system files in the FTP home directory. No special bin or etc files are needed. You can also set up ProFTPD to alternate automatically between xinetd startups or as a standalone server constantly running, depending on the system load.

ProFTPD's tools operate in the same way as the WU-FTPD tools. ftpshut shuts down the system at specified times with warnings. With ProFTPD, you can shut down a virtual host while the main server continues to run. ftpwho displays a list of all remote users currently connected, broken down according to virtual hosts and servers. ftpcount shows the number of current connections by server and virtual hosts. See the section "ProFTPD and WU-FTPD Server Tools" at the end of this chapter for more information.

ProFTPD is designed to be extensible, supporting dynamic modules that can be either custom made or provided by third-party developers. Currently, there are modules to provide LDAP and SQL authentication, along with numerous enhancement modules for such features as user quotas, logging formats, and time constraints.

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.

Note 

For ProFTPD, your anonymous FTP directory does not require any system files. Before ProFTPD executes a chroot operation, hiding the rest of the system from the directory, it accesses and keeps open any needed system files outside the directory.

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.

Note 

Given its configuration capabilities, you can also tailor any of the virtual FTP sites to specific roles, such as a guest site, an anonymous site for a particular group, or an anonymous site for a particular user.

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> 
Table 21-4: ProFTPD Configuration Directives, proftpd.conf

Directive

Description

Allow ["from"] "all"|"none"|host|
network[,host|
network[,...]]

Used inside a <Limit> context to specify explicitly which hosts and/or networks have access to the commands or operations being limited. Used with Order and Deny to create access control rules. Default: Allow from all Context: <Limit>

AllowAll

Allows access to a <Directory>, <Anonymous> or <Limit> block.

AllowFilter regular-expression

Allows the configuration of a regular expression that must be matched for all commands sent to ProFTPD.

AllowUser user-expression

Users allowed access.

<Anonymous root-directory>

Creates an anonymous FTP login, terminated by a matching </Anonymous> directive. The root directory parameter is the directory proftpd first moves to and then chroot to, hiding the rest of the file system.

Bind address

Allows additional IP addresses to be bound to a main or VirtualHost configuration. Multiple Bind directives can be used to bind multiple addresses.

DefaultRoot directory [group-expression]

Default root directory assigned to user on login. The group-expression argument restricts the DefaultRoot directive to a group or set of groups. Default: DefaultRoot /

Deny ["from"] "all"|"none"|host|network[,host|network[,...]]

List of hosts and networks explicitly denied access to a given <Limit> context block. all indicates all hosts are denied access, and none indicates no hosts are explicitly denied.

DenyAll

Denies access to a directory, anonymous FTP, or Limit block.

DenyFilter regular-expression

Specifies a regular expression, which must not match any command.

DenyUser user-expression

Users denied access within a Limit block.

<Directory pathname>

Directory-specific configuration. Used to create a block of directives that apply to the specified directory and its subdirectories.

DisplayLogin filename

Specifies the text file displayed to a user who logs in.

<Global>

Global configuration block

<Limit command|command-group [command2 ..]>

Access restrictions on FTP commands, within a given context. The command-group refers to groupings of commands as defined in the ProFTPD documentation.

LsDefaultOptions "options string"

Default options for directory listings (as in the ls command).

MasqueradeAddress host

Specifies public host name for FTP server. Used for FTP servers masqueraded by NAT tables (packet filtering). See Chapter 19.

MaxClients number|none message

Maximum number of connected clients allowed. The message specified is displayed when a client is refused connection.

MaxLoginAttempts number

Maximum number of times a client may attempt to log in to the server during a given connection.

Order allow,deny|deny,allow

Configures the order that Allow and Deny directives are checked inside a <Limit> block. Default: Order allow,deny Context: <Limit>

PersistentPasswd on|off

When on, proftpd, during login, opens the system-wide /etc/passwd, /etc/group files, accessing them even during a chroot operation that changes the root directory.

ServerAdmin "admin-email-address"

E-mail address of the server or virtual host administrator.

ServerType type-identifier

The server daemon's operating mode, either inetd or standalone.

TimeoutIdle seconds

Maximum number of seconds proftpd allows clients to stay connected without any activity. Default: TimeoutIdle 600

Umask octal-mask

Permissions applied to newly created file and directory within a given context.

User userid

The user the proftpd daemon runs as.

UserAlias login-user userid

Maps a login name used by a client to a user ID on the server. A client logging in as login-user is actually logged in as user ID. Often used inside an <Anonymous> block to allow specified login-names to perform an anonymous login.

<VirtualHost address>

Configuration directives that apply to a particular hostname or IP address. Often used with virtual servers that run on the same physical machine. The block is terminated with a </VirtualHost> directive.



 < Day Day Up > 



Red Hat(c) The Complete Reference
Red Hat Enterprise Linux & Fedora Edition (DVD): The Complete Reference
ISBN: 0072230754
EAN: 2147483647
Year: 2004
Pages: 328

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net