Protocolo de transferencia de archivos

El Protocolo de transferencia de archivos (FTP) es un protocolo de comunicación estándar utilizado para la transferencia de archivos informáticos desde un servidor a un cliente en una red informática. FTP se basa en una arquitectura de modelo cliente-servidor que utiliza conexiones de datos y control separadas entre el cliente y el servidor. Los usuarios de FTP pueden autenticarse con un protocolo de inicio de sesión de texto simple, normalmente en forma de nombre de usuario y contraseña, pero pueden conectarse de forma anónima si el servidor está configurado para permitirlo. Para una transmisión segura que proteja el nombre de usuario y la contraseña, y cifre el contenido, el FTP a menudo se asegura con SSL/TLS (FTPS) o se reemplaza con el Protocolo de transferencia de archivos SSH (SFTP).

Las primeras aplicaciones de cliente FTP fueron programas de línea de comandos desarrollados antes de que los sistemas operativos tuvieran interfaces gráficas de usuario y aún se envían con la mayoría de los sistemas operativos Windows, Unix y Linux. Desde entonces, se han desarrollado muchos clientes FTP dedicados y utilidades de automatización para equipos de escritorio, servidores, dispositivos móviles y hardware, y FTP se ha incorporado a aplicaciones de productividad como editores HTML y administradores de archivos.

Un cliente FTP solía integrarse comúnmente en los navegadores web, donde los servidores de archivos se navegan con el prefijo URI "ftp://". A lo largo de 2021, los dos principales proveedores de navegadores web eliminaron esta capacidad. La compatibilidad con el protocolo FTP se deshabilitó por primera vez en Google Chrome 88 en enero de 2021, seguido de Firefox 88.0 en abril de 2021. En julio de 2021, Firefox 90 eliminó FTP por completo y Google hizo lo mismo en octubre de 2021, eliminando FTP por completo en Google Chrome 95.

Historial de servidores FTP

Abhay Bhushan escribió la especificación original para el Protocolo de transferencia de archivos y se publicó como RFC 114 el 16 de abril de 1971. Hasta 1980, FTP se ejecutó en NCP, el predecesor de TCP/IP. Posteriormente, el protocolo fue reemplazado por una versión TCP/IP, RFC 765 (junio de 1980) y RFC 959 (octubre de 1985), la especificación actual. Varios estándares propuestos modifican RFC 959, por ejemplo, RFC 1579 (febrero de 1994) habilita FTP compatible con firewall (modo pasivo), RFC 2228 (junio de 1997) propone extensiones de seguridad, RFC 2428 (septiembre de 1998) agrega soporte para IPv6 y define un nuevo tipo de modo pasivo.

Descripción general del protocolo

Comunicación y transferencia de datos

Ilustración de iniciar una conexión pasiva utilizando el puerto 21

FTP puede ejecutarse en modo activo o pasivo, lo que determina cómo se establece la conexión de datos. (Este sentido de "modo" es diferente del comando MODE en el protocolo FTP).

• En modo activo, el cliente comienza a escuchar las conexiones de datos entrantes desde el servidor en el puerto M. Envía el comando FTP PORT M para informar al servidor en qué puerto está escuchando. El servidor inicia entonces un canal de datos al cliente desde su puerto 20, el puerto de datos del servidor FTP.
• En situaciones en las que el cliente está detrás de un cortafuegos y no puede aceptar conexiones TCP entrantes, modo pasivo puede ser usado. En este modo, el cliente utiliza la conexión de control para enviar un comando PASV al servidor y luego recibe un servidor IP dirección y número de puerto servidor desde el servidor, que el cliente utiliza para abrir una conexión de datos desde un puerto cliente arbitrario al servidor IP dirección y número de puerto servidor recibido.

Ambos modos se actualizaron en septiembre de 1998 para admitir IPv6. En ese momento se introdujeron más cambios en el modo pasivo, actualizándolo a modo pasivo extendido.

