Protocolos de transferencia de archivos: Parte 1 — FTP

FTP (File Transfer Protocol) — uno de los protocolos más antiguos de internet. Su especificación vigente, RFC 959, fue adoptada en 1985 y desde entonces el protocolo casi no ha cambiado. FTP aún se encuentra en proveedores de hosting, en equipos de red, en sistemas contables y de almacén antiguos. Para trabajar correctamente con él —o para justificar su abandono— es útil entender cómo está diseñado.

Dos conexiones: control y datos

La principal característica de FTP es que usa dos conexiones TCP separadas.

• Conexión de control. El cliente se conecta al servidor en el puerto 21 y mantiene esa conexión durante toda la sesión. Por ella se envían comandos de texto (USER, PASS, LIST, RETR, STOR) y respuestas del servidor con códigos de tres dígitos.
• Conexión de datos. Para cada transferencia de archivo o listado de directorio se abre una conexión separada, que se cierra después de la transferencia.

Precisamente la segunda conexión genera la mayoría de los problemas con cortafuegos y NAT.

Modo activo y pasivo

El modo determina quién abre la conexión de datos.

Modo activo (comando PORT). El cliente informa al servidor su dirección y puerto, y el servidor se conecta al cliente —según RFC 959 desde el puerto 20. Si el cliente está detrás de NAT o un cortafuegos, la conexión entrante desde el servidor no llegará. Por eso en la práctica el modo activo casi no funciona.

Modo pasivo (comando PASV, para IPv6 — EPSV según RFC 2428). El servidor abre un puerto y se lo comunica al cliente, y el cliente se conecta. Para un cliente detrás de NAT esto es cómodo, pero ahora el servidor debe aceptar conexiones entrantes en puertos arbitrarios. De aquí surgen dos configuraciones imprescindibles:

1. Rango de puertos pasivos. El servidor elige puertos solo dentro de un rango definido, y ese es el que debe abrirse en el cortafuegos.
2. Dirección externa. Si el propio servidor está detrás de NAT, debe comunicar al cliente la dirección pública, no la interna, de lo contrario el cliente intentará conectarse “a ninguna parte”.

Problema principal: todo se transmite en texto sin cifrar

En el FTP clásico no hay cifrado. Los comandos USER y PASS con usuario y contraseña, los listados de archivos y los propios archivos viajan por la red tal cual. Cualquiera que pueda interceptar el tráfico —en una red Wi-Fi pública, el proveedor, o un nodo intermedio— verá la contraseña.

Por eso FTP sin cifrado solo es aceptable en una red aislada donde la interceptación quede excluida. Para transferencias por internet se usan FTPS o SFTP.

Configuración mínima segura de vsftpd

vsftpd es el servidor FTP más común en distribuciones Linux. Si aún se necesita FTP, aquí hay un conjunto básico de parámetros sacados de man vsftpd.conf:

# /etc/vsftpd.conf
listen=YES
anonymous_enable=NO          # acceso anónimo desactivado (por defecto YES)
local_enable=YES             # acceso con usuarios del sistema
write_enable=YES             # permitir subir archivos
chroot_local_user=YES        # encerrar al usuario en su directorio home

# modo pasivo: rango estrecho de puertos para el cortafuegos
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=40100
# pasv_address=203.0.113.10  # si el servidor está detrás de NAT — dirección externa

# cifrado (FTPS)
ssl_enable=YES
rsa_cert_file=/etc/ssl/certs/ftp.example.ru.pem
rsa_private_key_file=/etc/ssl/private/ftp.example.ru.key
force_local_logins_ssl=YES   # contraseña solo por canal seguro
force_local_data_ssl=YES     # datos también

Lo importante:

• anonymous_enable está activado por defecto — hay que desactivarlo explícitamente.
• pasv_min_port y pasv_max_port por defecto valen 0, es decir, el servidor toma cualquier puerto libre. Sin un rango no es posible configurar correctamente el cortafuegos.
• chroot_local_user impide que el usuario salga del directorio home. Es mejor que la raíz del chroot no sea escribible por el usuario, y colocar los archivos en un subdirectorio.
• Con ssl_enable=YES y los parámetros force_*_ssl el servidor se convierte de facto en FTPS: no será posible iniciar sesión sin TLS.

Las reglas del cortafuegos para un servidor así son: puerto 21 y el rango 40000–40100/TCP. Para UFW:

sudo ufw allow 21/tcp
sudo ufw allow 40000:40100/tcp

Dónde FTP aún tiene sentido

• Dispositivos que solo admiten FTP: impresoras multifunción antiguas con escaneo a carpeta, cámaras IP, equipos industriales.
• Paneles de hosting donde FTP es la única forma de subir archivos del sitio. Si el proveedor soporta SFTP, es mejor pasarse a él.
• Intercambio con un tercero cuya sistema solo soporta FTP. En ese caso, al menos usar FTPS y una cuenta separada con permisos mínimos.

Errores típicos

• Puerto 21 abierto, pero no el rango de puertos pasivos. El cliente se conecta y se autentica, pero se queda colgado al intentar obtener el listado de archivos.
• Servidor detrás de NAT sin pasv_address. El servidor comunica al cliente una dirección interna y la conexión de datos no se establece.
• Acceso anónimo “temporal”. Un FTP abierto con escritura anónima se encuentra y se usa rápidamente para almacenar archivos de terceros.
• FTP sin TLS a través de internet. La contraseña del servidor se filtra en la primera intercepción. Si esa misma contraseña se usa para SSH o correo, todo queda comprometido de inmediato.

Conclusión

FTP es simple y está ampliamente soportado, pero su arquitectura —dos conexiones y texto sin cifrar— no encaja bien con el internet moderno. Debe usarse solo donde sea imprescindible y siempre con cifrado. Para tareas nuevas es mejor elegir directamente SFTP.