<!-- $Id: mod_wrap.html,v 1.4 2009/12/23 23:46:35 castaglia Exp $ --> <!-- $Source: /cvsroot/proftp/proftpd/doc/contrib/mod_wrap.html,v $ --> <html> <head> <title>ProFTPD module mod_wrap</title> </head> <body bgcolor=white> <hr> <center> <h2><b>ProFTPD module <code>mod_wrap</code></b></h2> </center> <hr><br> This module is contained in the <code>contrib/mod_wrap.c</code> 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 <code>standalone</code> mode, and in a very configurable manner. <p> If not installed on your system, the TCP wrappers library, required by this module, can be found <a href="ftp://ftp.porcupine.org/pub/security/tcp_wrappers_7.6.tar.gz">here</a>, on Wietse Venema's site. Once installed, it <i>highly recommended</i> that the <code>hosts_access(3)</code> and <code>hosts_access(5)</code> man pages be read and understood. The <a href="#Installation">installation</a> of <code>mod_wrap</code> is fairly straightforward, with some caveats for Solaris and FreeBSD users. <p> Many programs will automatically add entries in the common allow/deny files, and use of this module will allow a ProFTPD daemon running in <code>standalone</code> mode to adapt as these entries are added. The <code>portsentry</code> program does this, for example: when illegal access is attempted, it will add hosts to the <code>/etc/hosts.deny</code> file. <p> The most current version of <code>mod_wrap</code> can be found at: <pre> <a href="http://www.castaglia.org/proftpd/">http://www.castaglia.org/proftpd/</a> </pre> <h2>Author</h2> <p> Please contact TJ Saunders <tj <i>at</i> castaglia.org> with any questions, concerns, or suggestions regarding this module. <h2>Thanks</h2> <p> <i>2000-05-29</i>: Thanks to David Douthitt <ssrat <i>at</i> mailbag.com> for pointing out the usefulness of using <code>mod_wrap</code> in conjunction with <code>portsentry</code> <p> <i>2001-03-01</i>: Updated the configuration directives, as per lung <i>at</i> theuw.net's helpful suggestions. <p> <i>2001-09-24</i>: Thanks to Zenon Mousmoulas <cajoline <i>at</i> chaosengine.de > for helping determine that adding <code>-lnsl</code> would help in compiling <code>mod_wrap</code> with the stock RedHat <code>libwrap.a</code>, so that recompiling tcpwrappers without NIS/YP support should no longer be necessary. <p> <i>2001-09-27</i>: Thanks to Gabe Frost <gfrost <i>at</i> gostnet.com> for helping track down several mergedown bugs. <p> <i>2001-12-19</i>: Thanks to Mark Castillo <markc <i>at</i> webFreak.com> for pointing out the issue with passwords not being properly hidden <h2>Directives</h2> <ul> <li><a href="#TCPAccessFiles">TCPAccessFiles</a> <li><a href="#TCPAccessSyslogLevels">TCPAccessSyslogLevels</a> <li><a href="#TCPGroupAccessFiles">TCPGroupAccessFiles</a> <li><a href="#TCPServiceName">TCPServiceName</a> <li><a href="#TCPUserAccessFiles">TCPUserAccessFiles</a> </ul> <hr> <h2><a name="TCPAccessFiles">TCPAccessFiles</a></h2> <strong>Syntax:</strong> TCPAccessFiles <em>allow-filename deny-filename</em><br> <strong>Default:</strong> None<br> <strong>Context:</strong> server config, <code><VirtualHost</code>, <code><Global></code>, <code><Anonymous></code><br> <strong>Module:</strong> mod_wrap<br> <strong>Compatibility:</strong> 1.2.1 and later <p> 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. <p> Both file names are required. Also, the paths to both files must be the full path, with two exceptions: if the path starts with <code>~/</code>, 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 with <code>~user/</code>, where user is some system user. In this latter case, <code>mod_wrap</code> will attempt to resolve and verify the given user's home directory on start-up. <p> The service name for which <code>mod_wrap</code> will look in the indicated access files is <code>proftpd</code> by default; this can be configured via the <code>TCPServiceName</code> directive. <p> There is a built-in precedence to the <code>TCPAccessFiles</code>, <code>TCPGroupAccessFiles</code>, and <code>TCPUserAccessFiles</code> directives, if all are used. <code>mod_wrap</code> will look for applicable <code>TCPUserAccessFiles</code> for the connecting user first. If no applicable <code>TCPUserAccessFiles</code> is found, <code>mod_wrap</code> will search for <code>TCPGroupAccessFiles</code> which pertain to the connecting user. If not found, <code>mod_wrap</code> will then look for the server-wide <code>TCPAccessFiles</code> 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. <p> Example: <pre> # 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 </pre> <p> See also: <a href="#TCPGroupAccessFiles">TCPGroupAccessFiles</a>, <a href="#TCPServiceName">TCPServiceName</a>, <a href="#TCPUserAccessFiles">TCPUserAccessFiles</a> <p> <hr> <h2><a name="TCPAccessSyslogLevels">TCPAccessSyslogLevels</a></h2> <strong>Syntax:</strong> TCPAccessSyslogLevels <em>allow-level deny-level</em><br> <strong>Default:</strong> <code>TCPAccessSyslogLevels info warn</code><br> <strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code>, <code><Anonymous></code><br> <strong>Module:</strong> mod_wrap<br> <strong>Compatibility:</strong> 1.2.1 and later <p> ProFTPD can log when a connection is allowed, or denied, as the result of rules in the files specified in <code>TCPAccessFiles</code>, to the Unix <code>syslog</code> mechanism. A discussion on the <code>syslog</code> levels which can be used is given in the <code>SyslogLevel</code> directive. <p> The <em>allow-level</em> parameter sets the syslog level at which allowed connections are logged; the <em>deny-level</em> parameter sets the syslog level for denied connections. <p> Example: <pre> TCPAccessSyslogLevels debug warn </pre> <p> <hr> <h2><a name="#TCPGroupAccessFiles">TCPGroupAccessFiles</a></h2> <strong>Syntax:</strong> TCPGroupAccessFiles <em>group-expression allow-filename deny-filename</em><br> <strong>Default:</strong> <em>None</em><br> <strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br> <strong>Module:</strong> mod_wrap<br> <strong>Compatibility:</strong> 1.2.1 and later <p> <code>TCPGroupAccessFiles</code> allows for access control files, the same types of files required by <code>TCPAccessFiles</code>, to be applied to select groups. The given <em>group-expression</em> 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 <code>!</code> prefix. <p> The rules for the filename paths are the same as for <code>TCPAccessFiles</code> settings. <p> Example: <pre> # 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 </pre> <p> See Also: <a href="#TCPAccessFiles">TCPAccessFiles</a> <p> <hr> <h2><a name="TCPServiceName">TCPServiceName</a></h2> <strong>Syntax:</strong> TCPServiceName <em>name</em><br> <strong>Default:</strong> <code>TCPServiceName proftpd</code><br> <strong>Context:</strong> server config, <code><VirtualHost></code>, <code><Global></code><br> <strong>Module:</strong> mod_wrap<br> <strong>Compatibility:</strong> 1.2.1 and later <p> <code>TCPServiceName</code> is used to configure the name of the service under which <code>mod_wrap</code> will check the allow/deny files. By default, this is the name of the program started, <em>i.e.</em> "proftpd". However, some administrators may want to use a different, more generic service name, such as "ftpd"; use this directive for such needs. <p> <hr> <h2><a name="TCPUserAccessFiles">TCPUserAccessFiles</a></h2> <strong>Syntax:</strong> TCPUserAccessFiles <em>user-expression allow-filename deny-filename</em><br> <strong>Default:</strong> <em>None</em><br> <strong>Context:</strong> server config, virtual host<BR> <strong>Module:</strong> mod_wrap<br> <strong>Compatibility:</strong> 1.2.1 and later <p> <code>TCPUserAccessFiles</code> allows for access control files, the same types of files required by <code>TCPAccessFiles</code>, to be applied to select users. The given <em>user-expression</em> 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 <i>except</i> this user" with the use of the <code>!</code> negation prefix. <p> The rules for the filename paths are the same as for <code>TCPAccessFiles</code> settings. <p> Example: <pre> # 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 </pre> <p> See also: <a href="#TCPAccessFiles">TCPAccessFiles</a> <p> <hr> <h2><a name="FAQ">FAQ</a></h2> <p> <font color=red>Question</font>: Using <code>mod_wrap</code>, connections from hosts that have broken reverse DNS mappings are refused. OpenSSH uses the same <code>libwrap</code> library, and this doesn't happen. Is it a bug in <code>mod_wrap</code>?<br> <font color=blue>Answer</font>: No, it is not, strictly speaking, a bug in <code>mod_wrap</code>. <p> Users who encounter this issue will usually find log messages that look like the any/all of the following in their syslog: <pre> proftpd: warning: can't verify hostname: gethostbyname(<i>dns-name</i>) failed proftpd: warning: can't verify hostname: getaddrinfo(anothername.net, AF_INET) failed proftpd: warning: host name/name mismatch: somedomain.com != vs-23.somename.com </pre> These log messages do <b>not</b>, in fact, come from <code>proftpd</code>. Instead, they come from the <code>libwrap</code> library, which is used by the <code>mod_wrap</code> module. In particular, the <code>libwrap</code> library emits these log messages when it has been compiled with the <code>-DPARANOID</code> compile-time option (and most installations of the <code>libwrap</code> library are compiled this way). <p> OpenSSH allows such connections because the OpenSSH code, when using the <code>libwrap</code> library, does not check for paranoid/unknown results from the <code>host_access()</code> function of the <code>libwrap</code> library. The <code>mod_wrap</code> module for ProFTPD <i>does</i> check for these values, thus why those connections are refused by <code>mod_wrap</code> but not OpenSSH. This just demonstrates that not all applications use the <code>libwrap</code> library the same way. <p> The solution, in most cases, is to switch to using the newer <a href="mod_wrap2.html"><code>mod_wrap2</code></a> module, which does <b>not</b> use the <code>libwrap</code> library (and thus does not encounter this issue). <p> <hr> <h2><a name="Installation">Installation</a></h2> Use of <code>mod_wrap</code> is 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 <code>mod_wrap.c</code>: <pre> * $Libraries: -lwrap -lnsl$ </pre> to be: <pre> * $Libraries: -lwrap$ </pre> This line is needed on Linux and Solaris machines, to properly link against the <code>libnsl.a</code> library, which implements the NIS/YP functions. In FreeBSD and Mac OSX, these functions are implemented in <code>libc</code>. <p> Then, you need simply follow the normal steps for using third-party modules in proftpd: <pre> ./configure --with-modules=mod_wrap make make install </pre> <p> <hr> Author: <i>$Author: castaglia $</i><br> Last Updated: <i>$Date: 2009/12/23 23:46:35 $</i><br> <br><hr> <font size=2><b><i> © Copyright 2000-2009 TJ Saunders<br> All Rights Reserved<br> </i></b></font> <hr><br> </body> </html>