El servidor responde a través de la conexión de control con códigos de estado de tres dígitos en ASCII con un mensaje de texto opcional. Por ejemplo, "200" (o "200 OK") significa que el último comando fue exitoso. Los números representan el código de la respuesta y el texto opcional representa una explicación o solicitud legible por humanos (por ejemplo, <Se necesita una cuenta para almacenar el archivo>). Una transferencia en curso de datos de archivo a través de la conexión de datos se puede cancelar mediante un mensaje de interrupción enviado a través de la conexión de control.

FTP necesita dos puertos (uno para enviar y otro para recibir) porque originalmente se diseñó para operar sobre el Protocolo de control de red (NCP), que era un protocolo simplex que utilizaba dos direcciones de puerto, estableciendo dos conexiones, para dos -vía de comunicaciones. Se reservó un puerto impar y uno par para cada aplicación o protocolo de la capa de aplicación. La estandarización de TCP y UDP redujo la necesidad del uso de dos puertos simplex para cada aplicación a un puerto dúplex, pero el protocolo FTP nunca se modificó para usar solo un puerto y continuó usando dos para compatibilidad con versiones anteriores.

NAT y cruce de cortafuegos

FTP normalmente transfiere datos haciendo que el servidor se vuelva a conectar al cliente, después de que el cliente envíe el comando PORT. Esto es problemático tanto para NAT como para firewalls, que no permiten conexiones desde Internet hacia hosts internos. Para los NAT, una complicación adicional es que la representación de las direcciones IP y el número de puerto en el comando PORT se refieren a la dirección IP y el puerto del host interno, en lugar de la dirección IP pública y el puerto del NAT.

Hay dos enfoques para resolver este problema. Una es que el cliente FTP y el servidor FTP usan el comando PASV, lo que hace que se establezca la conexión de datos desde el cliente FTP al servidor. Esto es ampliamente utilizado por los clientes FTP modernos. Otro enfoque es que NAT altere los valores del comando PORT, utilizando una puerta de enlace a nivel de aplicación para este propósito.

Tipos de datos

Al transferir datos a través de la red, se definen cuatro tipos de datos:

• ASCII (TYPE A): Usado para texto. Los datos se convierten, si es necesario, de la representación del personaje del host enviado a "ASCII de 8 bits" antes de la transmisión, y (de nuevo, si es necesario) a la representación del anfitrión receptor, incluyendo nuevas líneas. Como consecuencia, este modo es inapropiado para archivos que contienen datos distintos de ASCII.
• Imagen (TYPE I, comúnmente llamado modo binario): La máquina de envío envía cada byte de archivo, y el receptor almacena el bytestream como lo recibe. (Se ha recomendado apoyo de modo de imagen para todas las implementaciones de FTP).
• EBCDIC (TYPE E): Se utiliza para texto sencillo entre los anfitriones utilizando el conjunto de caracteres EBCDIC.
• Local (TYPE L n): Diseñado para soportar la transferencia de archivos entre máquinas que no utilizan bytes de 8 bits, por ejemplo sistemas de 36 bits como DEC PDP-10s. Por ejemplo, "TYPE L 9" se utilizaría para transferir datos en bytes de 9 bits, o "TYPE L 36" para transferir palabras de 36 bits. La mayoría de los clientes/servidores FTP contemporáneos solo soportan L 8, que es equivalente a I.
• Archivos de texto Unicode usando UTF-8 (TYPE U): definidos en un borrador de Internet vencido que nunca se convirtió en un RFC, aunque ha sido implementado por varios clientes/servidores FTP.

Tenga en cuenta que estos tipos de datos se denominan comúnmente "modos", aunque de forma ambigua esa palabra también se usa para referirse al modo de comunicación activo frente a pasivo (ver arriba) y los modos establecidos por el protocolo FTP MODE comando (ver más abajo).

Para los archivos de texto (TIPO A y TIPO E), se proporcionan tres opciones de control de formato diferentes para controlar cómo se imprimiría el archivo:

