This module is contained in the
contrib/mod_wrap.c file for
ProFTPD 1.2.x, and is not compiled by default. It enables the daemon to
use the common tcpwrappers access control library while in
standalone mode, and in a very configurable manner.
If not installed on your system, the TCP wrappers library, required by this
module, can be found
on Wietse Venema's site. Once installed, it highly recommended
pages be read and understood. The installation
mod_wrap is fairly straightforward, with some caveats for
Solaris and FreeBSD users.
Many programs will automatically add entries in the common allow/deny files,
and use of this module will allow a ProFTPD daemon running in
standalone mode to adapt as these entries are added. The
portsentry program does this, for example: when illegal access
is attempted, it will add hosts to the
The most current version of
mod_wrap is distributed with the
ProFTPD source code.
Please contact TJ Saunders <tj at castaglia.org> with any questions, concerns, or suggestions regarding this module.
2000-05-29: Thanks to David Douthitt <ssrat at mailbag.com>
for pointing out the usefulness of using
mod_wrap in conjunction
2001-03-01: Updated the configuration directives, as per lung at theuw.net's helpful suggestions.
2001-09-24: Thanks to Zenon Mousmoulas <cajoline at
chaosengine.de > for helping determine that adding
help in compiling
mod_wrap with the stock RedHat
libwrap.a, so that recompiling tcpwrappers without NIS/YP support
should no longer be necessary.
2001-09-27: Thanks to Gabe Frost <gfrost at gostnet.com> for helping track down several mergedown bugs.
2001-12-19: Thanks to Mark Castillo <markc at webFreak.com> for pointing out the issue with passwords not being properly hidden
TCPAccessFiles specifies two files, an allow and a deny file, each of which contain the IP addresses, networks or name-based masks to be allowed or denied connections to the server. The files have the same format as the standard tcpwrappers hosts.allow/deny files.
Both file names are required. Also, the paths to both files must be the full
path, with two exceptions: if the path starts with
~/, the check
of that path will be delayed until a user requests a connection, at which time
the path will be resolved to that user's home directory; or if the path starts
~user/, where user is some system user. In this latter case,
mod_wrap will attempt to resolve and verify the given user's home
directory on start-up.
The service name for which
mod_wrap will look in the indicated
access files is
proftpd by default; this can be configured via
There is a built-in precedence to the
directives, if all are used.
mod_wrap will look for applicable
TCPUserAccessFiles for the connecting user first. If no applicable
TCPUserAccessFiles is found,
mod_wrap will search for
TCPGroupAccessFiles which pertain to the connecting user. If not
mod_wrap will then look for the server-wide
TCPAccessFiles directive. This allows for access control to be
set on a per-server basis, and allow for per-user or per-group access control
to be handled without interfering with the server access rules.
# server-wide access files TCPAccessFiles /etc/ftpd.allow /etc/ftpd.deny # per-user access files, which are to be found in the user's home directory TCPAccessFiles ~/my.allow ~/my.deny
See also: TCPGroupAccessFiles, TCPServiceName, TCPUserAccessFiles
TCPAccessSyslogLevels info warn
ProFTPD can log when a connection is allowed, or denied, as the result of rules
in the files specified in
TCPAccessFiles, to the Unix
syslog mechanism. A discussion on the
which can be used is given in the
The allow-level parameter sets the syslog level at which allowed connections are logged; the deny-level parameter sets the syslog level for denied connections.
TCPAccessSyslogLevels debug warn
TCPGroupAccessFiles allows for access control files, the same
types of files required by
TCPAccessFiles, to be applied to
select groups. The given group-expression is a logical AND
expression, which means that the connecting user must be a member of all the
groups listed for this directive to apply. Group names may be negated with a
The rules for the filename paths are the same as for
# every member of group wheel must connect from restricted locations TCPGroupAccessFiles wheel /etc/ftpd-strict.allow /etc/ftpd-strict.deny # everyone else gets the standard access rules TCPGroupAccessFiles !wheel /etc/hosts.allow /etc/hosts.deny
See Also: TCPAccessFiles
TCPServiceName is used to configure the name of the service under
mod_wrap will check the allow/deny files. By default, this
is the name of the program started, i.e. "proftpd". However,
some administrators may want to use a different, more generic service name,
such as "ftpd"; use this directive for such needs.
TCPUserAccessFiles allows for access control files, the same types
of files required by
TCPAccessFiles, to be applied to select
users. The given user-expression is a logical AND expression.
Listing multiple users in a user-expression does not make much sense; however,
this type of AND evaluation allows for expressions such as "everyone
except this user" with the use of the
The rules for the filename paths are the same as for
# user admin might be allowed to connect from anywhere TCPUserAccessFiles admin /etc/ftpd-anywhere.allow /etc/ftpd-anywhere.deny # while every other user has to connect from LAN addresses TCPUserAccessFiles !admin /etc/ftpd-lan.allow /etc/ftpd-lan.deny
See also: TCPAccessFiles
from hosts that have broken reverse DNS mappings are refused. OpenSSH
uses the same
libwrap library, and this doesn't happen. Is it
a bug in
Answer: No, it is not, strictly speaking, a bug in
Users who encounter this issue will usually find log messages that look like the any/all of the following in their syslog:
proftpd: warning: can't verify hostname: gethostbyname(dns-name) failed proftpd: warning: can't verify hostname: getaddrinfo(anothername.net, AF_INET) failed proftpd: warning: host name/name mismatch: somedomain.com != vs-23.somename.comThese log messages do not, in fact, come from
proftpd. Instead, they come from the
libwraplibrary, which is used by the
mod_wrapmodule. In particular, the
libwraplibrary emits these log messages when it has been compiled with the
-DPARANOIDcompile-time option (and most installations of the
libwraplibrary are compiled this way).
OpenSSH allows such connections because the OpenSSH code, when using the
libwrap library, does not check for paranoid/unknown results
host_access() function of the
mod_wrap module for ProFTPD does check
for these values, thus why those connections are refused by
mod_wrap but not OpenSSH. This just demonstrates that not all
applications use the
libwrap library the same way.
The solution, in most cases, is to switch to using the newer
mod_wrap2 module, which does
not use the
libwrap library (and thus does not encounter
mod_wrapis straightforward, with some minor caveats. If you're using Solaris, you'll need to obtain and build the tcpwrappers library, as this library does not come installed on stock Solaris systems. If you're using FreeBSD or Mac OSX (and possibly other versions), you'll need to change the following line in the header of
* $Libraries: -lwrap -lnsl$to be:
* $Libraries: -lwrap$This line is needed on Linux and Solaris machines, to properly link against the
libnsl.alibrary, which implements the NIS/YP functions. In FreeBSD and Mac OSX, these functions are implemented in
Then, you need simply follow the normal steps for using third-party modules in ProFTPD:
$ ./configure --with-modules=mod_wrap $ make $ make install