mod_wrapcontrib/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
here,
on Wietse Venema's site. Once installed, it highly recommended
that the hosts_access(3) and hosts_access(5) man
pages be read and understood. The installation
of 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 run
TLS_SERVER_I_DNTLS_SERVER_I_DN_x509TLS_SERVER_V_STARTTLS_SERVER_V_ENDTLS_SERVER_A_SIGTLS_SERVER_A_KEYTLS_SERVER_CERT
dNSNameRequired
This option will cause mod_tls to perform checks on a client's
certificate once the SSL handshake has been completed: the client's
certificate will be searched for the subjectAltName X509v3
extension, and, in that extension, the dNSName value will
be looked up. Unless a dNSName value is present, and the
value matches the DNS name to which the client's IP address resolves,
the SSL session is closed. This check is only performed during
SSL handshakes on the control channel. Note that if
UseReverseDNS is off, this option is automatically
disabled.
iPAddressRequired
This option will cause mod_tls to perform checks on a client's
certificate once the SSL handshake has been completed: the client's
certificate will be searched for the subjectAltName X509v3
extension, and, in that extension, the iPAddress value will
be looked up. Unless an iPAddress value is present, and the
value matches the IP address of the client, the SSL session is closed.
This check is only performed during SSL handshakes on the control channel.
The TLSProtocol directive is used to configure the SSL/TLS
protocol versions that mod_tls should use when establishing
SSL/TLS sessions. Clients can then only connect using the configured
protocol.
Since the protocol version used by mod_tls is set only once,
when the daemon starts, the TLSProtocol directive is only allowed
in the "server config" context.
The allowed protocols are:
SSLv23 |
Compatibility mode, used to allow both SSLv3 and TLSv1 |
SSLv3 |
Allow only SSLv3 |
TLSv1 |
Allow only TLSv1 |
All use of SSLv2 is disabled. SSLv2 should not be used.
/.rnd<VirtualHost>, <Global>
The TLSRandomSeed directive configures the file that
mod_tls will use for seeding the PRNG. seed must be an
absolute path.
When the daemon shuts down, any random data left will be written out to the random seed file, so that that data may be used for seeding when the daemon is started again.
Example:
TLSRandomSeed /etc/ftpd/server.rnd
<VirtualHost>, <Global>
The TLSRenegotiate directive is used to configure when SSL
renegotiations are to occur. Renegotiations, and thus this directive, are
only supported by mod_tls if the version of OpenSSL installed
is 0.9.7 or greater.
If supported, renegotiations will occur on control channels that have been
established for four hours by default, and on data channels that have
transferred over one gigabyte of data by default. When renegotiations are
requested, the client is given a timeout of 30 seconds, by default, to perform
the renegotiation. To change the default control channel renegotiation
timeout, use ctrl followed by a number, greater than zero, in seconds.
Use data followed by a number, greater than zero, of kilobytes to
change the default data channel renegotiation threshhold. The timeout
parameter, followed by a positive number of seconds, is used to change the
length of time given to a client to complete a requested renegotiation, after
which the SSL session will be shutdown. By default, mod_tls
will require that the client comply with the requested renegotiation
within the TLSRenegotiate timeout. If, however, the client is
unwilling or unable to do so, and the daemon needs to support these clients,
set required to off. Doing so will cause renegotiations to
be requested, but not required.
By default, mod_tls will perform renegotiations if supported, on
the control channel after 4 hours, and on the data channel after one gigabyte
of transferred data. The default timeout for a renegotiation is 30 seconds.
Use none to disable all renegotiation requirements.
Examples:
# Change renegotiations to occur on control channels after 1 hour
TLSRenegotiate ctrl 3600
# Change renegotiations to occur on data channels after 500 MB
TLSRenegotiate data 512000
# Change renegotiations so that they are not required, only requested
TLSRenegotiate required off
# Change only the timeout for renegotiations to be 5 minutes
TLSRenegotiate timeout 300
# Change all of the above renegotiation threshholds using one directive
TLSRenegotiate ctrl 3600 data 512000 required off timeout 300
# To disable renegotiations entirely
TLSRenegotiate none
<VirtualHost>, <Global>, <Anonymous>
The TLSRequired directive is used to define a basic security
policy, one that dictates whether the control channel, or data channel, or
both, of an FTP session must occur over SSL/TLS.
The on parameter enables SSL/TLS requirements on both control and data channels; off disables the requirements on both channels. Use ctrl and data to require SSL/TLS on either channel individually.
Example:
# Require SSL/TLS on the control channel, so that passwords are not sent # in the clear. TLSRequired ctrl # Require SSL/TLS on both channels. TLSRequired on
<VirtualHost>, <Global>
The TLSRSACertificateFile directive points to the PEM-encoded
file containing the RSA certificate file for the server and optionally also
the corresponding RSA private key file.
If the contained private key is encrypted, the administrator will be prompted for the passphrase when the daemon starts up, and when the daemon is restarted.
Example:
TLSRSACertificateFile /etc/ftpd/server-rsa-cert.pem
<VirtualHost>, <Global>
The TLSRSACertificateKeyFile directive points to the PEM-encoded
private key file for the server. If the private key is not combined with the
certificate in the TLSRSACertificateFile, use this additional
directive to point to the file with the standalone private key. When
TLSRSACertificateFile is used and the file contains both the
certificate and the private key, this directive need not be used. However,
this pract