Servidor FTP seguro con Debian y ProFTPD
Uno de los antiguos servicios básicos de Internet es sin duda el que hoy día sigue generando mayor peligro en nuestros sistemas: FTP o File Transfer Protocol, es decir Protocolo para la Transferencia de Ficheros, que aunque va siendo reemplazado cada día mas por las redes P2P y el protocolo HTTP sigue teniendo una gran importancia.
¿Cual es el problema de FTP? Sencillamente que todas las transferencias se hacen sin ningún tipo de cifrado, por lo que todos los comandos y datos (y lo que es más grave, los datos de usuario y contraseña) que enviemos y recibamos pueden ser capturados por terceras personas.
Algunos se estarán preguntando por que no usar RSSH, que aportaría una solución sobre servidores SSH. La razón es que quiero servicios totalmente independientes, que corran sobre puertos diferentes y que me permitan opciones adicionales.
En mi caso usaré ProFTPD, ya que es un servidor soportado por Webmin, con lo que la configuración puede simplificarse para algunas cosas. De todas formas recomiendo configurar a mano todo.
Instalar ProFTPD es muy sencillo, basta con ejecutar como root el comando:
apt-get install proftpd
Con eso quedará todo configurado por defecto. CHROOT está activo por defecto, con lo que nuestros usuarios quedan ceñidos estrictamente a su directorio HOME, del que no pueden salir.
Pero falta enseñar a ProFTPD como reconocer conexiones TLS, y si lo deseamos, enseñarle a que fuerce a los usuarios a utilizar TLS (altamente recomendado).
Lo primero es generar un certificado para el servidor, ejecutando (de nuevo como root):
make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/ssl/certs/proftpd.pem
Necesitaremos introducir los datos pertinentes.
Ahora editamos /etc/proftpd.conf (siempre como root) y añadimos al final lo siguiente:
<IfModule mod_tls.c>
TLSEngine on
TLSLog /var/ftpd/tls.log
TLSProtocol TLSv1
# Obligar a los clientes a usar TLS (on/off)
TLSRequired on
# Certificado del Servidor
TLSRSACertificateFile /etc/ssl/certs/proftpd.pem
# Permitir a usuarios que deseen usar FTP sobre TLS (on/off)
TLSVerifyClient on
</IfModule>
Tras ello reiniciamos el servidor ftp con:
/etc/init.d/proftpd restart
¡Y listo! Con la configuración que acabamos de poner SOLO quien use TLS podrá identificarse en el servidor. Las contraseñas ya no viajarán nunca en texto plano.
Documentación empleada:
- FTPS: http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
- Documentación ProFTPD - mod_tls: http://www.castaglia.org/proftpd/modules/mod_tls.html
- ProFTPD mini-HOWTO - SSL/TLS: http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-TLS.html
Copyright (c) 2005 Julio González Gil.
Este artículo puede copiarse, distribuirse y/o modificarse bajo los términos de la Licencia GNU para Documentación Libre 1.1 o superior, manteniendo esta nota en su totalidad
- Inicie sesión o regístrese para enviar comentarios
- 15346 lecturas
Relacionado con Servidor FTP seguro con Debian y ProFTPD
Algunos se estarán preguntando por que no usar RSSH, que aportaría una solución sobre servidores SSH. La razón es que quiero servicios totalmente independientes, que corran sobre puertos diferentes y que me permitan opciones adicionales.
Varias cosas: al usar el TLS los clientes ftp deben tener soporte para TLS y eso no es algo común entre ellos. Es decir si usas el sshd TODOS los clientes tienen el soporte ya que es inherente al protocolo, por lo tanto no fuerzas a nadie a usar un cliente modificado con soporte ya que todos lo traen.
El cifrado surgió como un parche a un protocolo inseguro, lo que provoca que no todos los clientes tengan soporte (son pocos los que lo tienen). Por lo tanto mejor usar ssh o rssh ya que su uso es independiente del cliente.
De tu afirmación de arriba: ssh no tiene por qué correr en el puerto 22, es más, puedes tener muchos demonios de ssh corriendo en puertos distintos y con configuraciones distintas (son servicios distintos con opciones adicionales si es preciso). Por lo tanto no entiendo tu afirmación.
Por último, añadir soporte de cifrado al protocolo de ftp ya es de por sí un riesgo de seguridad, puesto que cada dos por tres se le encuentran buffers overflows y demás. Esa es la razón por la que yo uso vsftpd (el mejor en cuanto a la seguridad del código fuente respecto a bugs) SIN soporte SSL . Para defenderse de ellos, el demonio de ssh se diseñó para "droppear" los privilegios y que la comunicación se hiciera en base a un "fork" carente de ellos, cosa que no ocurre en los ftp.
Por lo tanto: pierdo confidencialidad pero gano seguridad frente a exploits, a lo que añado que al ser un servidor SÓLO anónimo y de sólo lectura no me preocupa en exceso ya que no viaja información sensible.
Un consejo: No elijas tu servidor por la facilidad de configuración sino por las cualidades de seguridad/rendimiento/fiabilidad que posea (la seguridad no depende tanto del cifrado sino de la claridad y el buen hacer del código fuente y la cantidad de bugs que se le saquen es un gran índice de ello).
---
"Don't accept that what's happening;
Is just a case of others' suffering;
Or you'll find that you're joining in
-Pink Floyd- On the turning away.
PD: me baso en dar mi opinión acerca de vsftpd a que no ha tenido nunca un exploit remoto serio y eso es índice de que el código fuente es bueno. He de añadir algo más: El chroot es una barrera MUY débil, es decir, si se aprovecha una vulnerabilidad del servicio ftp (que corre como superusuario) un atacante ya tendría los permisos necesarios para escapar de ella.
Distinto sería que el servicio no fuera lanzado como superusuario (un servicio que escuche en un puerto alto por ejemplo) ya que en caso de explotación el atacante accedería con los permisos de un usuario normal y corriente (unprivilegiado) y carece de los privilegios necesarios para escapar. Ahí tendría que buscar la utilización de un exploit local para escalar y poder hacerlo.
---
"Don't accept that what's happening;
Is just a case of others' suffering;
Or you'll find that you're joining in
-Pink Floyd- On the turning away.
Respondo aquí, ya que no me deja contestaros en vuestros
hilos y no se el motivo.
Habría incluido otros soportes mas 'estandar' para FTP
seguro, pero como visteis en los documentos adjuntos, o
rompen el RFC o bien el IETF no los apoya. Solo AUTH TLS
cumple esos requisitos.
Si, se puede usar SSH, sin embargo no quería romperme los
cuernos, y los overflows y demás que puedan afectar a
estos cifrados, también afectarán a muchas mas
aplicaciones que usen SSL, entre ellas servidores IMAP,
POP3, HTTP, SMTP, etc... La solución que tu propones de
dejar que vayan los datos sin encriptar no es solución, ya
que mucha gente (obviamente es a la que iba dirigido este
artículo) no le dará al FTP un uso anónimo, con lo que
viajan contraseñas del sistema, que pueden dar acceso a
mas servicios en algunos casos.
En algo estoy de acuerdo, debería mirar más a fondo el
historial de seguridad de ProFTPD, pero como tampoco
conozco el de VSFTPD, no te puedo decir cual de los dos es
mejor/peor.
El tema de la jaula CHROOT, tienes razón, debería haber
comentado que ProFTPD puede funcionar también como usuario
no privilegiado (en mi sistema el usuario ftp), evitando
esos problemas que comentas.
Espero haber aclarado algo con respecto al artículo :-)
---
Julio González Gil
http://www.juliogonzalez.info