Autora: Daniela Barbera

El objetivo de este trabajo es comprender los posibles ataques que pueden ocurrir en un sitio FTP, relacionados con los problemas de seguridad intrínsecos que posee el protocolo, aquellos generados por la configuración inadecuada del servidor y de los límites en la red.

Cuando un usuario inicia una comunicación FTP, se crea una conexión de control desde un port arbitrario de la máquina cliente (>1023) al port 21 del servidor remoto FTP. Dicho canal utiliza el protocolo Telnet, para transmitir los comandos generados por el proceso cliente y las respuestas enviadas por el proceso servidor.

Una vez que el usuario es autenticado, el cliente FTP elige un puerto por donde esperará recibir los datos. Luego envía un comando PORT, para anunciar al servidor dicha elección, sólo después genera y transmite comandos sobre el canal de control relacionados a la operación con el archivo.

El servidor responde activamente abriendo una conexión TCP, desde su port 20 al especificado en los parametros del comando PORT y transfiere el archivo sobre este nuevo canal. Cabe aclarar que la comunicación de datos es full duplex.

 En la figura 1 se muestra una sección FTP. Observemos que las líneas que comienzan con números son las respuestas del servidor y que el contenido de /file.txt ingresa por el port 5097=19*256+233 en la direción IP 172.16.1.1

Es importante notar que el port de datos no necesita estar en el mismo host que genera la conexión de control FTP, debido que el comando PORT especifica no sólo el port, sino también la dirección IP destino. En la figura 2, se muestra la transferencia de archivos entre dos máquinas remotas. El usuario crea canales de control a los dos servidores y luego arregla la comunicación de datos entre ellos, dichos canales deben permanecer activos mientras se utilice el servicio FTP.

Figura 2

Cuando se inicia una comunicación FTP, se establece un canal de control desde la máquina cliente al servidor, por esta conexión le transmite comandos y el servidor le contesta. Los argumentos de los comandos USER y PASS se utilizan para realizar el control de acceso, es decir para identificar al usuario. En el protocolo FTP estándar definido en la RFC 959, el nombre de usuario y password se transfieren en texto claro, esto presenta el riesgo que un atacante pueda robarlos con sólo monitorear en la red. 

2.2 -Basados en el comando PORT

Conforme con el Protocolo FTP. El comando PORT, como ya se ha mencionado anteriormente, especifica una dirección IP y un port destino para establecer la comunicación de los datos. Este comportamiento implica que un atacante puede abrir una conexión a un port sobre una máquina elegida por él. En los siguientes ejemplos, se observan dos tipos de ataques utilizando el comando PORT en sitios protegidos por "firewall".

Ejemplo 1:

Un intruso puede evadir a un firewall en ciertas configuraciones de red. Asumamos que detrás del mismo se encuentra un servidor FTP anónimo. Utilizando la técnica de "port scan", un atacante puede determinar por ejemplo, que un servidor de web interno esta disponible sobre el port 8080, dicho port está normalmente bloquedo por el firewall.

Una vez conectado al servidor público FTP, el atacante inicia una conexión entre este servidor y un port arbitrario de una máquina no pública en aquel sitio ( Por ejemplo, el servidor web interno en el port 8080). De esta manera, el intruso establece comunicación con una máquina dentro del área protegida por el firewall.

En sitios que se encuentran protegidos con "firewall" de filtrado dinámico de paquetes, el ataque puede realizarse con un "applet" Java.

Un usuario en el sitio víctima con sólo invocar una página web, leer un email o noticias en un "browser " habilitado, puede bajarse un applet Java construido por el atacante. De manera imperceptible, dicho ejecutable comienza a correr en la máquina cliente del sitio protegido, pues el firewall trata a aquel código como enteramente confiable.

El applet envía un comando PORT al servidor remoto FTP del atacante, indicando que abra una conexión al port telnet de la máquina víctima. El firewall con filtrado dinámico de paquetes examina en cada paquete IP que ingresa desde la red externa, la dirección fuente, destino y otros parametros, decidiendo cuales se reenvían al interior. En este caso, nota que el comando PORT fue generado por una máquina local y permite la conexión que viene desde el servidor remoto al port telnet, suponiendo que una transferencia de archivo fue requerida por el cliente.

