Viewing file:  BCP.html (13.69 KB) -rw-r--r--
Select action/file-type:
 (+) | (+) |  (+) | Code (+) | Session (+) |  (+) | SDB (+) |  (+) |  (+) |  (+) |  (+) |  (+) |
ProFTPD: Best Common Practices
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:
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-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-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).
© Copyright 2017 The ProFTPD Project
All Rights Reserved
|