Personalmente lo utilzo con relativa frecuencia, generalmente con el cliente FileZilla, un cliente FTP multiplataforma de código abierto muy recomendable. Y siendo honestos, hasta la escritura de esta entrada, mi desconocimiento sobre los modos de conexión activo o pasivo era absoluto, algo que intuyo que le sucede a mucha gente, y ya se sabe que mal de muchos consuelo de tontos entrada en el blog.

FTP, FTPS y SFTP.

Recordemos que existen tres protocolos distintos a los que solemos referirnos cuando hablamos de FTP: FTP, FTPS y SFTP. Si tienes dudas sobre alguno de ellos puedes echarle un vistazo a la entrada FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes.

Pues bien, los modos activo o pasivo solo aplican sobre los protocolos FTP y FTPS, en ningún caso sobre SFTP, pues es un protocolo que dista bastante de los dos anteriores.

Puerto de datos y puerto de control

Otro aspecto clave que debemos conoce para entender el funcionamiento del FTP es que trabaja sobre dos puertos distintos: el puerto de datos y el puerto de comandos o puerto de control.

Los nombres son bastante auto-explicativos, el puerto de datos se encarga de la transmisión de los ficheros y el puerto de control de las instrucciones entre ambos host. Se diseñó así para poder enviar comandos sin la necesidad de detener la transmisión de datos ni de encolarlos tras estos.

Si nos centramos en el servidor, tradicionalmente el puerto de control ha sido el 21 y el puerto de datos varía en función del modo, siendo el 20 para el modo activo, y un puerto aleatorio para el modo pasivo.

En el lado del cliente, en cambio, el puerto de control será un puerto aleatorio P superior a 1023, y el puerto de datos será P+1. Esto es así tanto en el modo activo, como en el pasivo.

Pero veamos cada uno de los modos en detalle para entenderlo mejor.

FTP activo

Es el modo predeterminado para las conexiones FTP, de hecho fue el primero en desarrollarse. En este modo el servidor utilizará el puerto 20 para la transferencia de datos, mientras que transmitirá los comandos utilizando el puerto 21. El cliente en cambio utilizará un puerto aleatorio P superior al 1023 para la transferencia de comandos, y un puerto P+1 para la transferencia de datos.

Secuencia de conexión del modo activo

La secuencia de conexión del modo activo es la siguiente:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor. Como hemos mencionado el puerto P será superior a 1023.
2. El servidor responde desde el puerto de control.
3. El servidor inicia entonces la conexión del canal de datos: puerto 20 para el servidor y puerto P+1 para el cliente.
4. El cliente responde desde el puerto de datos estableciendo así la conexión.

Inconvenientes del modo activo

Históricamente el principal inconveniente de este modo ha radicado en que si no hay una directiva específica en los firewalls del lado del cliente, la conexión es propensa a ser bloqueada. Esto se debe a que, como hemos visto, existen dos conexiones independientes: una de salida en la que el cliente establece la conexión del canal de control y otra de entrada en la que el servidor hace lo propio con el de datos. Esta última conexión es iniciada por el servidor en el puerto previamente negociado, y en ocasiones es bloqueada por el firewall del cliente al ser identificada como un intento de conexión externa no autorizada.

Recordemos que este sistema se diseñó en los años 70, cuando la democratización de los sistemas informáticos y los problemas de seguridad eran completamente distintos a los que podemos encontrar hoy en día.

Sea como sea, en todos los años que llevo utilizando el protocolo FTP desde el rol de cliente, no recuerdo haber experimentado nunca problemas de este tipo, y habré conectado con varias decenas de servidores de muchos proveedores distintos. Entiendo que esto se deba a la sofisticación de los sistemas de red y de seguridad más modernos.

FTP pasivo

El modo de FTP pasivo surge como consecuencia de los problemas de conexión del modo activo. Este modo mantiene los dos canales (control y datos) pero en este caso es el cliente el encargado de establecer las dos conexiones.

El servidor sigue manteniendo el puerto 21 como puerto de comandos, el puerto de datos en cambio difiere del modo activo y pasa a ser un rango de puertos Q superior a 1023. Del lado del cliente seguimos manteniendo el puerto P superior a 1023 para control, y el puerto P+1 para datos.