2.3 -Relacionados con la configuración

Si el directorio root FTP anómimo (~ftp) y sus subdirectorios son propiedad o están en el mismo grupo que la cuenta del usuario ftp y no se encuentran protegidos contra escritura, un intruso esta habilitado para adicionar archivos ( tal como .rhosts) o modificar los existentes. Este es un problema común de configuración.

Si los archivos /etc/passwd y /etc/group del sistema, se colocan como archivo de password y de grupo en el directorio ~ftp / etc, permitirá que intrusos obtengan copias de estos archivos.

Algunos sitios configuran sus servidores FTP anónimos para permitir áreas de escritura ( Por ejemplo, disponiendo de directorios "drop off" o de entrada para almacenar los archivo enviados a este sitio). Si estos archivos pueden ser leídos por los usuarios de la cuenta FTP anónimo, existirán abusos. Por ejemplo: Se han reportado casos donde se utilizaban los directorios "drop off" para distribuir versiones falsificadas de software o para traficar información sobre cuentas comprometidas y archivos de password.

Cuando en la configuración del servidor no está establecido un límite en el área de escritura, el sistema de archivos pueden ser llenados maliciosamente poniendo gran cantidad de archivos espurios, con el objetivo de causar la interrupción del servicio, el "crash" del sistema o el consumo del espacio de disco del mismo.

Un server FTP anónimo mal configurado o comprometido puede además de los abusos mencionados, permitir que se logren correr procesos bajo la UID del demonio FTP.

2.4 - Basados en antiguos "bug" del protocolo

El demonio ftpd es vulnerable a "crashing". Por ejemplo si desde una cuenta de usuario se ejecuta el comando cd .. /.. /.. /.. , el proceso aborta y UNIX hace un "dump", generando un archivo del sistema en el directorio del usuario que provoco el "crash". Si en el file core se encontraban los password, el atacante los tendrá en el archivo generado.

Desarrollando herramientas para analizar los registros de acceso al servidor, con los comandos "puts" y "gets" ( por ejemplo secciones de "STOR" y "RETR"). Algunos sitios han reportado tener cientos de conexiones en un corto lapso de tiempo que han sido identificadas como "puts" y "gets". Por ejemplo, para almacenar y retirar software pirata o sobre los archivos del sistema de un server anónimo.

Revisar regularmente los contenidos de los archivos que han ingresado en el área "drop off" de un server ftp anónimo, con el objeto de identificar abusos, luego proseguir de acuerdo a los procedimientos y política de la organización.

Reveer periódicamente la integridad de todos los archivos y directorios del sistema. Chequeando también los directorios ocultos ( Directorios con espacios, caracteres de control o especiales, etc.). Hay herramientas tales como Tripwire que ayudan a verificar la integridad. Se debe asegurar que no han ocurrido modificaciones no autorizadas en los archivos existentes o adiciones de nuevos archivos que impacten contra la seguridad, tales como .rhosts. Se han reportado abusos donde un "file" original es replicado con una versión de un caballo de Troya del mismo.

Asegurando que el servidor FTP se encuentre correctamente configurado. Existen muchos casos en que los administradores no perciben que su sistema esta siendo atacado, por desconocer los tipos de abusos y maneras de detectarlos. Ellos pueden creer que han configurado el servidor para prevenir ataques, cuando en realidad no lo han hecho.

4.1.1 - Configurando los directorios FTP anónimo.

Haciendo que el directorio root ftp y sus subdirectorios sea solo propiedad de root, separar del sistema de grupos y proteger para que sólo root tenga permiso de escritura, esto ayudará a mantener la seguridad en el servicio FTP anónimo.

Ejemplo:

Los archivos y librerías, utilizados en ~ftp /bin y ~ftp/etc y aquellos empleados por el demonio FTP, deben tener la misma protección que estos directorios. Es decir, no pueden estar ubicados en la cuenta ftp o pertenecer al mismo grupo y todo ellos deben estar protegidos contra escritura.

 4.1.2 - Utilizando archivos de password y grupo propio

