Resumen

  • FTP usa una conexión para órdenes y otra para datos. El cliente iniciaba la primera, mientras el servidor abría normalmente la segunda hacia un puerto anunciado por el cliente.
  • Los filtros de paquetes interpretaban esa devolución de llamada como una conexión entrante nueva e imprevisible. RFC 1579 recomendó PASV: el servidor escucha y el cliente inicia también el canal de datos.
  • EPSV reutilizó la dirección del par de control y devolvió solo un puerto, lo que redujo la intervención de NAT. El cambio de sentido no autenticó al par: el rebote activo y el robo de puertos pasivos conservaron riesgos propios.

Dos conexiones detrás de una sola sesión

La definición de RFC 959 separa con claridad el diálogo de control y el transporte de datos. Usuario y servidor pueden mantener órdenes y respuestas mientras abren y cierran un canal distinto para una lista de directorio o un archivo.

La iniciativa no era simétrica. El cliente abría el control, pero su proceso de datos quedaba normalmente a la escucha y el servidor lo llamaba al comenzar la transferencia. Mediante PORT, el cliente podía escoger otro host y puerto. Esa libertad hacía posible que dos servidores transfirieran directamente bajo el control de un tercero.

El campo indicaba dónde conectar; no demostraba quién poseía el destino. Esa diferencia tardaría en convertirse en un problema visible.

El borde cambió el significado de la llamada

En 1994, RFC 1579 describió clientes que elegían un puerto nuevo en cada operación. Para un cortafuegos de paquetes, la conexión que regresaba desde el servidor no aparecía como continuación natural del login: era una llamada externa a un puerto alto que cambiaba sin cesar.

Permitir cualquier puerto anulaba la protección. Exigir al filtro que entendiera todos los estados de FTP añadía dependencia y complejidad. El fallo surgía de una composición: FTP delegaba en el cliente la dirección del retorno; el borde solo confiaba en conexiones nuevas iniciadas desde dentro.

PASV resolvió el desacuerdo con una regla que ya existía. El servidor abre un puerto de escucha y lo anuncia; el cliente realiza la apertura activa. Control y datos comienzan entonces desde el lado protegido. Bellovin recomendó que los clientes usaran este modo como comportamiento habitual, no solo como excepción para cortafuegos.

No cambió el formato de los archivos ni fusionó los canales. Tampoco necesitaba más mensajes que el patrón común con PORT. Las implementaciones que no reconocían PASV podían responder con error y el cliente podía volver al modo activo, aunque ese retorno siguiera sin atravesar la misma política de borde.

Esa coexistencia importa. La recomendación no eliminó el código antiguo por decreto. Cada cliente, servidor y red determinó qué combinación funcionaba. Incluso la propuesta APSV, pensada para hacer pasivas todas las operaciones, quedó sin implementación conocida: el documento llegó más lejos que el sistema en marcha.

Un puerto bastaba; la dirección sobraba

Los comandos clásicos empotraban una dirección IPv4 además del puerto. IPv6 rompía el tamaño supuesto, y NAT podía hacer que la dirección escrita dentro del diálogo fuera distinta de la observada en el transporte. El traductor debía inspeccionar y modificar contenido de aplicación para mantener la sesión.

RFC 2428 definió EPRT y EPSV. EPRT conserva la operación activa con familia de red, dirección y puerto. EPSV entrega únicamente el puerto de escucha y toma la familia y la dirección de la conexión de control.

En una transferencia entre las mismas dos máquinas, la conexión existente ya había decidido el par. Repetir su dirección creaba un dato que podía quedar obsoleto o ser reescrito. La respuesta extendida mantuvo solo la novedad necesaria.

Con EPSV ALL, el cliente puede cerrar las demás opciones dentro de esa sesión. Una vez aceptado, el servidor rechaza PORT, PASV, EPRT y cualquier alternativa. Si después se necesita una transferencia a tres bandas, se abre otra sesión. La decisión tiene un ámbito comprensible y una salida limpia.

El rebote reveló autoridad excesiva

RFC 2577 examinó cómo PORT podía ordenar al servidor FTP que conectara con una máquina y servicio ajenos. Después, el atacante hacía que enviara datos preparados. El servidor actuaba como rebote, ocultaba el origen y podía franquear restricciones basadas en direcciones.

Las defensas sugeridas incluían rechazar puertos inferiores a 1024, desactivar PORT donde no fuera necesaria la transferencia entre servidores y comprobar las direcciones de control y datos cuando la política dependiera de la ubicación.

El modo pasivo no quedó libre de autoridad mal asignada. Su servidor abre un puerto efímero. Si un intruso puede predecirlo y llega antes, puede bloquear al cliente, robar un archivo o introducir datos falsos. De ahí la recomendación de escoger puertos locales aleatorios y verificar que el par de datos corresponde al contexto de control.

El sentido de la apertura ofrece una propiedad de encaminamiento, no una identidad. “Sale desde dentro” describe el primer paquete; no demuestra que el proceso al otro extremo sea el que se autenticó.

La extensión mínima preservó decisiones locales

FTP compartió solo el mecanismo para anunciar un oyente y establecer el segundo camino. El cliente decide qué modo solicitar. El servidor decide qué puerto abre y qué destinos activos admite. El cortafuegos conserva su política de flujo. Los extremos unen ambas conexiones a la misma operación y cuenta.

Así pudo cambiar el uso sin un cambio universal. El activo sobrevivió donde tenía sentido. El pasivo avanzó donde el borde lo exigía. EPSV simplificó el caso de dos pares; EPRT mantuvo la excepción. Adoptar, rechazar o iniciar una sesión nueva era una consecuencia operativa, no un veredicto institucional.

Fuentes y límites

RFC 959 define las dos conexiones, PORT y PASV. RFC 1579 explica el conflicto con los filtros. RFC 2428 especifica EPRT, EPSV y EPSV ALL. RFC 2577 documenta rebote, comprobación de pares y robo de puertos.

Estos RFC no miden el uso actual ni garantizan la conducta de cada implementación, proxy, NAT o cortafuegos. Tampoco convierten el FTP pasivo en un transporte seguro. Sí sostienen una conclusión histórica acotada: invertir quién abre el canal de datos permitió atravesar una nueva frontera sin transferir a esa frontera toda la autoridad de la aplicación.