• Non-print (TYPE A N y TYPE E N) – el archivo no contiene ningún personaje de control de carruaje destinado a una impresora
• Telnet (TYPE A T y TYPE E T) – el archivo contiene Telnet (o en otras palabras, ASCII C0) caracteres de control de carros (CR, LF, etc)
• ASA (TYPE A A y TYPE E A) – el archivo contiene caracteres de control de carros ASA

Estos formatos eran principalmente relevantes para las impresoras de línea; la mayoría de los clientes/servidores FTP contemporáneos solo admiten el control de formato predeterminado de N.

Estructuras de archivos

La organización de archivos se especifica mediante el comando STRU. Las siguientes estructuras de archivos se definen en la sección 3.1.1 de RFC959:

• F o estructura FILE (orientada a corriente). Los archivos son vistos como una secuencia arbitraria de bytes, caracteres o palabras. Esta es la estructura habitual de archivos en sistemas Unix y otros sistemas como CP/M, MS-DOS y Microsoft Windows. (Sección 3.1.1.1)
• R o estructura RECORD (record-oriented). Los archivos se consideran divididos en registros, que pueden ser de longitud fija o variable. Esta organización de archivos es común en sistemas mainframe y midrange, como MVS, VM/CMS, OS/400 y VMS, que soportan sistemas de archivos orientados a registros.
• P o estructura PAGE (orientada a página). Los archivos se dividen en páginas, que pueden contener datos o metadatos; cada página también puede tener un encabezado dando varios atributos. Esta estructura de archivos fue diseñada específicamente para sistemas TENEX, y generalmente no es compatible con otras plataformas. La sección 4.1.2.3 de RFC1123 recomienda que esta estructura no se aplique.

La mayoría de los clientes y servidores FTP contemporáneos solo admiten STRU F. STRU R todavía se usa en aplicaciones de transferencia de archivos de mainframe y minicomputadora.

Modos de transferencia de datos

La transferencia de datos se puede realizar en cualquiera de los tres modos:

• Modo de corriente (MODE S): Los datos se envían como un flujo continuo, lo que permite que FTP haga cualquier procesamiento. Más bien, todo el procesamiento se deja hasta TCP. No se necesita ningún indicador final de archivo, a menos que los datos se dividan en registros.
• Modo de bloque (MODE B): Diseñado principalmente para transferir archivos orientados a registros (STRU R), aunque también se puede utilizar para transferir archivos de texto orientados a secuencias (STRU F). FTP pone cada registro (o línea) de datos en varios bloques (cabeza de bloqueo, cuenta de byte y campo de datos) y luego lo pasa a TCP.
• Modo comprimido (MODE C): Extende el MODE B con compresión de datos mediante codificación de longitud de ejecución.

La mayoría de los clientes y servidores FTP contemporáneos no implementan el MODO B o el MODO C; Los clientes y servidores FTP para sistemas operativos de mainframe y minicomputadoras son la excepción.

Algún software de FTP también implementa un modo comprimido basado en DEFLATE, a veces llamado "Modo Z" después del comando que lo habilita. Este modo se describió en un Borrador de Internet, pero no estandarizado.

GridFTP define modos adicionales, MODO E y MODO X, como extensiones del MODO B.

Comandos adicionales

Las implementaciones más recientes de FTP admiten el comando Modify Fact: Modification Time (MFMT), que permite a un cliente ajustar ese atributo de archivo de forma remota, lo que permite la preservación de ese atributo al cargar archivos.

Para recuperar la marca de tiempo de un archivo remoto, existe el comando MDTM. Algunos servidores (y clientes) admiten una sintaxis no estándar del comando MDTM con dos argumentos, que funciona de la misma manera que MFMT

Iniciar sesión

El inicio de sesión mediante FTP utiliza un esquema normal de nombre de usuario y contraseña para otorgar acceso. El nombre de usuario se envía al servidor con el comando USER y la contraseña se envía con el comando PASS. Esta secuencia no está cifrada 'en el cable', por lo que puede ser vulnerable a un ataque de rastreo de red. Si la información proporcionada por el cliente es aceptada por el servidor, el servidor enviará un saludo al cliente y comenzará la sesión. Si el servidor lo admite, los usuarios pueden iniciar sesión sin proporcionar credenciales de inicio de sesión, pero el mismo servidor puede autorizar solo un acceso limitado para dichas sesiones.

