FTP

El FTP solía ser el protocolo más usado en Internet por el tráfico puro de datos hasta que fue sobrepasado por el HTTP hace unos años (sí, una vez hubo un Internet libre de WWW). El FTP hace una cosa, y lo hace bien, transferir ficheros entre sistemas. El protocolo en sí mismo es inseguro, contraseñas, datos, etc, se transfieren en texto claro y pueden ser esnifados con facilidad, sin embargo la mayoría del uso del ftp es ‘anónimo’, de modo que no es un gran problema. Uno de los principales problemas con que se suelen encontrar los sitios de ftp son los permisos incorrectos en directorios que permiten a la gente utilizar el sitio para distribuir sus propios datos (por lo general material con copyrights). Al igual que con telnet, se debería utilizar una cuenta para hacer ftp que no se utilizara para hacer trabajos administrativos, puesto que la contraseña viaja por la red en texto claro.

En general, los problemas con el ftp incluyen:

• Autentificación en texto claro, nombre de usuario y contraseña.
• Texto en claro en todos los comandos.
• Ataques de adivinación de contraseñas.
• Configuración inadecuada del servidor y el consiguiente abuso de servidores.
• Todavía existen varios desagradables ataques de Negación de Servicio en algunos servidores de ftp.
• Las versiones más antiguas de WU-FTPD y sus derivados tienen ataques de root.

Asegurar FTP no es demasiado difícil, entre los cortafuegos y los TCP_WRAPPERS se puede restringir bastante bien el acceso basado en la dirección IP / hostname. Además, la mayoría de los servidores ftp se ejecutan bajo chroot por defecto para cualquiera con acceso anónimo, o en una cuenta definida como invitado. Con un poco de trabajo, se puede configurar a los usuarios que están haciendo ftp para hacer chroot su directorio personal, o cualquier otra cosa apropiada. También se pueden ejecutar servidores de ftp que cifren los datos (utilizando cosas como SSL/etc.) sin embargo eso significa que tus clientes ftp deben hablar el protocolo de cifrado, y ello no siempre es práctico. También asegúrate de que no se tienen directorios de acceso público en el servidor de ftp que sean a la vez legibles y que se puedan escribir, o si no la gente los explotará para distribuir su propio software (generalmente warez o porno).

Un ejemplo de reglas de filtrado para el cortafuegos:

Un ejemplo de lo mismo utilizando TCP_WRAPPERS:

En /etc/hosts.allow

Y en /etc/hosts.deny

Existen diferentes alternativas cifradas a ftp como se mencionó más arriba, SSLeay FTPD y otras utilidades de terceros. puesto que la mayoría de cuentas ftp no se utilizan como cuentas de administración (contraseñas en texto claro, ya has sido advertido), y es de esperar que se ejecuten con chroot, el riesgo de seguridad se minimiza. Ahora que tenemos cubiertas todas las partes de ftp basadas en red, vamos con la forma de asegurar cuentas de usuarios y el entorno.

No recomendaría el uso del WU-FTPD, puesto que tiene muchos problemas de seguridad, y bastantes vendedores de Linux no utilizan WU-FTPD en sus propios servidores de ftp. Recomendaría encarecidamente ProFTPD, que está disponible gratuitamente y se desarrolla en la siguiente sección.

Uno de los principales mecanismos de seguridad de WU-FTPD es el uso de chroot. Por ejemplo: por defecto toda la gente haciendo login de forma anónima tiene /home/ftp/ como el directorio raíz. No pueden salir de aquí y, digamos, mirar el contenido de /home/ o /etc/. Lo mismo se aplica a grupos de usuarios y/o individuos, por ejemplo, se podría configurar a todos los usuarios para que fuesen hechos chroot a /home/ cuando hacen el ftp, o en casos extremos de privacidad de usuarios (digamos un servidor de www albergando múltiples dominios) configurar cada usuario con chroot a su propio directorio personal. Esto se hace mediante el uso de /etc/ftpaccess y /etc/passwd (haciendo man ftpaccess se obtienen toda la información). Daré unos cuantos ejemplos de lo que es necesario hacer para llevarlo a cabo, puesto que al principio puede resultar algo confuso. ftpd también verifica /etc/ftpusers y si el usuario que está intentando hacer login aparece listado en ese fichero (como debería estarlo el root) no le dejará acceder vía ftp.

