One Hat Cyber Team

View File Name : BCP.html

<!DOCTYPE html>
<html>
<head>
<title>ProFTPD: Best Common Practices</title>
</head>

<body bgcolor=white>

<hr>
<center><h2><b><i>Best Common Practices</i></b></h2></center>
<hr>

<p>
This document describes the best practices, common and recommended, when
configuring and using <code>proftpd</code> servers.  The first few
recommendations are covered in detail elsewhere: <a href="ConfigFile.html#Identity">role accounts</a>, <a href="Chroot.html">chroots</a>, and <a href="Logging.html">logging directories</a>.

<p><a name="VirtualHosts"></a>
<b><code><VirtualHost></code>s</b><br>
When configuration a <code><VirtualHost></code>, 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
<code><VirtualHost></code> configuration, there is the possibility that
that DNS name will resolve to an IP address of another virtual host in the
configuration.

<p><a name="ResourceLimits"></a>
<b>Resource Limits</b><br>
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
<code>proftpd</code> daemon.  There are different configuration directives for
doing so, depending on the situation:
<ul>
  <li><code>MaxInstances</code>: Limits the overall number of connections<br>
  <br>

  <li><code>MaxClients</code>: Limits the number of connections on a per-server/vhost basis<br>
  <br>

  <li><code>MaxClientsPerHost</code>: Limits the number of clients that may be connecting from the same host<br>
  <br>

  <li><code>MaxClientsPerUser</code>: Limits the number of clients that may be logged in at one time using the same username<br>
  <br>

  <li><code>MaxHostsPerUser</code>: Limits the number of hosts from which clients may be logged in at one time using the same username<br>
</ul>

