Best Common Practices

This document describes the best practices, common and recommended, when configuring and using proftpd servers. The first few recommendations are covered in detail elsewhere: role accounts, chroots, and logging directories.

<VirtualHost>s
When configuration a <VirtualHost>, it is best to use an IP address, and not a DNS name. Not only does this reduce network traffic a little when the daemon starts up (as it will not need to resolve the DNS name to its IP address), but it will also reduce confusion. Unlike HTTP, FTP does not support name-based virtual hosts; all contact to virtual hosts is done based on IP addresses (and ports). If a DNS name is used in a <VirtualHost> configuration, there is the possibility that that DNS name will resolve to an IP address of another virtual host in the configuration.

Resource Limits
One of the most common requests on the mailing list is to be able to limit the number of connections, in various ways, a given user may make to the proftpd daemon. There are different configuration directives for doing so, depending on the situation:

If you are using a ServerType of inetd, then you should be aware of the default concurrency limits in inetd (see Bug#1243). For xinetd, the per_source and cps attributes can be used to configure concurrency limits. For a ServerType of standalone, the MaxConnectionRate configuration directive can be used to provide connection limitations.

Intensive use of CPU and/or memory by FTP sessions can be restricted by use of RLimitCPU and RLimitMemory. Here's an example: 

  RLimitCPU session 10
  RLimitMemory session 4096
This applies CPU and memory resource limits to session processes. In order to limit the use of such resources by the daemon, should this be a concern, the directives can be used similarly: 
  RLimitMemory daemon 8192 max
In general, one should not set an RLimitCPU limit on the daemon, as a long-lived daemon (as all should be) will eventually encounter such a limit. Note: appropriate settings to use will vary from site to site - do not blindly copy these examples.

One concern associated with unrestricted use of resources is globbing; the topic has been mentioned, in relation to FTP servers, in security forums in the past. This mini-HOWTO discusses, in-depth, the defenses against globbing attacks that ProFTPD provides.

Some sites like to be able to restrict the size of files transferred, particularly uploaded files, as disk space is also a precious resource. For this purpose, the MaxRetrieveFileSize and MaxStoreFileSize configuration directives are provided.

There are also several third-party modules that can add various resource limiting abilities to a proftpd server:

Access Controls
ProFTPD provides a <Limit> directive for configuring fine-grained access controls that can be applied to logins as well as FTP commands. The contributed mod_wrap module allows a proftpd daemon to use the standard /etc/hosts.allow and /etc/hosts.deny access control files. Of interest to some is the next generation of this module, mod_wrap-2.0, which allows for storing access control rules in SQL tables.

Performance Tuning
When configuring a proftpd for performance, here are some settings to try. First, make sure that you have ident and reverse DNS lookups disabled: 

  IdentLookups off
  UseReverseDNS off
By default, both are done for each new FTP session, and, depending on the response time from both identd and DNS servers, this can add a noticeable delay during the login process.

Another possible source of delays during the login process is a very large /etc/passwd file (a large /etc/group file will have the same effect). The standard library functions used for doing user lookups scan these files line-by-line, which means that the scan time increases with the number of entries. If this is the case at your site, you might consider using a different storage format for your user account information. The mod_sql and mod_ldap modules provided with ProFTPD can be used for storing such information in SQL tables or LDAP servers.

In some cases, it's also possible that PAM checks may introduce delays. If you suspect this to be happening, try adding the following to your proftpd.conf: 

  <IfModule mod_auth_pam.c>
    AuthPAM off
  </IfModule>

The listing of directories during an FTP session can impose quite a bit of disk I/O on a server machine. This is most often seen when site-mirroring scripts do recursive directory listings, and for deeply nested directory structures. To deal with the former, the following can be used: 

  ListOptions +R strict
This setting blocks the use of the -R option, which is how clients request recurse directory listings. The strict keyword prevents client options from overriding the proftpd.conf setting. Also, new in 1.2.9rc1 are some ListOptions options that allow recursive directory listings, but can be used to set limits on the recursion: 
  ListOptions "" maxdepth 3
  ListOptions "" maxdirs 10
  ListOptions "" maxfiles 1000
The first line above limits the directory depth of recursion; the second line does not limit the recursion depth, rather it limits the maximum number of directories that may be listed at one time; the third limit limits the maximum number of files that may be listed at one time.

Another way to speed up directory listings to disable proftpd's checking for .ftpaccess files in every directory encountered. To do this, use: 

  AllowOverride off
This disable's proftpd's honouring of .ftpaccess files. How does this reduce disk I/O? In order to properly process .ftpaccess files, the daemon has to check for such a file in each and every directory when performing an operation in that directory, each time an operation is requested (it's possible for a .ftpaccess file to be added or updated after the daemon has already checked the directory). This constant checking is noticeable on heavily loaded servers. By disabling use of these files, the daemon no longer has to check each directory each time.

The type of logging also has an impact, performance-wise. By default, a proftpd daemon logs using syslog; syslogd, however, is known to not scale well at all, and can break under heavy load. Directing logging to a file in such cases, using the ServerLog and/or SystemLog directives can reduce this bottleneck. Also, depending on the type of authentication done, disabling utmp/wtmp logging can reduce overhead: 

  WtmpLog off
for <VirtualHost>s that only allow anonymous logins, or that authenticate non-/etc/passwd accounts, helps to reduce the amount of unnecessary "clutter" in the utmp/wtmp log files.

If your proftpd server is on a high-bandwidth Internet link, it may benefit from tuning the size of kernel-level (as opposed to application-level) socket buffers used when transferring data. The SocketOptions configuration directive can be used to specify larger buffer sizes: 

  # The 'sndbuf' parameter tunes the size of the buffer used for sending
  # files to clients; the 'rcvbuf' tunes the buffer used for receiving
  # files uploaded by clients.
  #
  # This configures 16K buffers for both, which assumes a very
  # well-connected site.
  SocketOptions sndbuf 16384 rcvbuf 16384
Again, these are example numbers, and should not be blindly copied.

Finally, there are some configure options that can be used to tune your proftpd daemon. All of the --enable- options are available; of particular interest are --enable-tunable-buffer-size and --enable-sendfile. Use of the sendfile(2) function (via the latter configure option) may or may not increase download speeds, but it will reduce disk I/O: sendfile(2) implements zero-copy transfers, meaning that the kernel will read data directly from the file into the socket, all in kernel space; normal read() transfers spend time copying buffers from kernel space to application space (reading the file), and then back to kernel space (writing to the socket). By increasing the buffer size using the --enable-tunable-buffer-size option, proftpd reads and writes data in larger chunks, and makes fewer expensive system calls. Use of this option to set buffer sizes of 8K or more has been reported to drastically increase transfer speeds (depending on network configurations).

Configuration Delegation
A configuration is considered "delegated" when the Include configuration directive is used in proftpd.conf to specify a portion of the server configuration that may not be under the daemon administrator's control. This situation often arises for sites that have multiple virtual servers; the administrator for a given virtual server may be allowed to configure their particular server via an Included file. If possible, avoid this.

Here's why: by delegating a configuration, you are trusting someone else with a great deal of possible control over the daemon. A given <VirtualHost> section can have an AuthUserFile. In that AuthUserFile, the virtual server administrator could define a user who has a UID of 0, thus basically giving herself root access. Most sites probably would not like this. The trouble here is the lack of control over the contents of AuthUserFiles (and AuthGroupFiles). There are a couple of ways of handling this situation. First, the daemon administrator can make sure that any Include directives occur as early as possible in the proftpd.conf file. Most configuration directives in the Included file can be overridden by setting the directive again, after the Include, in the main proftpd.conf.

The mod_auth_file module, now part of the core distribution, was developed specifically to provide finer control over the contents of AuthUserFile and AuthGroupFile files. It does so by enhancing these configuration directives to support optional "filters" that restrict the UIDs, GIDs, user names, and/or home directories in such files.

Miscellaneous
For the security-wary administrator, there are a few more directives that may be of interest: AnonRejectPasswords, which configures a regular expression that matches and blocks scripted FTP clients that try to find and exploit ill-configured anonymous FTP sites, and RootRevoke, which causes proftpd to drop root privileges completely (read the description for details).

Last Updated: $Date: 2004/05/25 17:41:34 $