AccessDenyMsg [ "message"]
Default
Dependent on login type
Context
server config, <VirtualHost>, <Anonymous>, <Global>
Module
mod_auth
Compatibility
1.2.2 and later
Normally, a 530 response message is sent to an FTP client immediately after a failed authentication attempt, with a standard message indicating the the reason of failure. In the case of a wrong password, the reason is usually "Login incorrect." This message can be customized with the AccessDenyMsg directive. In the message argument, the magic cookie '%u' is replaced with the username specified by the client during login.
AccessGrantMsg [ "message"]
Default
Dependent on login type
Context
server config, <VirtualHost>, <Anonymous>, <Global>
Module
mod_auth
Compatibility
0.99.0pl5 and later
Normally, a 230 response message is sent to an FTP client immediately after authentication, with a standard message indicating that the user has either logged in or that anonymous access has been granted. This message can be customized with the AccessGrantMsg directive. In the message argument, the magic cookie '%u' is replaced with the username specified by the client during login.
Allow [ ["from"] "all"|"none"|host|network[,host|network[,...]]]
Default
Allow from all
Context
<Limit>
Module
mod_core
Compatibility
0.99.0pl6 and later
The Allow directive is used inside a <Limit> context to explicitly specify which hosts and/or networks have access to the commands or operations being limited. Allow is typically used in conjunction with Order and Deny in order to create sophisticated (or perhaps not-so-sophisticated) access control rules. Allow takes an optional first argument; the keyword from. Using from is purely cosmetic. The remaining arguments are expected to be a list of hosts and networks which will be explicitly granted access. The magic keyword all can be used to indicate that all hosts will explicitly be granted access (analogous to the AllowAll directive, except with a lower priority). Additionally, the magic keyword none can be used to indicate that no hosts or networks will be explicitly granted access (although this does not prevent them from implicitly being granted access). If all or none is used, no other hosts or networks can be supplied. Host and network addresses can be specified by name or numeric address. For security reasons, it is recommended that all address information be supplied numerically. Relying solely on named addresses causes security to depend a great deal upon DNS servers which may themselves be vulnerable to attack or spoofing. Numeric addresses which specify an entire network should end in a trailing period (i.e. 10.0.0. for the entire 10.0.0 subnet). Named addresses which specify an entire network should begin with a leading period (i.e. .proftpd.net for the entire proftpd.net domain).
<Limit LOGIN> Order allow,deny Allow from 128.44.26.,128.44.26.,myhost.mydomain.edu,.trusted-domain.org Deny from all </Limit>
AllowAll [ AllowAll]
Default
Default is to implicitly AllowAll, but not explicitly
Context
<Directory>, <Anonymous>, <Limit>, .ftpaccess
Module
mod_core
Compatibility
0.99.0 and later
The AllowAll directive explicitly allows access to a <Directory>, <Anonymous> or <Limit> block. Although proftpd's default behavior is to allow access to a particular object, the default is an implicit allow. AllowAll creates an explicit allow, overriding any higher level denial directives.
AllowClass [ ["AND"|"OR"|"regex"] class-expression]
Default
None
Context
<Limit>
Module
mod_core
Compatibility
1.2.10rc1 and later
AllowClass specifies a class-expression that is specifically permitted access within the context of the <Limit> block it is applied to. class-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of classes or "not" classes (by prefixing a class name name with the `!' character) that are to be allowed access to the block.
By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit allow to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.
# A regular expression AllowClass directive AllowClass regex ^known # An AND-evaluated ClassUser directive DenyClass AND bad,scanner
AllowFilter [ regular-expression]
Default
None
Context
server config, <VirtualHost>, <Global>, <Anonymous>, <Directoryl>, .ftpaccess
Module
mod_core
Compatibility
1.2.0pre7 and later
AllowFilter allows the configuration of a regular expression that must be matched for all command arguments sent to ProFTPD. It is extremely useful in controlling what characters may be sent in a command to ProFTPD, preventing some possible types of attacks against ProFTPD. The regular expression is applied against the arguments to the command sent by the client, so care must be taken when creating a proper regex. Commands that fail the regex match result in a "Forbidden command" error being returned to the client. If the regular-expression argument contains whitespace, it must be enclosed in quotes.
# Only allow commands containing alphanumeric characters and whitespace AllowFilter "^[a-zA-Z0-9 ,]*$"
AllowForeignAddress [ on|off ]
Default
AllowForeignAddress off
Context
server config, <VirtualHost>, <Anonymous>, <Global>
Module
mod_core
Compatibility
1.1.7 and later
Normally, proftpd disallows clients from using the ftp PORT command with anything other than their own address (the source address of the ftp control connection), as well as preventing the use of PORT to specify a low-numbered (< 1024) port. In either case, the client is sent an "Invalid port" error and a message is syslog'd indicating either "address mismatch" or "bounce attack". By enabling this directive, proftpd will allow clients to transmit foreign data connection addresses that do not match the client's address. This allows such tricks as permitting a client to transfer a file between two FTP servers without involving itself in the actual data connection. Generally it's considered a bad idea, security-wise, to permit this sort of thing. AllowForeignAddress only affects data connection addresses; not tcp ports. There is no way (and no valid reason) to allow a client to use a low-numbered port in its PORT command.
AllowGroup [ ["AND"|"OR"|"regex"] group-expression]
Default
None
Context
<Limit>
Module
mod_core
Compatibility
1.1.1 and later
AllowGroup specifies a group-expression that is specifically permitted within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be allowed access to the block.
By default, the expression is parsed as a boolean "AND" list, meaning that ALL elements of the expression must evaluate to logically true in order to the explicit allow to apply. In order to treat the expression as a boolean "OR" list, meaning that ANY of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.
# An OR-evaluated AllowGroup directive AllowGroup OR www,doc # A regular expression DenyGroup directive DenyGroup regex ^sys
AllowLogSymlinks [ "on"|"off"]
Default
AllowLogSymlinks off
Context
server config, <VirtualHost>, <Global>
Module
mod_log
Compatibility
1.2.2rc2 and later
By default, the server will the path of any configured SystemLog, any configured TransferLogs, and any configured ExtendedLogs to see if they are symbolic links. If the paths are symbolic links, the server will refuse to log to that link unless explicitly configured to do so via this directive.
Security note: this behaviour should not be allowed unless for a very good reason. By allowing the server to open symbolic links with its root privileges, you are allowing a potential symlink attack where the server could be tricked into overwriting arbitrary system files. You have been warned.
AllowOverride [ on|off ["user"|"group"|"class" expression]]
Default
on
Context
server config, <Global>, <VirtualHost>, <Anonymous>
Module
mod_core
Compatibility
1.2.7rc1 and later
Normally, the server will look for and parse any files in the encountered directories called ".ftpaccess". The files provide a functionality similar to Apache's .htaccess files -- mini-configuration files. This directive controls when those .ftpaccess files will be parsed.
The optional parameters are used to restrict the use of .ftpaccess files only to specific users. If the "user" restriction is given, then expression is a user-expression specifying to which users the rule applies. Similarly for the "group" restriction. For the "class" restriction, the expression is simply the name of connection class for whom the rule will apply.
AllowOverwrite [ on|off]
Default
AllowOverwrite off
Context
server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>, .ftpaccess
Module
mod_xfer
Compatibility
0.99.0 and later
The AllowOverwrite directive permits newly transfered files to overwrite existing files. By default, ftp clients cannot overwrite existing files.
AllowRetrieveRestart [ on|off]
Default
AllowRetrieveRestart on
Context
server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>, .ftpaccess
Module
mod_core
Compatibility
0.99.0 and later
The AllowRetrieveRestart directive permits or denies clients from performing "restart" retrieve file transfers via the FTP REST command. By default this is enabled, so that clients may resume interrupted file transfers at a later time without losing previously collected data.
AllowStoreRestart [ on|off]
Default
AllowStoreRestart off
Context
server config, <VirtualHost>, <Anonymous>, <Directory>, <Global>, .ftpaccess
Module
mod_core
Compatibility
0.99.0 and later
The AllowStoreRestart directive permits or denies clients from "restarting" interrupted store file transfers (those sent from client to server). By default restarting (via the REST command) is not permitted when sending files to the server. Care should be taken to disallow anonymous ftp "incoming" transfers to be restarted, as this will allow clients to corrupt or increase the size of previously stored files (even if not their own).
The REST (Restart STOR) command is automatically blocked when HiddenStor is enabled, with the server returning a 501 error code to the client.
AllowUser [ ["AND"|"OR"|"regex"] user-expression]
Default
None
Context
<Limit>
Module
mod_core
Compatibility
1.1.7 and later
AllowUser specifies a user-expression that is specifically permitted access within the context of the <Limit> block it is applied to. user-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of users or "not" users (by prefixing a user name with the `!' character) that are to be allowed access to the block.
By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit allow to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.
# A regular expression AllowUser directive AllowUser regex ^ftp # An AND-evaluated DenyUser directive DenyUser AND system,test
AnonRatio [ foo1 foo2 foo3]
Default
None known
Context
<Directory>, <Anonymous>, <Limit>,.ftpaccess
Module
mod_ratio
Compatibility
at least 1.2.0 and later
AnonRejectePasswords [ regex]
Default
None
Context
<Anonymous>
Module
mod_auth
Compatibility
1.2.9rc1 and later
The AnonRejectPasswords directive configures a regular expression filter for passwords given for anonymous logins. If the given anonymous password matches the configured regular expression, the anonymous login is denied.
# Reject all <Anonymous> logins that use "evil.org" as part of the password AnonRejectPasswords @evil\.org$
AnonRequirePassword [ on|off]
Default
AnonRequirePassword off
Context
<Anonymous>
Module
mod_auth
Compatibility
0.99.0 and later
Normally, anonymous FTP logins do not require the client to authenticate themselves via the normal method of a transmitted cleartext password which is hashed and matched against an existing system user's password. Instead, anonymous logins are expected to enter their e-mail address when prompted for a password. Enabling the AnonRequirePassword directive requires anonymous logins to enter a valid password which must match the password of the user that the anonymous daemon runs as. However using AuthUsingAlias authentication can be matched against the password of the login username. This can be used to create "guest" accounts, which function exactly as normal anonymous logins do (and thus present a "chrooted" protected file system to the client), but require a valid password on the server's host system.
Example of a "guest" account configuration: <Anonymous ~roger> User roger Group other UserAlias proftpd roger AnonRequirePassword on # Deny write operations to all directories, underneath root-dir # Default is to allow, so we don't need a <Limit> for read operations. <Directory *> <Limit WRITE> DenyAll </Limit> </Directory> # Deny all read/write operations in incoming. Because these are command-group # limits, we can explicitly permit certain operations which will take precedence # over our group limit. <Directory incoming> <Limit READ WRITE> DenyAll </Limit> # The only command allowed in incoming is STOR (transfer file from client to server) <Limit STOR> AllowAll </Limit> </Directory> </Anonymous>
Anonymous [ root-directory]
Default
None
Context
server config,<VirtualHost>, <Global>
Module
mod_core
Compatibility
0.99.0 and later
The Anonymous configuration block is used to create an anonymous FTP login, and is terminated by a matching </Anonymous> directive. The root-directory parameters specifies which directory the daemon will first chdir to, and then chroot, immediately after login. Once the chroot operation successfully completes, higher level directories are no longer accessible to the running child daemon (and thus the logged in user). By default, proftpd assumes an anonymous login if the remote client attempts to login as the currently running user; unless the current user is root, in which case anonymous logins are not allowed regardless of the presence of an <Anonymous> block. To force anonymous logins to be bound to a user other than the current user, see the User and Group directives. In addition, if a User or Group directive is present in an <Anonymous> block, the daemon permanently switches to the specified uid/gid before chroot()ing. Normally, anonymous logins are not required to authenticate with a password, but are expected to enter a valid e-mail address in place of a normal password (which is logged). If this behavior is undesirable for a given <Anonymous> configuration block, it can be overridden via the AnonRequirePassword directive.
Note: Chroot()ed anonymous directories do not need to have supplemental system files in them, nor do they need to have any sort of specific directory structure. This is because proftpd is designed to acquire as much system information as possible before the chroot, and to leave open those files which are needed for normal operation and reside outside the new root directory.
Example of a typical anonymous FTP configuration:
<Anonymous /home/ftp>
# After anonymous login, daemon runs as user/group ftp.
User ftp
Group ftp
# The client login 'anonymous' is aliased to the "real" user 'ftp'.
UserAlias anonymous ftp
# Deny write operations to all directories, except for 'incoming' where
# 'STOR' is allowed (but 'READ' operations are prohibited)
<Directory *>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
<Directory incoming>
<Limit READ >
DenyAll
</Limit>
<Limit STOR>
AllowAll
</Limit>
</Directory>
</Anonymous>AnonymousGroup [ group-expression]
Default
None
Context
server config, <VirtualHost>, <Global>
Module
mod_core
Compatibility
1.1.3 and later
The AnonymousGroup directive specifies a group-expression to which all matching users will be considered anonymous logins. The group-expression argument is a boolean logically ANDed list of groups to which the user must be a member of (or non-member if the group name is prefixed with a `!' character). For more information on group-expressions see the DefaultRoot directive. If the authenticating user is matched by an AnonymousGroup directive, no valid password is required, and a special dynamic anonymous configuration is created, with the user's home directory as the default root directory. If a DefaultRoot directive also applies to the user, this directory is used instead of the user's home dir. Great care should be taken when using AnonymousGroup, as improper configuration can open up user home directories to full read/write access to the entire world.
AuthAliasOnly [ on|off]
Default
AuthAliasOnly off
Context
server config, <VirtualHost>, <Anonymous>, <Global>
Module
mod_auth
Compatibility
1.1.3 and later
AuthAliasOnly restricts authentication to "aliased" logins only; i.e. those usernames provided by clients which are "mapped" to a real userid by the UserAlias directive. Turning AuthAliasOnly `on' in a particular context will cause proftpd to completely ignore all non-aliased logins for the entire context. If no contexts are available without AuthAliasOnly set to `on', proftpd rejects the client login and sends an appropriate message to syslog.
AuthGroupFile [ path]
Default
None
Context
server config, <VirtualHost>, <Global>
Module
mod_auth_file
Compatibility
1.0.3/1.1.1 and later
AuthGroupFile specifies an alternate groups file, having the same format as the system /etc/group file, and if specified is used during authentication and group lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthGroupFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthUserFile).
Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.
AuthOrder [ module-name...]
Default
None
Context
server config, <VirtualHost>, <Global>
Module
mod_core
Compatibility
1.2.8rc1 and later
The AuthOrder directive configures the names of auth modules, and the order in which they will be checked when authenticating a user.
At least one module name must be given; there is no maximum number of modules that can be listed. The listed module names must the full name of the source file, e.g. "mod_auth_unix.c". To see a full list of module names, use "proftpd -l". Do not use "mod_auth.c", as that module is the authentication front end module, and is necessary. Also, do not use "mod_auth_pam.c", as that module does not provide, by itself, all of the information proftpd needs.
# Use only AuthUserFiles when authenticating, and not the system's /etc/passwd AuthOrder mod_auth_file.c
# If the user's information is not in LDAP, they're not a user to use # this server. AuthOrder mod_ldap.c
# Use SQL tables first, then LDAP, for authentication AuthOrder mod_sql.c mod_ldap.c
AuthPAM [ on|off]
Default
on
Context
server config,<VirtualHost>, <Global>
Module
mod_auth_pam
Compatibility
1.2.0rc1 and later
This directive determines whether PAM is used as an authentication method by ProFTPD. Enabled by default to fit in with the design policy of using PAM as the primary authentication mechanism.
AuthPAMConfig [ service]
Default
ftp
Context
server config,<VirtualHost>, <Global>
Module
mod_auth_pam
Compatibility
1.2.0rc1 and later
This directive allows you to specify the PAM service name used in authentication. PAM allows you to specify a service name to use when authenticating. This allows you to configure different PAM service names to be used for different virtual hosts. The directive was renamed from PAMConfig post 1.2.0 pre10.
# Virtual host foobar authenticates differently than the rest AuthPAMConfig foobar # This assumes, that you have a PAM service named foobar # configured in your /etc/pam.conf file or /etc/pam.d directory.
AuthUserFile [ path]
Default
None
Context
server config,<VirtualHost>, <Global>
Module
mod_auth_file
Compatibility
1.0.3/1.1.1 and later
AuthUserFile specifies an alternate passwd file, having the same format as the system /etc/passwd file, and if specified is used during authentication and user lookups for directory/access control operations. The path argument should be the full path to the specified file. AuthUserFile can be configured on a per-VirtualHost basis, so that virtual FTP servers can each have their own authentication database (most often used in conjunction with AuthGroupFile).
Note that this file need not reside inside a chroot()ed directory structure for Anonymous or DefaultRoot logins, as it is held open for the duration of client connections.
AuthUsingAlias [ on|off]
Default
AuthUsingAlias off
Context
<Anonymous>
Module
mod_auth
Compatibility
1.2.0pre9 and later
AuthUsingAlias disables the resolving of mapped usernames for authentication purposes. For example, if you have mapped the username anonymous to the "real" user ftp, the password gets checked against the user "anonymous". When AuthUsingAlias is disabled, the checked username would be "ftp".
An example of an Anonymous configuration using
AuthUsingAlias
# Basic Read-Only Anonymous Configuration.
<Anonymous /home/ftp>
UserAlias anonymous nobody
UserAlias ftp nobody
AuthAliasOnly on
<Limit WRITE>
DenyAll
</Limit>
</Anonymous>
# Give Full Read-Write Anonymous Access to certain users
<Anonymous /home/ftp>
AnonRequirePassword on
AuthAliasOnly on
AuthUsingAlias on
# The list of authorized users.
# user/pass lookup is for each user, not password entry
# of server uid ('nobody' in this example).
UserAlias fred nobody
UserAlias joe nobody
<Limit ALL>
AllowAll
</Limit>
</Anonymous>Bind [ IP address]
Default
None
Context
server config, <VirtualHost>
Module
mod_core
Compatibility
1.1.6 - 1.3.0rc1
Cause of too much confusion this directive has been deprecated with Proftpd 1.3.0rc1. Please take a look at the VirtualHost and DefaultAddress directive. The Bind directive allows additional IP addresses to be bound to a main or VirtualHost configuration. Multiple Bind directives can be used to bind multiple addresses. The address argument should be either a fully qualified domain name or a numeric dotted-quad IP address. Incoming connections destined to an additional address added by Bind are serviced by the context containing the directive. Additionally, if SocketBindTight is set to on, a specific listen connection is created for each additional address.
ByteRatioErrMsg [ foo1 foo2 foo3]
Default
None known
Context
<Directory>, <Anonymous>, <Limit>,.ftpaccess
Module
mod_ratio
Compatibility
at least 1.2.0 and later
CapabilitiesEngine [ on
off]
Default
CapabilitiesEngine On, if running on a Linux hosts that supports capabilities
Context
server config, <VirtualHost>, <Global>
Module
mod_cap
Compatibility
1.2.8rc1 and later
The CapabilitiesEngine directive enables or disables the module's runtime capabilities engine. If set to off, this module does no runtime capabilities processing at all. Use this directive to disable the module.
CapabilitiesSet [ [+/-]capability...]
Default
CapabilitiesSet +CAP_CHOWN
Context
server config, <VirtualHost>, <Global>
Module
mod_cap
Compatibility
1.2.8rc1 and later
By default, mod_cap removes all but two capabilities from the session-handling process: CAP_NET_BIND_SERVICE, for binding to ports lower than 1024 (required for active data transfers), and CAP_CHOWN, for allowing a process to change a file's ownership to a different user. The latter capability is only strictly necessary if the UserOwner configuration directive is in use; if not being used, the CAP_CHOWN capability is best removed. The CapabilitiesSet directive is used to manipulate the set of capabilities that mod_cap grants.
To remove a capability, prefix the name with a '-'; to enable a capability, use '+'. At present, this directive only supports one capability: CAP_CHOWN.
CDPath [ directory]
Default
None
Context
server config, <VirtualHost>, <Anonymous>, <Global>
Module
mod_core
Compatibility
1.2.0pre2 and later
Adds an entry to a search path that is used when changing directories. For example: CDPath /home/public CDPath /var/devel This allows a user to cd into any directory directly under /home/public or /var/devel, provided they have the appropriate rights. So, if /home/public/proftpd exists, cd proftpd will bring the user to that directory, regardless of where they currently are in the directory tree.
VirtualHost [ <Class name>]
Default
None
Context
server config
Module
mod_core
Compatibility
1.2.10rc1 and later
When configuring proftpd, it is sometimes nice, or even necessary, to tag or label a client as belonging to some group, based on that client's IP address or DNS hostname. A "class" is the name for such connection-based groupings in ProFTPD terms. A class is defined to have a name, and as having certain criteria such as IP addresses, IP subnets/masks, and DNS hostnames. A client that connects to the daemon that has matching characteristics is then labeled as belonging to that class.
Within a <Class> section, the From directive is used to list the IP addresses, IP subnet/masks, and DNS names that make up the class.
From 192.168.0.0/16
This defines a class named "internal"; any client connecting from 192.168.0.0/16 will belong to this class. And if you wanted to define a class for all clients not connecting from 192.168.0.0/16 address space:
From !192.168.0.0/16
A more complicated class might include matching DNS names as well:
From 1.2.3.4 From proxy.*.com From my.example.com From 5.6.7.8
CommandBufferSize [ size]
Default
512
Context
server config, <VirtualHost>, <Global>
Module
mod_core
Compatibility
1.2.0pre7 and later
The CommandBufferSize directive controls the maximum command length permitted to be sent to the server. This allows you to effectively control what the longest command the server may accept it, and can help protect the server from various Denial of Service or resource-consumption attacks.
CreateHome [ off|on [<mode>] [skel <path>] [dirmode <mode>]]
Default
None
Context
server config, <VirtualHost>, <Global>
Module
mod_auth
Compatibility
1.2.8rc2 and later
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 module will default to 700.
The optional skel path parameter 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 directory. The directory must not be world-writeable. Files copied from this directory into the new home directory will have 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 allow for the execute bit to be enabled can cause havoc. You have been warned.
# 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
CwdRatioMsg [ foo1 foo2 foo3]
Default
None known
Context
<Directory>, <Anonymous>, <Limit>,.ftpaccess
Module
mod_ratio
Compatibility
at least 1.2.0 and later
DebugLevel [ level]
Default
DebugLevel 0
Context
server config, <VirtualHost>, <Global>
Module
mod_core
Compatibility
1.2.8rc1 and later
The DebugLevel directive configures the debugging level the server will use when logging. The level parameter must be between 0 and 9. This configuration directive will take precedence over any command-line debugging options used.
DefaultAddress [ dns-names|ip-addresses seperated with spaces]
Default
none
Context
server config
Module
mod_core
Compatibility
1.2.7rc1 and later
This directive sets the the address the main server instance will bind to, the default behaviour is to select whatever IP the system reports as being the primary IP.
Starting with Proftpd 1.3.0rc1 it's possible to use more than one FQDN or IP Address. With this change the old Bind directive has been deprecated.
ServerName "Default FTP Server"
Port 21
# We want the main server instance to listen on a specific IP
DefaultAddress 192.168.10.30
## Since 1.3.0rc1 it's also possible to use the following:
# DefaultAddress 192.168.10.30 my.domain.tld
DefaultChdir [ directory [group-expression]]
Default
~
Context
server config, <VirtualHost>, <Anonymous>, <Global>
Module
mod_auth
Compatibility
1.2.0pre2 and later
Determines the directory a user is placed in after logging in. By default, the user is put in their home directory. The specified directory can be relative to the user's home directory. NOTE: If the specified directory is not available then DefaultChdir is treated as if it wasn't there in the first place. In particular, in this case the directory a user is placed in after logging in is determined by the other settings in proftpd.conf.
DefaultRoot [ directory [group-expression]]
Default
DefaultRoot /
Context
server config, <VirtualHost>, <Global>
Module
mod_auth
Compatibility
0.99.0pl7 and later
The DefaultRoot directive controls the default root directory assigned to a user upon login. If DefaultRoot is set to a directory other than "/", a chroot operation is performed immediately after a client authenticates. This can be used to effectively isolate the client from a portion of the host system filespace. The specified root directory must begin with a / or can be the magic character '~'; meaning that the client is chroot jailed into their home directory.
When the specified chroot directory is a symlink this will be resolved to it's parent first before setting up the chroot. This can have unwanted side effects. For example if a user has write access to the symlink he could modify it so that it points to '/'. Thus the chroot would be the root directory of the server, resulting in insufficient or no restrictions.
If the DefaultRoot directive specifies a directory which disallows access to the logged-in user's home directory, the user's current working directory after login is set to the DefaultRoot instead of their normal home directory. DefaultRoot cannot be used in <Anonymous> configuration blocks, as the <Anonymous> directive explicitly contains a root directory used for Anonymous logins. The special character '~' is replaced with the authenticating user's home directory immediately after login. Note that the default root may be a subdirectory of the home directory, such as "~/anon-ftp".
The optional group-expression argument can be used to restrict the DefaultRoot directive to a unix group, groups or subset of groups. The expression takes the format: [!]group-name1[,[!]group-name2[,...]]. The expression is parsed in a logical boolean AND fashion, such that each member of the expression must evaluate to logically TRUE in order for the DefaultRoot directive to apply. The special character '!' is used to negate group membership.
Care should be taken when using DefaultRoot. Chroot "jails" should not be used as methods for implementing general system security as there are potentially ways that a user can "escape" the jail.
Example of a DefaultRoot configuration: ServerName "A test ProFTPD Server" ServerType inetd User ftp Group ftp # # This causes proftpd to perform a chroot into the authenticating user's directory # immediately after login. # Once this happens, the user is unable to "see" higher level directories. # Because a group-expression is included, only users who are a member of # the group 'users' and NOT a member of 'staff' will have their default # root directory set to '~'. DefaultRoot ~ users,!staff ...
DefaultServer [ on|off]
Default
DefaultServer off
Context
server config,<VirtualHost>
Module
mod_core
Compatibility
0.99.0pl6 and later
The DefaultServer directive controls which server configuration is used as the default when an incoming connection is destined for an IP address which is neither the host's primary IP address or one of the addresses specified in a <VirtualHost> configuration block. Normally such "unknown" connections are issued a "no server available to service your request" message and disconnected. When DefaultServer is turned on for either the primary server configuration or a virtual server, all unknown destination connections are serviced by the default server. Only a single server configuration can be set to default.
DefaultTransferMode [ ascii|binary]
Default
DefaultTransferMode ascii
Context
server config, <VirtualHost>, <Global>
Module
mod_core
Compatibility
1.2.0pre9 and later
DefaultTransferMode sets the default transfer mode of the server. By default, carriage-return/linefeed translation will be performed (ASCII mode).
DeferWelcome [ DeferWelcome on|off]
Default
DeferWelcome off
Context
server config, <VirtualHost>, <Global>
Module
mod_core
Compatibility
0.99.0 and later
The DeferWelcome directive configures a master or virtual server to delay transmitting the ServerName and address to new connections, until a client has successfully authenticated. If enabled, the initial welcome message will be exceedingly generic and will not give away any type of information about the host that the daemon is actively running on. This can be used by security-conscious administrators to limit the amount of "probing" possible from non-trusted networks/hosts.
Define [ parameter-name]
Default
none
Context
any context
Module
mod_core
Compatibility
1.2.6rc1 and later
This directive is used to initialise defines for use in conjunction with the IfDefine directive
DelayEngine [ on|off ]
Default
DelayEngine on
Context
server config
Module
mod_delay
Compatibility
1.3.0rc1 and later
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.
DelayTable [ path ]
Default
DelayTable var/proftpd/proftpd.delay
Context
server config
Module
mod_delay
Compatibility
1.3.0rc1 and later
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.
DeleteAbortedStores [ DeleteAbortedStores on|off]
Default
off
Context
server, <VirtualHost>, <Directory>, <Anonymous>, <Global>, .ftpaccess
Module
mod_xfer
Compatibility
1.2.0rc2 and later
The DeleteAbortedStores directive controls whether ProFTPD deletes partially uploaded files if the transfer is stopped via the ABOR command rather than a connection failure.
Deny [ Deny ["from"] "all"|"none"|host|network[,host|network[,...]]]
Default
None
Context
<Limit>
Module
mod_core
Compatibility
0.99.0pl6 and later
The Deny directive is used to create a list of hosts and/or networks which will explicitly be denied access to a given <Limit> context block. The magic keywords "ALL" and "NONE" can be used to indicate that all hosts are denied access, or that no hosts are explicitly denied (respectively). For more information on the syntax and usage of Deny see: Allow and Order.
DenyAll [ DenyAll]
Default
None
Context
<Directory>, <Anonymous>, <Limit>, .ftpaccess
Module
mod_core
Compatibility
0.99.0 and later
The DenyAll directive is analogous to a combination of "order deny,allow <cr> deny from all", with the exception that it has a higher precedence when parsed. It is provided as a convenient method of completely denying access to a directory, anonymous ftp or limit block. Because of its precedence, it should not be intermixed with normal Order/Deny directives. The DenyAll directive can be overridden at a lower level directory by using AllowAll. DenyAll and AllowAll are mutually exclusive.
DenyClass [ ["AND"|"OR"|"regex"] class-expression]
Default
None
Context
<Limit>
Module
mod_core
Compatibility
1.2.10rc1 and later
DenyClass specifies a class-expression that is specifically denied access within the context of the <Limit> block it is applied to. class-expression has a similar syntax as that used in AllowGroup, in that it should contain a comma delimited list of classes or "not" classes (by prefixing a class name name with the `!' character) that are to be denied access to the block.
By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit deny to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.
# A regular expression AllowClass directive AllowClass regex ^known # An AND-evaluated ClassUser directive DenyClass AND bad,scanner
DenyFilter [ DenyFilter regular-expression]
Default
None
Context
server config, <VirtualHost>, <Global>, <Anonymous>, <Directory>, .ftpaccess
Module
mod_core
Compatibility
1.2.0pre7 and later
Similar to AllowFilter, DenyFilter specifies a regular expression which must not match any of the command arguments. If the regex does match, a "Forbidden command" error is returned to the client. This can be especially useful for forbidding certain command argument combinations from ever reaching ProFTPD.
Notes: The 'PASV' command cannot be blocked using this directive.
DenyGroup [ ["AND"|"OR"|"regex"] group-expression]
Default
None
Context
<Limit>
Module
mod_core
Compatibility
1.1.1 and later
DenyGroup specifies a group-expression that is specifically denied within the context of the <Limit> block it is applied to. group-expression has the same format as that used in DefaultRoot, in that it should contain a comma separated list of groups or "not" groups (by prefixing a group name with the `!' character) that are to be denied access to the block.
By default, the expression is parsed as a boolean "AND" list, meaning that ALL elements of the expression must evaluate to logically true in order to the explicit deny to apply. In order to treat the expression as a boolean "OR" list, meaning that ANY of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.
# An OR-evaluated AllowGroup directive AllowGroup OR www,doc # A regular expression DenyGroup directive DenyGroup regex ^sys
DenyUser [ ["AND"|"OR"|"regex"] user-expression]
Default
None
Context
<Limit>
Module
mod_core
Compatibility
1.1.7 and later
DenyUser specifies a user-expression that is specifically denied within the context of the <Limit> block it is applied to. user-expression is a comma delimited list of users or "not" users (by prefixing a user name with the `!' character).
By default, the expression is parsed as a boolean "OR" list, meaning that ANY elements of the expression must evaluate to logically true in order to the explicit deny to apply. In order to treat the expression as a boolean "AND" list, meaning that ALL of the elements must evaluate to logically true, use the optional "AND" keyword. Similarly, to treat the expression as a regular expression, use the "regex" keyword.
# A regular expression AllowUser directive AllowUser regex ^ftp # An AND-evaluated DenyUser directive DenyUser AND system,test
Directory [ <Directory pathname>]
Default
None
Context
server config, <VirtualHost>, <Anonymous>, <Global>
Module
mod_core
Compatibility
0.99.0 and later
This directive creates a block of configuration directives which applies only to the specified directory and its sub-directories. The block is ended with </Directory>. Per-directory configuration is enabled during run-time with a "closest" match algorithm, meaning that the <Directory> directive with the closest matching path to the actual pathname of the file or directory in question is used. Per-directory configuration is inherited by all sub-directories until a closer matching <Directory> is encountered, at which time the original per-directory configuration is replaced with the closer match. Note that this does not apply to <Limit> </Limit> blocks, which are inherited by all sub-directories until a <Limit> block is reached in a closer match.
A trailing slash and wildcard ("/*") can be appended to the directory, specifying that the configuration block applies only to the contents (and sub-contents), not to the actual directory itself. Such wildcard matches always take precedence over non-wildcard <Directory> configuration blocks. <Directory> blocks cannot be nested (they are automatically nested at run-time based on their pathnames). Pathnames must always be absolute (except inside <Anonymous>), and should not reference symbolic links. Pathnames inside an <Anonymous> block can be relative, indicating that they are based on the anonymous root directory.
[Notes for ProFTPD 1.1.3 and later only] Pathnames that begin with the special character '~' and do not specify a username immediately after ~ are put into a special deferred mode. When in deferred mode, the directory context is not hashed and sorted into the configuration tree at boot time, but rather this hashing is deferred until a user authenticates, at which time the '~' character is replaced with the user's home directory. This allows a global <Directory> block which applies to all user's home directories, or sub-directories thereof.
#Default usage of the directory directive
<Directory /users/robroy/private>
HideNoAccess on
</Directory>
#Example with username-expanding
<Directory ~/anon-ftp>
<Limit WRITE>
DenyAll
</Limit>
</Directory>DirFakeGroup [ DirFakeGroup On|Off [groupname]]
Default
DirFakeGroup Off
Context
server config, <VirtualHost>, <Global>, <Anonymous>, <Directory>, .ftpaccess
Module
mod_ls
Compatibility
1.1.5
DirFakeGroup can be used to hide the true group of files (including directories, fifos, etc.) in a directory listing. If simply turned On, DirFakeGroup will display all files as being owned by group 'ftp'. Optionally, the groupname argument can be used to specify a specific group other than 'ftp'. "~" can be used as the argument in order to display the primary group name of the current user.
Both DirFakeGroup and DirFakeUser are completely cosmetic; the groupname or username specified don't need to exist on the system, and neither directive affects permissions, real ownership or access control in any way.
DirFakeMode [ DirFakeMode octal-mode]
Default
None
Context
server config, <VirtualHost>, <Global>, <Anonymous>, <Directory>
Module
mod_ls
Compatibility
1.1.6
The DirFakeMode directive configures a mode (or permissions) which will be displayed for ALL files and directories in directory listings. For each subset of permissions (user, group, other), the "execute" permission for directories is added in listings if the "read" permission is specified by this directive. As with DirFakeUser, and DirFakeGroup, the "fake" permissions shown in directory listings are cosmetic only, they do not affect real permissions or access control in any way.
DirFakeMode 0640 Will result in: -rw-r----- ... arbitrary.file drwxr-x--- ... arbitrary.directory