Hacer chroot a usuarios a medida que van haciendo login en el servidor de ftp es bastante simple, pero está pobremente documentado. La comprobación del servidor de ftp de /etc/ftpaccess en busca de "guestgroup"’s, que son simplemente "guestgroup cualquier-grupo-del-sistema" p. ej. "guestgroup usuarios". El nombre de grupo tiene que estar definido en /etc/group y tener añadidos miembros. Es necesario editar la línea de su fichero de contraseñas, de forma que el servidor de ftp sepa dónde volcarlos. Y puesto que ahora están hechos chroot a ese directorio del sistema, no tienen acceso a /lib, etc, así que hay que copiar ciertos ficheros a sus directorios para que cosas como "ls" funcionen correctamente (siempre un toque elegante).

Configurar un usuario (felipefroilan) de forma que pueda entrar por ftp y acabe siendo hecho chroot a su directorio personal (porque sigue amenazando al administrador con llevarle a cazar gamusinos). Además de esto, felipefroilan puede entrar por telnet y cambiar su contraseña, pero nada más, porque sigue intentando ejecutar bots de irc. El sistema en que está utiliza contraseñas con shadow, por eso hay una ‘x’ en el campo de contraseñas de felipefroilan.

Lo primero de todo es que felipefroilan necesita tener una cuenta correctamente configurada en /etc/passwd:

Lo que significa que el servidor de ftp hará un chroot de felipefroilan y luego le hará un chdir en lo que ahora se conoce como / (/home/felipefroilan para el resto de nosotros). La página del manual de ftpaccess cubre bien todo esto, y por supuesto que /usr/sbin/passwd tiene que estar listado en /etc/shells.

Segundo, para que el servidor de ftp sepa que se le está haciendo chroot, tiene que ser miembro de un grupo (usuariosmalos, genteftp, etc) que venga definido en /etc/group. Y después ese grupo tiene que aparecer listado en /etc/ftpaccess.

Ahora hay que copiar algunas librerías y binarios en la "cárcel" chroot, si no "felipefroilan" no va a poder hacer demasiadas cosas una vez que haya entrado por ftp. Los ficheros necesarios están disponibles como paquete (normalmente llamado "anonftp"), una vez que esté instalado, los ficheros se copiarán a /home/ftp/, te darás cuenta de que hay un /etc/passwd, que sólo se usa para mapear UID’s a nombres de usuarios, si quieres que felipefroilan vea su nombre de usuario y no su UID, añade una línea para él (p. ej., copia esta línea desde el /etc/passwd real por esta otra). Lo mismo se aplica al fichero de grupos.

sin "felipefroilan:*:500:500:::" en /home/felipefroilan/etc/passwd:

y con la línea añadida a /home/felipefroilan/etc/passwd:

y con una línea para el grupo de felipefroilan añadida a /home/felipefroilan/etc/group:

drwxr-xr-x 2 felipefroilan felipefroilan 1024 Jul 14 20:46 felipefroilan

Ahora felipefroilan puede hacer un ftp al sistema, subir y descargar ficheros desde el directorio /home/felipefroilan, cambiar él mimo su contraseña y no dañar el sistema, ni descargar el fichero de contraseñas u otro tipo de incordios.

El FTP también es un protocolo bastante especial, pues los clientes se conectan al puerto 21 (por lo general) del servidor de ftp, y luego, en el puerto 20 del servidor de ftp se conecta al cliente, y es sobre esta conexión donde viajan los datos reales. Lo cual significa que el puerto 20 tiene que hacer conexiones externas. Hay que tener esto en cuenta cuando se configure un cortafuegos, ya sea para proteger servidores ftp o clientes utilizando ftp. De igual forma, existe un ftp "pasivo", y generalmente se suele utilizar por visores www/etc, lo cual significa conexiones entrantes al servidor en puertos altos (en lugar de utilizar el 20, se ponen de acuerdo en algún otro). Si se pretende tener un servidor ftp público que SÓLO vaya a servir ftp, y nada más, colócalo preferiblemente fuera de nuestra LAN interna (ver Practical Unix and Internet Security para discusiones del concepto ‘DMZ’). Se puede conseguir WU-FTPD de ftp://ftp.wu-ftpd.org/

