Este documento describe los mejores ejercicios, comunes y recomendados, cuando configuramos y utilizamos servidores proftpd. Daremos por hecho que se tiene algo de conocimientos del entorno y los comandos básicos de sistema, administración de cuentas, chroots..

<virtualhost></virtualhost>

Cuando configuramos un virtualhost, es mejor utilizar una dirección IP, no un servidor DNS, no solo reduce el tráfico de red cuando el demonio se inicia (ya que no tendrá que resolver los nombres DNS a sus direcciones IP), sino que también reducirá la confusión. A diferencia de HTTP, FTP no soporta hosts virtuales basados en nombre, todo contacto con los hosts virtuales se hace a través de direcciones IP (y puertos). Si se utiliza un servidor DNS en una configuración , es probable que el nombre DNS se resolverá a una dirección IP de otro host virtual en la configuración. Lo ideal sería que el demonio proftpd comprobara esta coincidencia cuando ha terminado de analizar el fichero de configuración (y puede que en el futuro lo haga) pero de momento, es mejor utilizar una dirección IP en vez de nombres DNS si es posible.

Accediendo

Para crear un usuario utiliza:

$ useradd your_user -p your_password -d /your_homedirectory -s /bin/false
$ passwd your_user

Limite de Recursos

Uno de los peticiones más comunes en la lista de correo es poder limitar el número de conexiones, de varias maneras, que un usuario dado pueda hacer al demonio proftpd. Hay diferentes directivas de configuración para hacerlo, dependiendo de la situación:

• MaxInstances: Limita el número total de conexiones
• MaxClients: Limita el número de conexiones en base a servidor/host
• MaxClientsPerHost: Limita el número de clientes que puedan conectar desde el mismo host.
• MaxClientsPerUser: Limita el número de clientes que pueden loguearse a la vez utilizando para un mismo nombre de usuario.
• MaxHostsPerUser: Limita el número de hosts del que los clientes pueden loguearse de una vez utilizando el mismo nombre de usuario.