Secuencia de conexión del modo pasivo

La secuencia de conexión del modo pasivo es la que sigue a continuación:

1. El cliente FTP comienza la conexión dese un puerto de control aleatorio P con destino al puerto 21 del servidor.
2. El servidor responde desde el puerto de control.
3. El cliente inicia la conexión del canal de datos dese el puerto P+1 hacia el puerto Q del servidor.
4. El servidor responde desde el puerto de datos estableciendo así la conexión.

Como ves, los pasos uno y dos son iguales que en el modo activo, y es en los pasos tres y cuatro dónde vemos como se invierten los roles y es el cliente el que inicia la conexión de datos.

Inconvenientes del modo pasivo del FTP

El principal inconveniente de habilitar el modo pasivo en un servidor FTP está asociado con el riesgo extra en materia de seguridad que conlleva la apertura de un rango de puertos extra con respecto al modo activo. Notemos que para que el modo pasivo funcione adecuadamente estos puertos deben ser abiertos tanto en el servidor como en el firewall.

Para minimizar este riesgo la estrategia pasa por definir un rango de puertos lo más pequeño posible en función del número de conexiones concurrentes que esperemos tener, pero ojo, porque un cliente no se corresponde con una única conexión, es muy probable que cada cliente abra múltiples conexiones concurrentes.

Resumen

Para cerrar esta entrada os dejo una tabla con el resumen de lo que hemos visto.

Créditos, referencias y artículos relacionados

• Imagen de portada por Michal Jarmoluk en Pixabay
• FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes
• VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu
• FTPS o cómo habilitar SSL en vsftp
• Usuarios virtuales en vsftp

Esta es la tercera entrega de la serie Clonar una web en un servidor local, por lo que te recomiendo leer las entregas previas. No obstante, este artículo puede ser tratado como un artículo atómico asumiendo que perdemos ciertos matices.

Una de las ventajas del proceso de clonado de los archivos frente al de clonado de una base de datos es que si bien con la base de datos podíamos encontrarnos muchas limitaciones en función de los diferentes proveedores y planes de hostings, para clonar los archivos el único requisito que debemos cumplir con respecto a nuestro host remoto es tener acceso mediante ftp, algo que todos los hosting ofrecen.

Descarga de archivos

Para descargar los archivos nos serviremos del comando wget. Comenzaremos el proceso creando un script de consola y le asignándole los permisos necesarios:

mkdir ~/scripts
vim ~/scripts/cloneWebFiles.sh
chmod 0755 ~/scripts/clonWebFiles.sh

Con el siguiente contenido:

#!/bin/bash

wget -r -N -q --level=15 --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com

Dónde:

• -r, indica recursividad
• -N, indica que descargue solo archivos nuevos y/o modificados
• -q, oculta los mensajes de salida del comando
• –level=15, es el numero de niveles de recursividad
• –user=user, es el usuario ftp
• –password=’password’, es la contraseña del ftp
• –directory-prefix=~/webBackUp, es el directorio dónde copiaremos los archivos
• fttp://ftp.url.com, es el ftp con el path del que queremos descargar los archivos

Esto realizará una copia de los archivos de nuestra web en la carpeta ~/webBackUp/ftp.url.com. Esta operación suele tardar bastante tiempo, así que para agilizarla hemos optado por descargar únicamente los archivos nuevos y/o modificados recientemente, aun así con una web de tamaño medio tardará un buen rato.

Debemos destacar que no descargamos los archivos directamente a nuestro entorno de pruebas, sino que los descargamos a una carpeta intermedia. Esto lo hacemos por dos motivos:

1. Modificaremos algunos archivos antes de copiarlos en nuestro entorno de pruebas.
2. Podemos crear un segundo script que omita la descarga y que restaure nuestra copia mucho más rápido, muy útil en caso de querer descartar los cambios realizados y comenzar desde 0.

Modificación de datos relativos al entorno

Una vez hecha la descarga de los archivos deberemos modificar los que contienen datos relativos a nuestro host. En nuestro ejemplo, el archivo wp-config.php almacena la inforación de la conexión a la base de datos. En vuestro caso debereis localizar que archivos contienen este tipo de información antes de seguir avanzando.