FTP anónima

Un host que proporciona un servicio FTP puede proporcionar acceso FTP anónimo. Los usuarios suelen iniciar sesión en el servicio con un código 'anónimo' (en minúsculas y con distinción entre mayúsculas y minúsculas en algunos servidores FTP) cuando se le solicite el nombre de usuario. Aunque normalmente se pide a los usuarios que envíen su dirección de correo electrónico en lugar de una contraseña, en realidad no se realiza ninguna verificación de los datos proporcionados. Muchos hosts FTP cuyo propósito es proporcionar actualizaciones de software permitirán inicios de sesión anónimos.

Diferencias con HTTP

HTTP esencialmente corrige los errores en FTP que hacían que su uso fuera inconveniente para muchas transferencias efímeras pequeñas, como son típicas en las páginas web.

FTP tiene una conexión de control con estado que mantiene un directorio de trabajo actual y otras banderas, y cada transferencia requiere una conexión secundaria a través de la cual se transfieren los datos. En "pasivo" esta conexión secundaria es del cliente al servidor, mientras que en el modo predeterminado "activo" modo esta conexión es de servidor a cliente. Esta aparente inversión de roles cuando está en modo activo y los números de puerto aleatorios para todas las transferencias es la razón por la que los cortafuegos y las puertas de enlace NAT tienen tantas dificultades con FTP. HTTP no tiene estado y multiplexa el control y los datos a través de una única conexión del cliente al servidor en números de puerto bien conocidos, que pasa trivialmente a través de puertas de enlace NAT y es fácil de administrar para los firewalls.

La configuración de una conexión de control FTP es bastante lenta debido a los retrasos de ida y vuelta del envío de todos los comandos necesarios y la espera de respuestas, por lo que es habitual abrir una conexión de control y mantenerla abierta para múltiples transferencias de archivos en lugar de abandone y restablezca la sesión de nuevo cada vez. Por el contrario, HTTP originalmente cortó la conexión después de cada transferencia porque hacerlo era muy barato. Si bien HTTP obtuvo posteriormente la capacidad de reutilizar la conexión TCP para múltiples transferencias, el modelo conceptual sigue siendo de solicitudes independientes en lugar de una sesión.

Cuando FTP se transfiere a través de la conexión de datos, la conexión de control está inactiva. Si la transferencia tarda demasiado, el cortafuegos o NAT pueden decidir que la conexión de control está muerta y dejar de rastrearla, interrumpiendo efectivamente la conexión y confundiendo la descarga. La única conexión HTTP solo está inactiva entre solicitudes y es normal y esperado que dichas conexiones se interrumpan después de un tiempo de espera.

Soporte de software

Navegador web

La mayoría de los navegadores web comunes pueden recuperar archivos alojados en servidores FTP, aunque es posible que no admitan extensiones de protocolo como FTPS. Cuando se proporciona una URL de FTP, en lugar de HTTP, los contenidos accesibles en el servidor remoto se presentan de una manera similar a la que se utiliza para otros contenidos web. FireFTP es una extensión de navegador diseñada como un cliente FTP con todas las funciones, se podía ejecutar dentro de Firefox en el pasado, pero ahora se recomienda trabajar con Waterfox.

Google Chrome eliminó por completo la compatibilidad con FTP en Chrome 88. A partir de 2019, Mozilla estaba discutiendo propuestas, incluida la eliminación de la compatibilidad con implementaciones antiguas de FTP que ya no se usan para simplificar su código. En abril de 2021, Mozilla lanzó Firefox 88.0 que deshabilitó la compatibilidad con FTP de forma predeterminada. En julio de 2021, Firefox 90 eliminó por completo la compatibilidad con FTP.

Sintaxis