Si utilizas inetd, seguramente ya estés al tanto de los limites que tiene por defecto (ver Bug#1243). Para xinetd, los atributos per_source y cps se pueden utilizar para configurar los limites de concurrencia. Para un servidor standalone, la directiva de configuración MaxConnectionRate puede utilizarse para proporcionar límites de conexión.

El uso intensivo de CPU y/o memoria por las sesiones FTP se pueden restringir utilizando RLimitCPU y RLimitMemory. Por ejemplo:

RLimitCPU session 10
RLimitMemory session 4096

Esto aplica a los limites de CPU y de recursos de memoria para los procesos de sesión. Para limitar el uso de dichos procesos por el demonio, debemos tener en cuenta que las directivas pueden usarse similarmente:

RLimitMemory daemon 8192 max

En general, no debería ser necesario establecer límite RLimitCPU en el demonio, ya que un demonio de larga vida (como debería ser) encontraría de por sí ese limite.

Note: La configuración apropiada para utilizar varía de un site a otro, por ello no copies ciegamente estos ejemplos.

Algo a tener en cuenta respecto al uso inrestringido de recursos es globbing; Este tema ya lo habíamos menciado, en relación a los servidores FTP, en foros de seguridad en el pasado. Este mini howto discute en profundidad, la defensa contra ataques globbing(language) que proporciona ProFTPd.

(language) Un ataque «globbing» es como se suele llamar a la expansión de comodines en los nombres de los ficheros. Algunos servidores de ftp se vuelven locos cuando les pides cosas como esta:

mget ../../../../*

Algunos sitios gustan de restringir el tamaño de los ficheros transferidos, particularmente ficheros subidos, ya que el espacio en disco es también un recurso preciado. Para ello tenemos las directivas de configuración MaxRetrieveFileSize y MaxStoreFileSize.
También hay otros módulos de terceros que pueden añadir diversas habilidades de limite de recursos a un servidor proftpd:

• mod_diskuse
• mod_load
• mod_quotatab

Controles de Acceso

ProFTPD proporciona una directiva para configurar controles de acceso minuciosos que pueden aplicarse tanto a logins como a comandos FTP. El módulo mod_wrap permite a un demonio proftpd utilizar los ficheros estándar de control de acceso /etc/hosts.allow y /etc/hosts.deny. Para algunos sera interesante la próxima generación de este módulo, mod_wrap-2.0, que permite guardar reglas de control de acceso en tablas SQL.

Tunear el Rendimiento

Os ofrecemos unos ajustes para configurar proftpd para rendimiento, Primero, asegurate de deshabilitar la búsqueda Ident y Reverse DNS:

IdentLookups off
UseReverseDNS off

Por defecto, ambos se usan para cada sesión FTP nueva, y dependiendo del tiempo de respuesta de ambos servidores identd y DNS, esto puede añadir un retraso durante el proceso de logueo.

Otra posible causa de retardos durante el proceso de acceso es un fichero /etc/passwd demasiado grande. (un fichero /etc/group grande tendrá el mismo efecto). Las funciones de la librería estándar utilizadas para realizar la búsqueda de usuarios escanean estos ficheros linea por linea, lo que significa que el tiempo de escaneo es directamente proporcional al número de entradas. Si este es el caso de tu sitio, deberías considerar utilizar otro sistema de almacenamiento para tus cuentas de usuario. Los módulos mod_sql y mod_ldap provistos de ProFTPd se pueden utilizar para almacenar dicha información en las tablas SQL o servidores LDAP.

En algunos casos, es posible que los chequeos PAM sean responsables también de algunos retrasos. Si sospechas que esto pueda ser la causa, añade lo siguiente en tu proftpd.con:

AuthPAM off

El listado de directorios durante una sesión FTP puede requerir de E/S de disco en un servidor. Esto se observa con mayor frecuencia cuando los scripts de sitios espejo realizan el listado de directorios recursivos, y para estructuras de directorios anidadas. Para hacer frente a la primera, se puede utilizar lo siquiente:

ListOptions +R strict

This setting blocks the use of the -R option, which is how clients request recurse directory listings. The strict keyword prevents client options from overriding the proftpd.conf setting. Also, new in 1.2.9rc1 are some ListOptions options that allow recursive directory listings, but can be used to set limits on the recursion:

ListOptions "" maxdepth 3
ListOptions "" maxdirs 10
ListOptions "" maxfiles 1000

The first line above limits the directory depth of recursion; the second line does not limit the recursion depth, rather it limits the maximum number of directories that may be listed at one time; the third limit limits the maximum number of files that may be listed at one time.

Another way to speed up directory listings to disable proftpd’s checking for .ftpaccess files in every directory encountered. To do this, use:

AllowOverride off

This disable’s proftpd’s honouring of .ftpaccess files. How does this reduce disk I/O? In order to properly process .ftpaccess files, the daemon has to check for such a file in each and every directory when performing an operation in that directory, each time an operation is requested (it’s possible for a .ftpaccess file to be added or updated after the daemon has already checked the directory). This constant checking is noticeable on heavily loaded servers. By disabling use of these files, the daemon no longer has to check each directory each time.

The type of logging also has an impact, performance-wise. By default, a proftpd daemon logs using syslog; syslogd, however, is known to not scale well at all, and can break under heavy load. Directing logging to a file in such cases, using the ServerLog and/or SystemLog directives can reduce this bottleneck. Also, depending on the type of authentication done, disabling utmp/wtmp logging can reduce overhead:

WtmpLog off

for virtualhosts that only allow anonymous logins, or that authenticate non-/etc/passwd accounts, helps to reduce the amount of unnecessary «clutter» in the utmp/wtmp log files.

Finally, there are some configure options that can be used to tune your proftpd daemon. All of the –enable-e options are available; of particular interest are –enable-tunable-buffer-size and –enable-sendfile. Use of the sendfile(2) function (via the latter configure option) may or may not increase download speeds, but it will reduce disk I/O: sendfile(2) implements zero-copy transfers, meaning that the kernel will read data directly from the file into the socket, all in kernel space; normal read() transfers spend time copying buffers from kernel space to application space (reading the file), and then back to kernel space (writing to the socket). By increasing the buffer size using the –enable-tunable-buffer-size option, proftpd reads and writes data in larger chunks, and makes fewer expensive system calls. Use of this option to set buffer sizes of 8K or more has been reported to drastically increase transfer speeds (depending on network configurations).

Configuration Delegation

A configuration is considered «delegated» when the Include configuration directive is used in proftpd.conf to specify a portion of the server configuration that may not be under the daemon administrator’s control. This situation often arises for sites that have multiple virtual servers; the administrator for a given virtual server may be allowed to configure their particular server via an Included file. If possible, avoid this.

Here’s why: by delegating a configuration, you are trusting someone else with a great deal of possible control over the daemon. A given section can have an AuthUserFile. In that AuthUserFile, the virtual server administrator could define a user who has a UID of 0, thus basically giving herself root access. Most sites probably would not like this. The trouble here is the lack of control over the contents of AuthUserFiles (and AuthGroupFiles). There are a couple of ways of handling this situation. First, the daemon administrator can make sure that any Include directives occur as early as possible in the proftpd.conf file. Most configuration directives in the Included file can be overridden by setting the directive again, after the Include, in the main proftpd.conf.

The mod_auth_file module, now part of the core distribution, was developed specifically to provide finer control over the contents of AuthUserFile and AuthGroupFile files. It does so by enhancing these configuration directives to support optional «filters» that restrict the UIDs, GIDs, user names, and/or home directories in such files.

Patches

There are a couple of patches that may be of relevance to the security-wary administrator: AnonRejectPasswords and RootRevoke. Both patches can be found here:http://www.castaglia.org/proftpd/#Patches
As of version 1.2.9rc1, the directives added by these patches have become part of the core ProFTPD distribution.