mod_delay
The mod_delay module is designed to make a certain type of
information leak, known as a "timing attack", harder.
When proftpd processes the USER and PASS
FTP commands from a client, it has to perform checks against configured
ACLs, look up user and group information, etc. These checks are not done
if the given username is known to not exist for the server, in order to
not tie up system resources needlessly. However, this does mean that more
work is done when handling "good" users than when handling
"bad" users. This difference can be detected in the time it takes
for proftpd to send a response to the USER and
PASS commands. This means it is possible for an attacker
to look for these statistical timing differences, and determine which
users are "good" and which are "bad". From there,
a determined attacker can focus their attention on the known good usernames.
Note that the timings will vary depending on server load, number of
users in the user base, type of storage of user data (e.g.
LDAP directories, SQL tables, RADIUS servers, flat files, etc).
The mod_delay module attempts to prevent such timing differences
by keeping track of the time taken to process the USER and
PASS commands. It does this for the most recent
USER and PASS commands. The timing data are
stored in the module's DelayTable. If the module detects
that proftpd has not taken enough time to handle one of these
commands, compared to its past response times, a small delay will be added
to the response cycle. The amount of delay is determined by the difference
between the current time spent handling the command and the median time
spent handling the same command in the past.
The most current version of mod_delay can be found in the
ProFTPD source distribution:
http://www.proftpd.org/
2004-10-18: Thanks to Michael Renner for testing out various versions of the module as it was developed.
The DelayControlsACLs directive configures access lists of
users or groups who are allowed (or denied) the ability to
use the actions implemented by mod_delay. The default
behavior is to deny everyone unless an ACL allowing access has been explicitly
configured.
If "allow" is used, then list, a comma-delimited list
of users or groups, can use the given actions; all
others are denied. If "deny" is used, then the list of
users or groups cannot use actions all others are
allowed. Multiple DelayControlsACLs directives may be used to
configure ACLs for different control actions, and for both users and groups.
The DelayEngine directive enables or disables the module's
runtime delaying calculations. If it is set to off this module
does no delaying. Use this directive to disable the module.
Example:
<IfModule mod_delay.c>
DelayEngine off
</IfModule>
The DelayTable directive configures a path to a file
that mod_delay uses for storing its timing data. The given
path must be an absolute path. It is recommended that this file
not be on an NFS mounted partition.
Note that timing data is kept across daemon stop/starts. When new
<VirtualHost>s are added to the configuration, though,
mod_delay will detect that it does not have a suitable
DelayTable for the new configuration, and will clear all
stored data.
delay info
The delay info control action can be used to view the timing
data currently stored in the DelayTable file. This can help
to determine why the mod_delay module might be adding
longer-than-expected delays to the login sequence for FTP sessions.
delay reset
The delay reset control action can be used to clear the
DelayTable of all timing information, resetting the table.
This can be used if the table starts to collect delays that are too long
to be useful.
mod_delay module is compiled by default.