El directorio ~ftp/etc debe tener un archivo de password y de grupo independiente de los archivos del sistema (/etc/passwd y /etc/group son propiedad de root). Se debe asegurar que ~ftp/etc/passwd no contiene los mismos nombres de cuentas que se encuentran en /etc/passwd. Este sólo tiene que específicar aquellas entradas que son relevantes para la jerarquía FTP o para mostrar los nombres del propietario y del grupo. Además, se puede lograr que el campo de password sea clareado. Por ejemplo utilizando el asterisco (*) para clarear dicho campo.

 4.1.3 - Modificando el demonio FTP

 Si se planea permitir a los usuarios almacenar archivos en el servidor FTP anónimo, se sugiere modificar la configuración del demonio, que controla el acceso al directorio "drop off". Este es el mejor camino para prevenir la utilización no deseada de áreas de escritura.

Algunas modificaciones sugeridas son:

1. Implementar una política donde los archivos bajados (dropped) no puedan ser accedidos hasta que el administrador del sistema examine el archivo y lo mueva un directorio público.
2. Limitar la cantidad de datos transferidos en una sección.
3. Limitar la cantidad total de datos transferidos basado en la disponibilidad de espacio en disco.
4. Generar registros para facilitar la detección temprana de abusos.

 Los códigos fuentes de los demonios FTP están disponibles a través del fabricante. Las fuentes de dominio público disponibles son:

wuarchive.wustl.edu ~ftp/packages/wuarchive-ftpd

gatekeeper.dec.com ~ftp/pub/DEC/gwtools/ftpd.tar.Z

4.1.4 - Usando directorios protegidos

Si se planea dar servicio "drop off" y no es posible modificar el demonio ftpd.

Proteger el nivel más elevado del directorio (~ftp/incoming), dando sólo permiso de ejecución a los usuarios anónimos (chmod 751 ~ftp/incoming). Esto permite a los usuarios cambiar de directorio (cd), pero los imposibilita ver el contenido de los mismos.

4.2 - Restringir las funciones del software del servidor FTP

La mejor solución a los problemas de seguridad, es asegurar que el software del servidor FTP no puede establecer conexiones a máquinas arbitrarias. Sin embargo, de acuerdo a los requerimientos del sitio se puede implementar, por ejemplo la supresión de los comandos PORT, es decir sólo se puede conectar a la máquina cliente que origino la comunicación de control.

4.3 - Configuración adecuada de la red

4.4 - Evitar el ataque con applet Java en redes protegidas con filtrado dinámico de paquetes.

Los sitios que poseen fuerte autenticación de los usuarios que intentan generar una conexión FTP hacia fuera del área protegida, no son susceptibles a estos ataques, ya que un applet no podrá autenticarse el mismo como un usuario.

4.5 - Extensiones de seguridad

Implementar un servicio FTP con las especificaciones definidas en la RFC 2228. Estas extensiones proveen fuerte autenticación, integridad y confiabilidad sobre ambos canales, de control y de datos. Introducen nuevos comandos , respuestas y codificación en la transferencia de datos. Los nuevos comandos son opcionales y estas especificaciones son compatibles con la RFC 959:

AUTH ( Authentication/security Mechanism),

ADAT ( Authentication/security Data),

PROT (Data Channel Protection Level)

PBSZ ( Protection Buffer Size)

CCC ( Clear Command Channel)

MIC ( Integrity Protected Command)

CONF ( Confidentiality Protected Command)

ENC ( Privacy Protected Command)

[2] "Anonymous FTP Configuration guidelines", disponible en:

[3] "Anonymous FTP Abuses", disponible electrónicamente en:

[4] "Problems with The FTP PORT Command", disponible en:

[5] RFC: 2228, FTP Security Extensions ( Octubre de 1997), disponible en:

[6] Martin, David M. ; Rajagopalan Bellcore, Sivaramakrishnan and Rubin, Aviel D., " Blocking Java Applets at the Firewall ". In IEEE, the Proceedings of the Symposium on Network and Distributed Systems Security, 1997. Disponible en :