<p>
If you are using a <code>ServerType</code> of <code>inetd</code>, then you
should be aware of the default concurrency limits in <code>inetd</code> (see
<a href="http://bugs.proftpd.org/show_bug.cgi?id=1243">Bug#1243</a>).  For
<code>xinetd</code>, the <code>per_source</code> and <code>cps</code>
attributes can be used to configure concurrency limits.  For a
<code>ServerType</code> of <code>standalone</code>, the
<code>MaxConnectionRate</code> configuration directive can be used to provide
connection limitations.

<p>
Intensive use of CPU and/or memory by FTP sessions can be restricted by use
of <code>RLimitCPU</code> and <code>RLimitMemory</code>.  Here's an example:
<pre>
  RLimitCPU session 10
  RLimitMemory session 4096
</pre>
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:
<pre>
  RLimitMemory daemon 8192 max
</pre>
In general, one should not set an <code>RLimitCPU</code> limit on the daemon,
as a long-lived daemon (as all should be) will eventually encounter such a
limit.  <b>Note</b>: appropriate settings to use will vary from site to site -
<i>do not blindly copy these examples</i>.

<p>
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 <a href="Globbing.html">mini-HOWTO</a> discusses, in-depth,
the defenses against globbing attacks that ProFTPD provides.

<p>
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 <code>MaxRetrieveFileSize</code> and
<code>MaxStoreFileSize</code> configuration directives are provided.

<p>
There are also several third-party modules that can add various resource
limiting abilities to a <code>proftpd</code> server:
<ul>
  <li><a href="http://www.castaglia.org/proftpd/modules/mod_diskuse.html">mod_diskuse</a>
  <li><a href="../contrib/mod_load.html">mod_load</a>
  <li><a href="../contrib/mod_quotatab.html">mod_quotatab</a>
</ul>

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

<p>
On systems which support the /proc filesystem, such as Linux and several others,
it is <b>highly recommended</b> 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 <code>proftpd.conf</code>:
<pre>
  <Directory /proc>
    <Limit ALL>
      DenyAll
    </Limit>
  </Directory>
</pre>

<p><a name="PerformanceTuning"></a>
<b>Performance Tuning</b><br>
When configuring a <code>proftpd</code> for performance, here are some
settings to try.  First, make sure that you have <code>ident</code> and
reverse DNS lookups disabled:
<pre>
  IdentLookups off
  UseReverseDNS off
</pre>
By default, both are done for each new FTP session, and, depending on the
response time from both <code>identd</code> and DNS servers, this can add
a noticeable delay during the login process.

<p>
Another possible source of delays during the login process is a very large
<code>/etc/passwd</code> file (a large <code>/etc/group</code> 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 <code>mod_sql</code> and <code>mod_ldap</code> modules
provided with ProFTPD can be used for storing such information in SQL tables
or LDAP servers.

<p>
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
<code>proftpd.conf</code>:
<pre>
  <IfModule mod_auth_pam.c>
    AuthPAM off
  </IfModule>
</pre>

<p>
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:
<pre>
  ListOptions +R strict
</pre>
This setting blocks the use of the <code>-R</code> option, which is how clients
request recurse directory listings.  The <em>strict</em> keyword prevents
client options from overriding the <code>proftpd.conf</code> setting.  Also,
new in <code>1.2.9rc1</code> are some <code>ListOptions</code> options
that allow recursive directory listings, but can be used to set limits on
the recursion:
<pre>
  ListOptions "" maxdepth 3
  ListOptions "" maxdirs 10
  ListOptions "" maxfiles 1000
</pre>
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.

<p>
Another way to speed up directory listings to disable proftpd's checking
for <code>.ftpaccess</code> files in every directory encountered.  To do
this, use:
<pre>
  AllowOverride off
</pre>
This disable's <code>proftpd</code>'s honouring of <code>.ftpaccess</code>
files.  How does this reduce disk I/O?  In order to properly process
<code>.ftpaccess</code> files, the daemon has to check for such a file in
each and every directory when performing an operation in that directory,
<i>each time an operation is requested</i> (it's possible for a
<code>.ftpaccess</code> 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.

<p>
The type of logging also has an impact, performance-wise.  By default,
a <code>proftpd</code> daemon logs using <code>syslog</code>;
<code>syslogd</code>, 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 <code>ServerLog</code> and/or <code>SystemLog</code> directives
can reduce this bottleneck.  Also, depending on the type of authentication
done, disabling <code>utmp/wtmp</code> logging can reduce overhead:
<pre>
  WtmpLog off
</pre>
for <code><VirtualHost></code>s that only allow anonymous logins, or
that authenticate non-<code>/etc/passwd</code> accounts, helps to reduce
the amount of unnecessary "clutter" in the <code>utmp/wtmp</code> 
log files.

<p>
If your <code>proftpd</code> server is on a high-bandwidth Internet link,
it may benefit from tuning the size of <b>kernel</b>-level (as opposed
to <b>application</b>-level) socket buffers used when transferring data.
The
<a href="../modules/mod_core.html#SocketOptions"><code>SocketOptions</code></a> configuration directive can be used to specify larger buffer sizes:
<pre>
  # 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
</pre>
Again, these are example numbers, and should <b>not be blindly copied</b>.

<p>
Finally, there are some <code>configure</code> options that can be used
to tune your <code>proftpd</code> daemon.  All of the
<code>--enable-</code> options are available; of particular interest
are <code>--enable-buffer-size</code> and
<code>--enable-sendfile</code>.  Use of the <code>sendfile(2)</code> function
(via the latter <code>configure</code> option) may or may not increase
download speeds, but it will reduce disk I/O: <code>sendfile(2)</code>
implements zero-copy transfers, meaning that the kernel will read data
directly from the file into the socket, all in kernel space; normal
<code>read()</code> 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
<code>--enable-buffer-size</code> 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).

<p><a name="ConfigDelegation"></a>
<b>Configuration Delegation</b><br>
A configuration is considered "delegated" when the
<code>Include</code> configuration directive is used in
<code>proftpd.conf</code> 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 <code>Include</code>d file.  <b>If possible, avoid this</b>.

<p>
Here's why: by delegating a configuration, you are trusting someone else with
a great deal of possible control over the daemon.  A given
<code><VirtualHost></code> section can have an <code>AuthUserFile</code>.
In that <code>AuthUserFile</code>, 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 <code>AuthUserFile</code>s (and
<code>AuthGroupFile</code>s).  There are a couple of ways of handling this
situation.  First, the daemon administrator can make sure that any
<code>Include</code> directives occur as early as possible in the
<code>proftpd.conf</code> file.  Most configuration directives in the
<code>Include</code>d file can be overridden by setting the directive again,
after the <code>Include</code>, in the main <code>proftpd.conf</code>.

<p>
The <a href="../modules/mod_auth_file.html"><code>mod_auth_file</code></a>
module, now part of the core distribution, was developed specifically to
provide finer control over the contents of <code>AuthUserFile</code> and
<code>AuthGroupFile</code> 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.

<p><a name="Miscellaneous"></a>
<b>Miscellaneous</b><br>
For the security-wary administrator, there are a few more directives that
may be of interest: <a href="../modules/mod_auth.html#AnonRejectPasswords"><code>AnonRejectPasswords</code></a>,
which configures a regular expression that matches and blocks scripted FTP
clients that try to find and exploit ill-configured anonymous FTP sites, and
<a href="../modules/mod_auth.html#RootRevoke"><code>RootRevoke</code></a>,
which causes <code>proftpd</code> to drop root privileges completely (read the
description for details).

<p>
<hr>
<font size=2><b><i>
© Copyright 2017 The ProFTPD Project<br>
 All Rights Reserved<br>
</i></b></font>
<hr>

</body>
</html>