La sintaxis de la URL de FTP se describe en RFC 1738, con la siguiente forma: ftp://[usuario[:contraseña]@]host[:puerto]/ruta-url (las partes entre paréntesis son opcionales).

Por ejemplo, la URL ftp://public.ftp-servers.example.com/mydirectory/myfile.txt representa el archivo myfile.txt del directorio mydirectory en el servidor public.ftp-servers.example.com como recurso FTP. La URL ftp://user001:secretpassword@private.ftp-servers.example.com/mydirectory/myfile.txt agrega una especificación del nombre de usuario y la contraseña que se deben usar para acceder a este recurso.

Puede encontrar más detalles sobre cómo especificar un nombre de usuario y una contraseña en los navegadores' documentación (por ejemplo, Firefox e Internet Explorer). De manera predeterminada, la mayoría de los navegadores web usan el modo pasivo (PASV), que atraviesa más fácilmente los firewalls de los usuarios finales.

Ha existido alguna variación en la forma en que los diferentes navegadores tratan la resolución de rutas en los casos en que hay un directorio de inicio no raíz para un usuario.

Administrador de descargas

Los administradores de descargas más comunes pueden recibir archivos alojados en servidores FTP, mientras que algunos de ellos también brindan la interfaz para recuperar los archivos alojados en servidores FTP. DownloadStudio permite no solo descargar un archivo del servidor FTP, sino también ver la lista de archivos en un servidor FTP.

Otro

LibreOffice admite la apertura de archivos desde servidores FTP, pero a partir de la versión 7.4, esta característica está etiquetada como obsoleta y los desarrolladores pretenden eliminarla en una versión futura.

Seguridad

FTP no fue diseñado para ser un protocolo seguro y tiene muchas debilidades de seguridad. En mayo de 1999, los autores de RFC 2577 enumeraron una vulnerabilidad a los siguientes problemas:

• Ataque de la fuerza bruta
• FTP bounce attack
• Captura de paquete
• El robo de puertos (escuchando el próximo puerto abierto y usurpando una conexión legítima)
• Ataque de espontáneo
• Lista de nombres de usuario
• DoS o DDoS

FTP no cifra su tráfico; todas las transmisiones son en texto claro, y los nombres de usuario, las contraseñas, los comandos y los datos pueden ser leídos por cualquier persona capaz de realizar la captura de paquetes (olfateo) en la red. Este problema es común a muchas de las especificaciones del Protocolo de Internet (como SMTP, Telnet, POP e IMAP) que se diseñaron antes de la creación de mecanismos de encriptación como TLS o SSL.

Las soluciones comunes a este problema incluyen:

1. Usando las versiones seguras de los protocolos inseguros, por ejemplo, FTPS en lugar de FTP y TelnetS en lugar de Telnet.
2. Usando un protocolo diferente y más seguro que pueda manejar el trabajo, por ejemplo. Protocolo de Transferencia de Archivos SSH o Protocolo de Copiado Seguro.
3. Usando un túnel seguro como Secure Shell (SSH) o red privada virtual (VPN).

FTP sobre SSH

FTP sobre SSH es la práctica de tunelizar una sesión FTP normal a través de una conexión Secure Shell. Debido a que FTP usa múltiples conexiones TCP (algo inusual para un protocolo TCP/IP que todavía está en uso), es particularmente difícil hacer un túnel a través de SSH. Con muchos clientes SSH, intentar configurar un túnel para el canal de control (la conexión inicial de cliente a servidor en el puerto 21) protegerá solo ese canal; cuando se transfieren datos, el software FTP en cualquiera de los extremos establece nuevas conexiones TCP (canales de datos) y, por lo tanto, no tienen protección de confidencialidad o integridad.

De lo contrario, es necesario que el software del cliente SSH tenga conocimientos específicos del protocolo FTP, para monitorear y reescribir los mensajes del canal de control FTP y abrir de forma autónoma nuevos reenvíos de paquetes para los canales de datos FTP. Los paquetes de software que admiten este modo incluyen:

• Tectia ConnectSecure (Win/Linux/Unix) de la suite de software de SSH Communications Security

Derivados

FTPS

El FTPS explícito es una extensión del estándar FTP que permite a los clientes solicitar que se cifren las sesiones FTP. Esto se hace enviando el "AUTH TLS" dominio. El servidor tiene la opción de permitir o denegar conexiones que no soliciten TLS. Esta extensión de protocolo se define en RFC 4217. El FTPS implícito es un estándar obsoleto para FTP que requería el uso de una conexión SSL o TLS. Se especificó que usara puertos diferentes al FTP simple.

Protocolo de transferencia de archivos SSH

El protocolo de transferencia de archivos SSH (cronológicamente el segundo de los dos protocolos abreviados como SFTP) transfiere archivos y tiene un conjunto de comandos similar para los usuarios, pero usa el protocolo Secure Shell (SSH) para transferir archivos. A diferencia de FTP, cifra tanto los comandos como los datos, evitando que las contraseñas y la información confidencial se transmitan abiertamente a través de la red. No puede interoperar con el software FTP, aunque algunos software de cliente FTP también ofrecen soporte para el protocolo de transferencia de archivos SSH.

Protocolo trivial de transferencia de archivos

El protocolo trivial de transferencia de archivos (TFTP) es un FTP simple y de pasos fijos que permite a un cliente obtener un archivo o colocarlo en un host remoto. Uno de sus principales usos es en las primeras etapas de arranque desde una red de área local, porque TFTP es muy sencillo de implementar. TFTP carece de seguridad y de la mayoría de las funciones avanzadas que ofrecen los protocolos de transferencia de archivos más robustos, como el Protocolo de transferencia de archivos. TFTP se estandarizó por primera vez en 1981 y la especificación actual del protocolo se puede encontrar en RFC 1350.

Protocolo simple de transferencia de archivos

El Protocolo simple de transferencia de archivos (el primer protocolo abreviado como SFTP), según lo define RFC 913, se propuso como un protocolo de transferencia de archivos (no seguro) con un nivel de complejidad intermedio entre TFTP y FTP. Nunca fue ampliamente aceptado en Internet, y ahora el IETF le asigna el estado Histórico. Se ejecuta a través del puerto 115 y, a menudo, recibe las iniciales de SFTP. Tiene un conjunto de comandos de 11 comandos y admite tres tipos de transmisión de datos: ASCII, binario y continuo. Para sistemas con un tamaño de palabra que es un múltiplo de 8 bits, la implementación de binario y continuo es la misma. El protocolo también admite el inicio de sesión con ID de usuario y contraseña, carpetas jerárquicas y administración de archivos (incluidos renombrar, eliminar, cargar, descargar, descargar con sobrescribir y descargar con agregar).

Comandos FTP

Códigos de respuesta FTP

A continuación se muestra un resumen de los códigos de respuesta FTP que puede devolver un servidor FTP. Estos códigos han sido estandarizados en RFC 959 por el IETF. El código de respuesta es un valor de tres dígitos. El primer dígito se usa para indicar uno de los tres resultados posibles: éxito, fracaso o para indicar un error o una respuesta incompleta:

• 2yz – Respuesta al éxito
• 4yz o 5yz – Respuesta de fracaso
• 1yz o 3yz – Error o respuesta incompleta

El segundo dígito define el tipo de error:

• x0z – Sintaxis. Estas respuestas se refieren a errores de sintaxis.
• x1z – Información. Respuestas a solicitudes de información.
• x2z – Conexiones. Respuestas referidas a las conexiones de control y datos.
• x3z – Autenticación y contabilidad. Respuestas para el proceso de inicio de sesión y procedimientos de contabilidad.
• x4z – No definido.
• x5z – Sistema de archivos. Estas respuestas transmiten códigos de estado del sistema de archivos servidor.

El tercer dígito del código de respuesta se usa para proporcionar detalles adicionales para cada una de las categorías definidas por el segundo dígito.