mod_auth
mod_auth.c
file for
ProFTPD 1.3.x, and is compiled by default.
<VirtualHost>
, <Global>
The AllowChrootSymlinks
directive configures whether
proftpd
will follow a symlink to the destination directory
when performing a chroot(2)
call. This applies both to
DefaultRoot
directives and to
<Anonymous>
sections.
Security note: If you permit your users the ability to remove
directories which might be FTP users' home directories (or
<Anonymous>
directories) and create symlinks, then you
should use:
AllowChrootSymlinks offThis includes sites which are hosting providers, i.e. which allow users to run their untrusted webapps (e.g. PHP, Perl, Ruby, Python, etc apps) on the servers.
<VirtualHost>
, <Global>
The CreateHome
directive configures the server to automatically
create a user's home directory, if that directory does not exist, during the
login process.
The mode parameter is used to configure the absolute mode of the home directory created. If not specified, the mode will default to 700.
The optional skel path parameters can be used to configure an
/etc/skel
-like directory containing account initialization files
and directories. The parameter must be the full path to the skeleton directory.
The directory must not be world-writeable. Files copied from this
directory into the new home directory will have ownership set to the UID and
GID of the logging-in user. Note that sockets and FIFOs in the skeleton
directory will not be copied; any setuid or setgid bits on files will be
removed from the copied files in the target home directory.
The optional dirmode parameter can be used to specify the mode for intermediate directories that may need to be created in order to create the target home directory. By default, the mode for such intermediate directories will be 711. Note: using a mode that does not include the execute bit to be enabled can cause havoc. You have been warned.
Examples:
# Use the CreateHome default settings CreateHome on # Specify a skeleton directory CreateHome on skel /etc/ftpd/skel # No skeleton, but make sure that intermediate directories have 755 # permissions. CreateHome on dirmode 755 # Skeleton directory, with 700 intermediate directories CreateHome on skel /etc/ftpd/skel dirmode 700
A fuller description of the CreateHome
directive and its uses,
with more examples, can be read here.
<VirtualHost>
, <Global>
The DefaultRoot
directive is used to chroot()
the
session process for the connecting client. A fuller explanation can be
found in the Chroot howto.
<VirtualHost>
, <Global>
The MaxLoginAttempts
directive configures the maximum number of
times a client may attempt to authenticate to the server on the same TCP
connection. After the number of attempts exceeds the configured
count, the client is disconnected and an appropriate message is
logged.
<VirtualHost>
, <Global>
, <Anonymous>
The RequireValidShell
directive configures the server, virtual
host or anonymous login to allow or deny logins which do not have a shell
listed in /etc/shells
. By default, proftpd
will not allow a login unless the user's default shell is listed in
/etc/shells
. If /etc/shells
cannot be found, all
default shells are assumed to be valid.
<VirtualHost>
, <Global>
Module: mod_auth
The RewriteHome
directive can be used to support rewriting the
home directory for a user, based on regular expression rules. One such use
case is where some portion of the home directory is retrieved e.g.
from an LDAP directory, but you need to apply some custom prefix to the LDAP
attribute. Note that this feature requires that the
mod_rewrite
module also be present in your proftpd
daemon.
To enable this feature, first you need to add the following to your
proftpd.conf
:
RewriteHome onNext, you need to configure the mod_rewrite rules for rewriting your home directory; this feature depends on the
mod_rewrite
module for the
rewriting. The pseudo-command used by mod_rewrite
for rewriting
home directories is "REWRITE_HOME". Thus would you use:
<IfModule mod_rewrite.c> RewriteEngine on RewrlteLog /path/to/rewrite.log RewriteCondition %m REWRITE_HOME RewriteRule (.*) /my/new/prefix$1 </IfModule>
<VirtualHost>
, <Global>
, <Anonymous>
Normally, proftpd
does not allow root logins under any
circumstance. If a client attempts to login as root, using the correct
password, a special security message is logged:
SECURITY VIOLATION: root login attempted.When
RootLogin on
is used, the root user may authenticate just as
any other user could (assuming no other access control measures deny
access); however the root login security message is still logged:
ROOT FTP login successful.Obviously, extreme care should be taken when using this directive.
The use of RootLogin
in the <Anonymous>
context is only valid when the User
/Group
defined
in the <Anonymous>
section is set to 'root'.
<VirtualHost>
, <Global>
, <Anonymous>
The RootRevoke
directive causes all root privileges to be dropped
once a user is authenticated. This will also cause active data transfers
(e.g. via the PORT
/EPRT
FTP commands) to be
disabled if the server is listening on a port less than 1024. Note that
this only affects active data transfers; passive transfers will not be
blocked.
The reason for rejecting active data transfers in these cases is because of a requirement in RFC 959 (which defines the File Transfer Protocol) that for active data transfers, the data connection must have a source port of L-1, where L is the control connection port (see RFC 959, Section 3.2 "Establishing Data Connections"). Thus if the FTP server listens on port 21, then a client requesting an active data transfer from that server will have a data connection whose source port (on the server) is port 20 (L = 21, L-1 = 20).
Even though passive data transfers are highly preferable, many FTP clients may still require/expect to be able to do an active data transfer. One question, though, is how many FTP clients actually check that the source port of the active data transfer connection is actually L-1. Or how many networking appliances along the way (i.e. firewalls, NATs, routers, etc) enforce this restriction as well.
If not for that requirement, then with "RootRevoke on" in the
proftpd.conf
, proftpd
would not be required
to use root privileges for binding to a privileged port like port 20.
Thus the RootRevoke
directive also accepts (as of proftpd-1.3.5rc1
) a parameter of "UseNonCompliantActiveTransfers", e.g.:
# Drop root privs, but allow active data tranfers (only use a non-standard # source port for the active data connection). RootRevoke UseNonCompliantActiveTranfersWith this configuration,
proftpd
will drop root privileges,
but would not reject PORT
/EPRT
commands at all. Instead, the active data transfers would be allowed as per
normal, except that proftpd
would not try to bind to the
L-1 port for those active transfers.
This RootRevoke
parameter is valuable because it helps in
getting proftpd
to drop root privileges for sessions more often,
which is a far more secure configuration. Exploits such as the
"Roaring Beast" attack would not be possible in a session where root privileges
have been dropped completely.
<VirtualHost>
, <Global>
The TimeoutLogin
directive configures the maximum number of
seconds a client is allowed to spend authenticating, i.e.
from the time when the client connects to the time when the client has
successfully authenticated. The login timer is not reset when a client
transmits data, and is only removed once a client has transmitted an
acceptable combination of USER
/PASS
commands.
The maximum allowed seconds value is 65535 (108 minutes).
See also: TimeoutIdle
,
TimeoutNoTransfer
,
TimeoutStalled
<VirtualHost>
, <Global>
, <Anonymous>
The TimeoutSession
directive sets the maximum number of
seconds a control connection between the proftpd server and client
can exist, after the client has successfully authenticated. If the
seconds argument is set to zero, sessions are allowed to last
indefinitely; this is the default. There is no maxium value for the
seconds parameter.
<VirtualHost>
, <Global>
, <Anonymous>
Legacy FTP servers generally check a special authorization file (typically
/etc/ftpusers
) when a client attempts to authenticate.
If the user's name is found in this file, FTP access is
denied. For compatibility of behavior, proftpd
defaults to
checking this same file during authentication. This behavior can be suppressed
using the UseFtpUsers
directive, e.g.:
# Do not check /etc/ftpusers UseFtpUsers off
<VirtualHost>
, <Global>
, <Anonymous>
The UserPassword
directive creates a password for a particular
user; this configured password will override the user's normal
password in /etc/passwd
(or whichever auth module handles that
user). Note that the user configured is a real user, and
not a UserAlias
.
The encrypted-password parameter is a string which has been passed
through the standard Unix crypt(3)
function. Do not use a
cleartext password. To obtain this encrypted-password value,
you can use the ftpasswd
script's --hash
option, e.g.:
# ftpasswd --hash Password: Re-type password: ftpasswd: $1$EsnXxyD6$tsO2YwTAT/Tl5u1NYPHIw1
Example configuration:
# Override user bob's password with a hash version of "password" UserPassword bob $1$EsnXxyD6$tsO2YwTAT/Tl5u1NYPHIw1
mod_auth
module is compiled by default.