## 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:

- `MaxInstances`: Limits the overall number of connections
- `MaxClients`: Limits the number of connections on a per-server/vhost basis
- `MaxClientsPerHost`: Limits the number of clients that may be connecting from the same host
- `MaxClientsPerUser`: Limits the number of clients that may be logged in at one time using the same username
- `MaxHostsPerUser`: Limits the number of hosts from which clients may be logged in at one time using the same username

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:

- mod_diskuse
- mod_load
- mod_quotatab

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_wrap2`, which allows for storing access control rules in SQL tables.

On systems which support the /proc filesystem, such as Linux and several others, it is highly recommended that the /proc filesystem be guarded, especially for non-chroot sessions. Malicious clients can read or write to that filesystem and cause quite a bit of damage. Thus we encourge administrators to use the following in their `proftpd.conf`:

      <Directory /proc>
        <Limit ALL>
          DenyAll
        </Limit>
      </Directory>

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 `Include`d 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 `AuthUserFile`s (and `AuthGroupFile`s). 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 `Include`d 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).

© Copyright 2017 The ProFTPD Project
All Rights Reserved