FTP sigue apareciendo en migraciones, copias de seguridad, NAS antiguos y equipos que todavía necesitan mover ficheros sin tocar demasiado la infraestructura. En el puerto 21 se negocia la sesión: autenticación, navegación por directorios y órdenes de transferencia, pero no el archivo en sí. Esa separación explica por qué un acceso puede abrir sesión sin que, después, funcionen los listados o las descargas.
Lo esencial para entender FTP sin perder tiempo
- 21/TCP gestiona comandos, respuestas y autenticación; el contenido viaja por otra conexión.
- El canal de datos no es fijo: cambia según uses modo activo o modo pasivo.
- Detrás de NAT y cortafuegos, el modo pasivo suele ser el más estable y predecible.
- FTP sin cifrado expone credenciales y archivos; FTPS y SFTP reducen ese riesgo de forma notable.
- Si entras al servicio pero no ves directorios o no descargas nada, el fallo suele estar en los puertos de datos.
Cómo se separan los comandos de los datos en FTP
Yo suelo explicarlo como dos conversaciones paralelas. La primera, sobre 21/TCP, sirve para decirle al servidor quién soy, qué directorio quiero ver y qué operación voy a hacer; la segunda transporta la carga útil, es decir, el contenido real del fichero o del listado.
- USER y PASS autentican.
- CWD, PWD y LIST navegan por el árbol de directorios.
- RETR descarga archivos y STOR los sube.
La consecuencia práctica es clara: el canal de control puede estar sano y, aun así, fallar la transferencia si la otra conexión no encuentra un camino abierto de ida y vuelta. Esa separación es la que complica el panorama cuando aparece un cortafuegos, y ahí entra el modo de transferencia.
Modo activo y modo pasivo, la parte que suele romperse
La diferencia más importante no está en el login, sino en quién inicia la conexión de datos. Ahí es donde los cortafuegos y el NAT deciden si la sesión fluye o se queda a medias.
| Aspecto | Modo activo | Modo pasivo |
|---|---|---|
| Quién inicia la conexión de datos | El servidor se conecta de vuelta al cliente | El cliente se conecta a un puerto anunciado por el servidor |
| Puerto que suele intervenir | 20 como origen del servidor en la transferencia de datos | Un puerto alto, normalmente dentro de un rango configurado |
| Problema típico | El cortafuegos del cliente bloquea la conexión entrante | El rango pasivo no está abierto o la IP anunciada es incorrecta |
| Encaje habitual | Redes muy controladas o escenarios heredados | Entornos con NAT, usuarios remotos y acceso desde Internet |
Si yo depuro un caso real y veo que el usuario sí entra pero el listado se queda colgado, casi siempre miro tres cosas antes que nada: el rango pasivo no está publicado, la IP pública anunciada por el servidor no coincide con la real o el cortafuegos está dejando pasar el canal de control pero no los puertos altos.
En otras palabras: el problema rara vez es el nombre de usuario. Casi siempre es la ruta que deben seguir los datos. Y esa pista nos lleva directamente a la parte de seguridad, que es donde FTP enseña sus limitaciones más serias.
Qué cambia en seguridad y por qué yo no expondría FTP plano
Desde seguridad, FTP sin cifrar sigue siendo flojo por una razón simple: credenciales y contenido viajan en claro. En una red Wi-Fi compartida, en una LAN mal segmentada o en una salida a Internet expuesta, eso deja margen para captura pasiva, robo de sesión y ataques de fuerza bruta sobre la cuenta.
También conviene recordar el viejo abuso del comando PORT, conocido como FTP bounce: no es el escenario más frecuente hoy, pero sí un recordatorio de que abrir este servicio sin control da más superficie de la que parece. Si además el servidor acepta cuentas débiles o anonimizadas sin restricciones, el riesgo deja de ser teórico.
| Opción | Cifrado | Puerto habitual | Mi criterio |
|---|---|---|---|
| FTP | No | 21/TCP y, según el modo, 20 o puertos altos | Solo para legado muy controlado |
| FTPS explícito | Sí, mediante TLS | 21/TCP más el rango de datos que definas | La mejor salida si necesitas seguir hablando FTP |
| SFTP | Sí, sobre SSH | 22/TCP | Mi preferido cuando puedo elegir desde cero |
La clave técnica aquí es sencilla: FTPS explícito mantiene la lógica de FTP y negocia seguridad sobre el canal de control con comandos como AUTH TLS; SFTP, en cambio, no es una variante de FTP, sino otro protocolo distinto sobre SSH. El FTPS implícito, asociado a puertos dedicados como 990 en algunos entornos, existe, pero yo lo trato más como una herencia histórica que como una elección moderna.
Con eso claro, lo útil es pasar del riesgo teórico a la configuración real: qué abrir, qué limitar y qué comprobar para que el servicio funcione sin regalar superficie de ataque.
Qué abrir en firewall, NAT y router para que funcione sin sobresaltos
La regla que mejor me ha funcionado es aburrida, pero evita incidencias: abrir lo mínimo, fijar el rango pasivo y anunciar la IP correcta si el servidor está detrás de NAT. Todo lo demás acaba siendo ruido.
- Abrir 21/TCP solo hacia el servidor o servicio que realmente lo necesita.
- Definir un rango pasivo fijo, por ejemplo 50000-51000, en vez de dejar que el servidor elija al azar.
- Permitir ese rango en el cortafuegos perimetral y en el router si hay redirección de puertos.
- Si el servidor está detrás de NAT, publicar la IP pública en la respuesta PASV para que el cliente no intente conectar a una dirección privada.
- Probar autenticación, listado de directorios, subida y descarga por separado.
- Si usas FTPS, verificar que el rango pasivo sigue abierto, porque cifrar el canal no elimina la necesidad de los puertos de datos.
En la práctica, el síntoma más común es sencillo: entra usuario y contraseña, pero LIST o RETR se quedan esperando. Ese patrón casi siempre apunta a una regla incompleta, no a un problema de credenciales. Y cuando ya tienes eso controlado, la decisión importante pasa a ser otra: si merece la pena mantener FTP o si conviene retirarlo.
Lo que revisaría antes de dejarlo en producción
Yo reservaría FTP para tres escenarios muy concretos: una migración temporal, un ecosistema heredado que no admite otra cosa o una red interna muy segmentada. Fuera de ahí, la superficie de ataque y la falta de cifrado pesan demasiado como para tratarlo como una opción general.
- Si necesitas compatibilidad, usa FTPS explícito y limita por IP, usuario y rango pasivo.
- Si empiezas de cero, SFTP suele simplificar más porque evita el doble canal de FTP.
- Si solo lo mantienes por costumbre, merece la pena replantearlo: el canal de control no es el problema, la exposición innecesaria sí.
Mi lectura final es simple: 21/TCP sigue teniendo sentido cuando hay legado y control del entorno, pero no cuando el servicio queda expuesto sin una razón operativa clara. Si puedes elegir, reduce la dependencia del FTP clásico y deja este protocolo como una excepción bien acotada, no como la base de tu intercambio de archivos.