La estrategia que seguiremos para ello sera la de realizar una copia inicial de forma manual de los archivos sensibles al entorno de pruebas. Una vez hecha actualizaremos los datos necesarios.

Por otro lado, automatizaremos una tarea que renombra estos archivos en la ubicación intermedia, de forma que cuando realicemos la copia al entorno de pruebas no se sobrescriban. Así que agregamos estas dos líneas a nuestro script:

rm ~/webBackUp/ftp.url.com/w-config.php.renamed
mv ~/webBackUp/ftp.url.com/w-config.php ~/webBackUp/ftp.url.com/w-config.php.renamed

Copia de archivos a la ubicación definitiva

Ya con los archivos descargados y una vez resuelta la problemática de la información sensible al entorno copiamos los archivos:

cp -r ~/webBackUp/ftp.url.com/* /var/www/targetVHost

Como vemos, este sistema solo copia los archivos nuevos y/o que han sufrido cambios, pero si hemos eliminado un archivo de nuestro host remoto no lo eliminará de nuestro host local. Para mi esta situación no supone un problema a día de hoy, así que simplemente no hago nada, pero siempre se puede preparar algún sistema que busque la diferencia de archivos entre la copia intermedia y el entorno de prueba y elimine los sobrantes de esta segunda ubicación.

El script

Y todo el rollazo que os he soltado se traduce básicamente en el siguiente script:

#!/bin/bash

wget -r -N -q --level=15 --user=user --password='password' --directory-prefix=~/webBackUp fttp://ftp.url.com
rm ~/webBackUp/ftp.url.com/w-config.php.renamed
mv ~/webBackUp/ftp.url.com/w-config.php ~/webBackUp/ftp.url.com/w-config.php.renamed
cp -r ~/webBackUp fttp://ftp.url.com/* /var/www/targetVHost

Programar la ejecución de la copia

Al igual que hicimos con la clonación de la base de datos programamos la ejecución del script con Cron:

crontab -e

E incluimos la siguiente línea en el archivo crontab:

0 2 * * 5 ~/scripts/clonWebFiles.sh

Aunque en principio ambos script podrían ejecutarse a la misma vez, hemos sido precavidos retrasando una hora la ejecución de la copia de los archivos, de forma que se ejecute cada viernes a las 02:00 de la madrugada.

Créditos y Referencias

• Articulo de la serie: Clonar una web en un servidor local.
• Entrega previa de la seie: Clonar una web: la base de datos.
• Imagen de portada: Martin Harry.

Y cuando hablamos de «una copia exacta», queremos decir que tanto archivos como bases de datos estén perfectamente actualizados. Esto es muy útil para realizar pruebas de todo tipo: nuevos plugins, cambios de configuración, revisión de actualizaciones, etc.

Realizar esta tarea manualmente es tedioso, aburrido y consume mucho tiempo, eso sin contar que es probable que cuando nos propongamos realizar nuestras pruebas este entorno esté desactualizado, alterado por las últimas pruebas realizadas, o lo que es aún peor, no esté disponible. Así que una buena idea es automatizar esta tarea y programar su ejecución con la periodicidad que nos interese.

Algunos aspectos relativos al clonado

Resumen del proceso

Es buena idea tener una visión general del proceso antes de adentrarnos en él. Lo que vamos a hacer básicamente es un proceso ETL (Extract, Transform, Load) manual.

Como parte del proceso de extracción realizaremos una copia de seguridad de la base de datos y la descargaremos a una ubicación intermedia. Haremos lo mismo con los archivos del servidor.

Una vez tenemos todo lo necesario en nuestro servidor local, modificamos algunos datos como son archivos de configuración o los registros en la base de datos relativos al entorno.

Finalmente restauraremos la base de datos y sobrescribiremos los archivos de nuestro servidor local.

Local versus Remoto

A pesar de que cada una de las tareas que realizaremos no son complicadas por si mismas, alternaremos de host continuamente y eso puede generar alguna confusión, así que para seguir los pasos indicados sin error deberemos estar muy atentos al host en el que se realizan las distintas acciones. Identificaremos los hosts como «remoto», el servidor de producción que queremos clonar, y «local» el servidor de pruebas dónde queremos tener la copia.

Es importante que las versiones de LAMP (Linux, Apache, PHP y MySQL) sean lo más similar posible, de este modo es posible que nos ahorraremos algunos quebraderos de cabeza. Además, es recomendable dedicar un virtual host de Apache para este entorno en nuestro servidor local.

Ejemplo sobre WordPress

Y ya que estas líneas que lees están escritas sobre WordPress, utilizaremos esta plataforma como ejemplo para realizar el clonado. Esto quiere decir que por norma general, si queréis clonar otra plataforma, las mayores diferencias las encontraremos en los los registros de la base de datos y los archivos de configuración referentes al entorno.

Periodicidad

Como hemos dicho queremos automatizar el clonado de nuestra web para tener nuestra réplica preparada y actualizada en todo momento. Podemos establecer la periodicidad que más nos convenga, personalmente estoy cómodo con una semana por dos motivos:

1. En una semana no suelen producirse muchos cambios en el blog.
2. Algunas pruebas se extienden durante varios días, y una restauración diaria las sobrescribiría.

Además, siempre estamos a tiempo de lanzar una actualización manual en caso de ser necesario con la simple ejecución de un script. Si no tienes una web muy grande el proceso será relativamente rápido.

Requisitos hardware

En cuanto a los requisitos de hardware puedes estar tranquilo, pues no necesitas un gran servidor para implementar este sistema. Un ejemplo muy claro de ello es que para este blog lo tengo implementado con una humilde Raspberry Pi. Por si te interesa, aquí te dejo un enlace en el que puedes ver cómo de sencillo es montar un servidor web Apache sobre una Raspberry Pi.

Clonando nuestra web: el proceso

Llegados a este punto creo que al igual que yo ya tendréis ganas de poneros manos a la obra, así que no me enrollo más y vamos al lío.

Y puesto que esto se ha alargado un poco más de la cuenta, hemos dividido este artículo en varias entregas para que sea más fácil de seguir:

1. Clonar una web en un servidor local (es decir, esta entrada).
2. Clonar una web: la base de datos.
3. Clonar una web: los archivos.

Créditos y referencias

• Imagen de portada: Martin Harry.

Esta entrada continua el contenido iniciado en el artículo VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu, desde dónde enlazamos más contenido relacionado con la insralación y la configuración de vsftp.

Usuarios virtuales vs usuarios de sistema

La configuración por defecto de vsftp nos permite autentificarnos con las credenciales de los usuarios que tengamos creados en el sistema, dándonos acceso a las mismas carpetas a las que estos tienen acceso. Pero además nos permite autentificarnos con usuarios virtuales creados especificamente para acceder por ftp a una determinada carpeta. Y lo mejor de todo es que estas dos opciones son totalmente compatible entre si, pudiendo elegir entre:

1. Habilitar solo el acceso de los usuarios del sistema (por defecto).
2. Habilitar solo el acceso de usuarios virtuales.
3. Habilitar el acceso de usuarios del sistema y usuarios virtuales.

/etc/vsftps.conf

Para no extendernos demasiado en esta entrada, a continuación veremos el resultado final del archivo /etc/vsftpd.conf. Si estás interesado en conocer los detalles de cada línea de configuración puede echarle un vistazo a la documentación oficial de vsftp en este enlace. Para facilitar la lectura hemos eliminado todas las líneas de comentarios originales del archivo:

# configuración excluyendo comentarios
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
secure_chroot_dir=/var/run/vsftpd/empty
user_sub_token=$USER
hide_ids=YES
listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
chroot_local_user=YES
allow_writeable_chroot=YES
hide_ids=YES

# Configuración específica de usuarios virtuales
user_config_dir=/etc/vsftpd/usersConf
guest_enable=YES
virtual_use_local_privs=YES
pam_service_name=vsftpd

Creación de usuarios virtuales

Una vez realizada la configuración de vsftp, lo siguiente que haremos será crear los usuarios virtuales. Para ello crearemos un directorio dónde alojar los ficheros de autentificación y acto seguido los propios ficheros, que en este ejemplo serán dos, uno por usuario. Por algún motivo que desconozco no he podido hacer funcionar la autentificación con PAM sin incluir la opción -d en la creación de los ficheros de autentificación, lo que nos limita a contraseñas con un máximo de 8 caracteres, una opción que lamentablemente reduce bastante la seguridad.

sudo mkdir /etc/vsftpd
sudo htpasswd -c -d /etc/vsftpd/ftpd.passwd ftpUser1
sudo htpasswd -d /etc/vsftpd/ftpd.passwd ftpUser2

El comando htpasswd nos solicitará que definamos la contraseña y que la confirmemos, y ojo que en el segundo usuario hemos omitido la opción -c, solo es necesario incluirla con el primer usuario, si la incluimos en el segundo o sucesivos truncaremos el fichero y por lo tanto únicamente dejaremos el último usuario que hemos creado.

Instalación y Configuración de PAM

Como adelantabamos en el punto anterior utilizaremos PAM (Pluggable Authentication Modules) para la autentificación de los usuarios, así que si no lo tenemos instalado deberemos hacerlo:

sudo apt-get update
sudo apt-get install libpam-pwdfilev

El archivo de configuración de PAM para el servicio vsftp por defecto se encuentra en /etc/pam.d/vsftp, notad que hicimos referencia a él en la configuración de vsftp mediante la directiva pam_service_name. Así que por seguridad realizaremos una copia de seguridad de este archivo y acto seguido lo editaremos de forma que quede así:

auth required pam_pwdfile.so pwdfile /etc/vsftpd/ftpd.passwd
account required pam_permit.so

Como ves, le estamos indicando que utilice el archivo que acabamos de crear con el comando htpasswd para autentificar a los usuarios virtuales.

Directorios de usuarios virtuales

El último paso que nos queda para tener nuestro servicio funcionando es definir cuales serán los directorios a los que tendrán acceso los usuarios. Para realizar esta configuración crearemos un archivo por cada usuario al que estemos concediendo acceso, y para mantenerlos organizados los almacenaremos dentro de un directorio que crearemos a tal efecto, al que ya hemos hecho referencia en /etc/vsftpd.conf mediante la directiva user_config_dir. El nombre de cada archivo debe ser idéntico al nombre de usuario al que hace referencia:

sudo mkdir /etc/vsftpd/usersConf
sudo vim /etc/vsftpd/usersConf/ftpUser1
sudo vim /etc/vsftpd/usersConf/ftpUser2

El contenido de cada archivo debe hacer referencia al directorio al que le estamos concediendo acceso de la siguiente manera:

local_root=/var/www/targetDir

Permisos de escritura

Un aspecto de gran importancia es configurar correctamente los permisos de escritura del directorio de cada usuario, en caso contrario nos encontraremos con un error cuando intentemos cargar cualquier archivo en nuestro servidor.

En nuestro caso, estamos concediendo acceso a una carpeta de un servidor web, así que daremos por hecho que los permisos están configurados tal y como explicamos en la entrada Archivos y permisos de usuario en Apache 2 y Linux.

sudo usermod -a -G www-data ftpd
sudo chown ftpd:www-data /var/www/users/ftpUser1

Comprobamos que todo funciona

Reiniciamos el servidor y comprobamos que todo funciona:

sudo service vsftpd restart

Recuerda que si tienes algún problemalor archivos de logs de vsftp están en /var/log/vsftp.log y los logs de autentificación /var/log/auth.log.

Lamentablemente, según mi experiencia, esa practica no está tan extendida en los servidores ftp, dónde a día de hoy todavía todavía existen un gran número de ellos que no implementan el protocolo FTPS, haciendo uso de conexiones sin encriptar y por lo tanto menos seguras. Una lástima teniendo en cuenta que no es algo complicado.

Hoy veremos cómo habilitar el protocolo FTPS en nuestro servidor vsftp, ampliando el contenido publicado en el artículo VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu. Además, es muy probable que también te interese echarle un vistazo a la entrada FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes, pues es una buena introducción si no estás familiarizado con estos protocolos.

Esta configuración está realizada sobre Ubuntu Mate 16.0.4.2 corriendo en una Raspberry PI, pero es perfectamente aplicable a otras distribuciones y versiones de Linux y otros hardwares.

Asumiremos que ya tenemos nuestro servidor vsftp funcionando y que tenemos OpenSSL instalado. Así que el primer paso será crear los certificados SSL pertinentes:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem

A continuación agregamos las siguientes líneas al final del archivo /etc/vsftpd.conf:

# Opciones para el certificado SSL
rsa_cert_file=/etc/ssl/private/vsftpd.pem
rsa_private_key_file=/etc/ssl/private/vsftpd.pem
ssl_enable=YES

Ya solo nos queda reiniciar el servidor y comprobar que la configuración que hemos aplicado funciona correctamente.

sudo service vsftpd restart

Y con estos sencillos pasos hemos terminado, mejorando notablemente la seguridad de nuestro servidor FTP.

Esta entrada pertenece a la serie de artículos sobre cómo utilizar una Raspberry PI como herramienta de apoyo para el desarrollo web, y veremos como instalar y configurar vsftp en Ubuntu, crear usuarios virtuales y habilitar el acceso con el protocolo FTPS.

vsftp

Puestos a implementar una solución ftp el primer paso será elegir uno de las muchas posibilidades que existen en el mercado. Si ya hemos descartado el protocolo SFTP, y queremos un servidor FTP o FTPS que nos permita mantener la simplicidad pero ampliando la versatilidad, y que además esté disponible bajo licencia de software libre, vsftp (Very Secure FTP) es una buena opción.

Además otra de las ventajas de Vsftp es que su uso está muy extendido y es fácil resolver cualquier duda con alguna consulta en internet, y entre algunas de sus características podemos destacar:

• Usuarios virtuales
• Configuración avanzada por usuario
• Configuración por IP de origen
• Límites por IP de origen
• Limitación de ancho de banda
• Encriptación sobre SSL

Características más que suficientes para cubrir muchos de los casos que podemos necesitar.

Por otro lado, si leiste el articulo FTP, FTPS y SFTP: diferencias, ventajas e inconvenientes, es interesante destacar que es totalmente compatible tener habilitado el acceso SFTP y el acceso FTP y FTPS con Vsftp. Esto nos permitiría por ejemplo utilizar SFTP para los usuarios del sistema y FTPS para una lista de usuarios específicos con unas necesidades distintas.

Instalar vsftp

Como es habitual la instalación de cualquier programa incluido en los repositorios de una distro es algo muy sencillo.

sudo apt-get update
sudo apt-get install vsftpd

Tras la instalación de vsftp el servidor es perfectamente funcional con los usuarios del sistema

Configurar vsftp

La configuración de vsftp ofrece muchas posibilidades y se realiza en el archivo /etc/vsftpd.conf, puedes ver todas las opciones de configuración que tiene en este enlace.

En cuanto a las configuraciones que vamos a aplicar lo haremos en entradas separadas para facilitar la organización y la lectura y evitar que esto se convierta en un artículo demasiado largo y aburrido. A continuación tienes los enlaces:

• Creación y configuración de usuarios virtuales
• Habilitar el acceso por FTPS

Comprobamos que todo funciona

Después de aplicar cualquier configuración deberemos probar que funciona correctamente, para ello el primer paso será reiniciar el servidor para aplicar la nueva configuración y acto seguido conectarnos con nuestro cliente ftp favorito.

sudo service vsftpd restart

En caso de que tengamos algún tipo de problema podemos revisar los logs de vsftp en /var/log/vsftp.log y los logs de autentificación /var/log/auth.log. Ojo que podemos tener más de un archivo de log por servicio.

El uso del FTP suponía para mi una de esas situaciones, lo utilizo con relativa frecuencia pero nunca me había cuestionado cual era la diferencia entre FTPS y SFTP. Si bien sabía que ambos añadían una capa de encriptación con respecto al protocolo FTP,  desconocía por completo que era lo que les distinguía. Así que cuando configuraba una nueva conexión, seleccionaba la opciones que me permitía conectar sin darle mayor importancia.

El caso es que hace unas semanas instalé un servidor FTP en mi Raspberry. No es el primero que instalo, pero cuando lo he hecho siempre han estado destinados a ámbitos muy concretos, protegidos por una red local y su uso ha sido prácticamente unipersonal,  por lo que nunca me preocupé demasiado por los detalles más allá de que me permitieran conectar y hacer mi trabajo.

La diferencia fue que en esta ocasión quise profundizar un poco más, conocer exactamente la diferencia entre los distintos protocolos y aplicar configuraciones más complejas y eso es lo que os cuento en esta y otras entradas que vendrán.

FTP

FTP son siglas de File Transfer Protocol, es un protocolo que lleva con nosotros desde la década de los 70 y fue diseñado para la transferencia de archivos a través de la red con  una configuración de cliente-servidor.

Su principal defecto es que carece de capa alguna de seguridad, los datos viajan por la red en texto plano, sin encriptación, de modo que es muy sencillo interceptar no solo los archivos que se transmiten sino también los datos de autentificación. Por otro lado, esta ausencia de encriptación es la responsable de que sea el protocolo de transmisión más rápido de los que veremos en esta entrada, pues no existe consumo de recursos relacionados con la encriptación y el tamaño de los paquetes transmitidos es menor.

Por defecto hace uso del puerto 21 y es el precursor de los otros dos protocolos que vamos a ver en esta entrada.

FTPS

Las siglas FTPS provienen de FTP over SSL y no es más que el protocolo estándar FTP transmitido sobre una conexión segura. Inicialmente la conexión segura hacía referencia únicamente  SSL (Secure Sockets Layer), pero con el  paso del tiempo y la aparición del protocolo TLS (Transport Layer Security), también soporta este último. Este protocolo hace uso de dos canales diferentes: uno de control y otro de transferencia, y tiene dos variantes bien diferenciadas:

• FTP implicito sobre SSL. Recibe este nombre porque la conexión cifrada es implicita, es decir, ocurre desde un primer instante, sin necesidad de solicitarla, motivo por el cual además está desaconsejada (deprecated). Por defecto utiliza el puerto 990 para el canal de control y el 998 para el de datos, de forma que el puerto 21 permanece libre para poder ofrecer un servicio FTP estandar. En cualquier caso los dos canales viajan encriptados.
• FTP explicito sobre SSL o también conocido como FTPES. El cliente establece una conexión FTP estándar mediante el puerto 21 con el servidor y una vez conectado se solicita explícitamente la negociación SSL, de ahí el nombre. En función de la configuración del servidor, si el cliente no solicita la encriptación es posible que ocurran dos cosas: que se rechace la conexión o que se establezca una conexión FTP estándar (insegura). Esta variante permite decidir si queremos encriptar los canales de control y transferencia o si por el contrario solo queremos encriptar uno de ellos.

Un aspecto que puede resultar negativo de este protocolo es que por el hecho de utilizar más de un canal puede resultar problemático con algunas configuraciones en los firewalls, así que es posible que si tenemos un firewall en funcionamiento e implementamos un servidor FTPS nos veremos obligados a revisar su configuración.

STFP

SFTP o SSH File Transfer Protocol es un protocolo que «simula» el comportamiento del protocolo FTP pero que realmente poco o nada tiene que ver con él, no es una extensión o una mejora como puede ser FTPS, si no que fue desarrollado desde cero.

Tanto los datos de control como de transferencia se transmiten siempre encriptados y por un único canal, utilizando para ello el puerto 22 al igual que el protocolo SSH (Secure SHell) sobre el que está construido. Posiblemente por este motivo muchos servidores FTP implementan los protocolos FTP Y FTPS pero no SFTP. En su lugar podemos ver implementaciones  de servidores SFTP de la mano de los propios servidores de SSH, algunos ejemplos son OpenSSH o LSH.

SFTP ha sido el último protocolo en llegar y cabe destacar que su especificación nunca ha pasado de ser un borrador, es decir, no existe un documento RFC.

Conclusión

Es interesante conocer qué hay detrás de los distintos protocolos de transmisión de ficheros para poder decidir cual es el que mejor se adapta a las necesidades que tengamos en cada momento.

Mi recomendación dependerá del uso que le vayamos a dar, pero siempre que sea posible utilizaría un protocolo que implemente una capa de encriptación y no esté desaconsejado (deprecated), es decir: SFTP o FTPES.

¿Y tú qué opinas al respecto? ¿Qué protocolo prefieres y por qué? ¿Has tenido alguna mala experiencia por utilizar un FTP sin encriptación? Déjanos un comentario contándonos tu experiencia.

Créditos, referencias y artículos relacionados

• VSFTP instalar y configurar un servidor FTP en una Raspberry Pi con Ubuntu
• FTPS o cómo habilitar SSL en vsftp
• Usuarios virtuales en vsftp