Resumen

  • La especificación FTP de 1985 permitía que dos servidores se pasaran un archivo sin hacerlo circular por el cliente; PORT indicaba un punto alternativo para la conexión de datos.
  • En 1999, RFC 2577 mostró cómo esa libertad podía usarse para que el servidor FTP conectara con un servicio ajeno y le enviara datos elegidos por el cliente.

La operación parecía ideal para quien tenía una conexión lenta: encargar el traslado a dos almacenes y no llevar la caja primero a casa. FTP podía hacerlo. El usuario daba órdenes por un canal; el archivo viajaba por otro. El chiste dejó de hacer gracia cuando la orden incluía una dirección que no pertenecía al segundo almacén. El camión seguía siendo del servidor; el cliente había elegido la puerta a la que llamaría.

El RFC 959 de octubre de 1985 explicaba cómo organizar una transferencia entre dos servidores FTP. El cliente sostenía una conversación de control con cada uno. Un servidor aguardaba la conexión de datos y el otro la iniciaba. Mediante PORT, el cliente indicaba un puerto de datos alternativo, incluso en una máquina de un tercero. El texto mencionaba usos como obtener un archivo de otro servidor o enviarlo a una impresora remota. Evitar que el archivo diera la vuelta por el terminal del usuario era una ventaja real.

La misma separación creaba una asimetría. El usuario elegía el destino; el servidor abría la conexión. En el caso previsto, el destino era el otro servidor FTP que participaba en la transferencia. Si el servidor no restringía la dirección indicada, la siguiente conexión podía llegar a un servicio totalmente distinto. Visto desde ese servicio, el visitante era el servidor FTP. La persona que había escrito la dirección seguía lejos, detrás de la conversación de control.

Los cortafuegos hicieron visible otra parte del diseño. En RFC 1579, publicado en febrero de 1994, Steve Bellovin describió la incomodidad del FTP activo: el servidor iniciaba una conexión hacia un puerto del cliente, difícil de admitir con filtros de paquetes. Recomendó que los clientes utilizaran PASV, de modo que el servidor esperara y el cliente abriera la conexión saliente. También bosquejó APSV, pero indicó que no conocía ninguna implementación entonces. Cambiar quién llama a quién resolvía una fricción práctica, aunque no convertía todos los destinos posibles en destinos autorizados.

La llegada de nuevas direcciones complicó la libreta. El RFC 2428 de septiembre de 1998 añadió EPRT y EPSV para trabajar con IPv6 y traductores de direcciones. EPRT especificaba familia de red, dirección y puerto TCP. EPSV ALL comprometía la sesión a transferencias entre dos partes; si después hacía falta una transferencia entre tres, había que empezar otra sesión. Se modernizaba el formato del destino y se explicitaba la elección entre dos y tres participantes. La facultad de mandar al servidor a otra dirección seguía exigiendo criterio.

El RFC 2577 de mayo de 1999 describió esa facultad cuando caía en malas manos: el ataque de rebote. Un cliente podía enviar a un servidor FTP una orden PORT con la dirección y el puerto de un servicio en una tercera máquina, y luego pedirle que transmitiera datos. Si esos datos tenían forma de órdenes que el servicio entendía, el servidor FTP se convertía en mensajero involuntario. El ejemplo del RFC empleaba instrucciones SMTP guardadas en un archivo para llegar al servicio de correo de la tercera máquina. La conexión salía del servidor FTP, no del cliente que había preparado la carga.

La propuesta de defensa no cabía en un eslogan. RFC 2577 sugería negar conexiones de datos a puertos TCP inferiores a 1024 y contestar 504 a una petición PORT de ese tipo. Los servicios que escucharan en puertos superiores seguían expuestos. Los permisos de archivos podían impedir que alguien guardara una carga y luego la enviara. Desactivar PORT también era posible, con la pérdida del FTP entre servidores. PASV bastaba para la mayoría de las transferencias ordinarias, según los autores. Cada operador debía decidir cuánto valor tenía para él la ruta de tres participantes y cuánto control estaba dispuesto a imponerle.

FTP no había inventado la idea de un cliente que contrata un transporte. Había dado al cliente un bolígrafo para escribir la dirección en el camión de otro. Los documentos de 1985, 1994, 1998 y 1999 muestran el recorrido de esa decisión: primero comodidad, luego dirección del flujo, después nuevos formatos y por fin una pregunta de autoridad. El repartidor necesitaba un mapa; también necesitaba saber quién podía marcarle la próxima parada.