ProFTPD es un servidor con licencia GPL que se ejecuta en una variedad de plataformas UNIX. Soporta nuevas características como ftp virtual, configuración por directorio (utilizando ficheros .ftpaccess, similares a los ficheros .htaccess de Apache), soporte para cuentas que han expirado y más. También soporta características bastante útiles como la limitación de descargas y controles de seguridad más férreos que WU-FTPD. Lo recomendaría encarecidamente por encima de otros servidores de FTP para UNIX gratuitos.

El fichero de configuración principal de ProFTPD es /etc/proftpd.conf, tiene un estilo de configuración Apachesca que me gusta mucho. ProFTPD se puede ejecutar desde inetd (y hacer uso de TCP_WRAPPERS) o se puede ejecutar como servidor autónomo. También soporta ficheros de configuración por directorio para limitar el acceso, etc. ProFTPD también soporta ftp virtual (aunque al contrario que con un servidor virtual de www, son necesarias IPs extra) y se puede configurar cada sitio de forma diferente (diferente acceso anónimo, si es que lo hay, y más cosas de entre esas líneas). El fichero general proftpd.conf suele tener una sección que cubre los parámetros globales (inetd o autónomo, número máximo de procesos a ejecutar, como quien se ejecuta, etc.), seguido de un fichero de configuración por defecto, seguido de una configuración específica del sitio (sitios virtuales). En un servidor haciendo hosting virtual probablemente sea una buena idea desactivar "DefaultServer", de modo que cualquier cliente que haga ftp sin ningún objetivo sea denegada, en lugar de volcada dentro del sitio por defecto.

Una configuración de ejemplo de un servidor ProFTPD ejecutándose desde inetd sin acceso anónimo:

Digamos que, al igual que yo, eres paranoico y quieres controlar el acceso al servidor de ftp mediante direcciones IP, nombres de hosts y nombres de dominio (aunque recomendaría confiar sólo en las IP’s). Esto se puede conseguir mediante reglas del cortafuegos, pero eso acaba ralentizando la máquina (especialmente si se añaden multitud de reglas, como tiende a ocurrir). Se puede utilizar TCP_WRAPPERS , pero no sería posible limitar selectivamente el acceso a sitios virtuales, sitios anónimos, sólo al servidor en sí mismo. O se puede hacer en el fichero proftpd.conf utilizando la directiva "<Limit LOGIN>".

El siguiente ejemplo limitará el acceso a 10.1.*.* y 1.2.3.4, a cualquier otra máquina se le denegará el acceso.

Si se coloca esto dentro de las directivas "<VirtualHost>" o "<Anonymous>", se aplica sólo a ese sitio virtual o configuración anónima, si se coloca en la directiva "<Global>" se aplicará a todas las secciones "<VirtualHost>" y "<Anonymous>", y si se coloca en la configuración del servidor (p. ej. con "ServerName" y elementos relacionados) se comportará como lo haría TCP_WRAPPERS, cualquiera desde 10.1.*.* o desde 1.2.3.4 impacta cuando se intenta conectar al puerto 21, al contrario que si simplemente le negase el login si no está en la sección "<Global>", "<VirtualHost>" o "<Anonymous>".

Si se quiere añadir más accesos anónimos, tan sólo añadir:

Esto asignaría el directorio personal de los usuarios "ftp" (suponiendo que la configuración normal de "~ftp" probablemente fuese /home/ftp) como el directorio raíz anónimo, cuando la gente hiciese login anónimo, el ProFTPD se ejecutaría como el usuario "ftp" y el grupo "ftp" (al contrario que si se hiciera login como un usuario normal), y los logins anónimos se limitarían a 10. De igual forma, el fichero /home/ftp/bienvenido.msg se mostraría cuando hiciesen ftp los usuarios anónimos, y cualquier directorio con un fichero .message que contuviera texto, el cual se mostraría al cambiar a tal directorio. El "<Directory >" se ocupa de /home/ftp/*, y después deniega el acceso de escritura a todos, lo cual quiere decir que nadie puede subir ficheros. Si se quisiera añadir in directorio entrante, simplemente se añadiría lo siguiente después de las directivas "<Directory *>":

Lo cual le permitiría a la gente escribir ficheros en /home/ftp/incoming, pero no leerlos (es decir, descargarlos). Como se puede ver, ProFTPD es muy flexible, lo cual da como resultado mayores requerimientos de potencia que el WU-FTPD, pero definitivamente merece la pena por el control añadido. ProFTPD y su documentación se pueden conseguir en: http://www.protftpd.org/

proftpd-ldap