Securizar FTP windows, linux y mac

Tras los estudios que llevamos ya hechos sobre servidores FTP y su funcionamiento llega el momento de verlos desde el punto de vista de la seguridad informática. Todas las publicaciones anteriores con conceptos previos sobre servidores FTP eran necesarias para poder comprender desde el punto de vista hacker cómo se ha de securizar un servidor FTP correctamente para disminuir al máximo las posibilidades de ser hackeados.

Evitar ataques MITM (Man In The Middle) FTP

Los ataques de tipo MITM (Man In The Middle) en español, «hombre en medio», son un tipo de ataque que buscan poder interceptar el tráfico que tenemos entre nosotros y nuestro servidor, normalmente para poder conseguir las claves de acceso. Se pueden realizar de 2 modos:

  1. Man In The Middle interceptando la conexión. En esta situación el atacante ha conseguido hacer que los paquetes viajen por un router o equipo que el controla. Rocordad, por esquemas anteriores, en los que mostrábamos cómo al conectarnos a internet toda nuestra comunicación pasaba por el router, si el atacante puede acceder ahí y conectar un sniffer (lo cual veremos más adelante) será capaz de ver el tráfico entre nosotros y nuestro servidor, por consiguiente podrá ver nuestras claves y todo lo que hacemos.
     
  2. Man In The Middle alterando el host. Aquí la situación es diferente, el atacante nos hará creer que nos estamos conectando a nuestro servidor cuando en realidad nos estamos conectando a un host que el controla. Esto se puede hacer con diversas técnias, una de las mas comunes es DNS Spoofing (la veremos más adelante). En esta situación el ataque puede deribar a su vez en otros 2 tipos de ataque. En el primero y mas sencillo, cuando nos intentemos autentificar (escribiendo nuestro usuario y clave) lo que estaremos haciendo será dárselas al atacante, ya que estamos intentando autentificarnos en SU servidor y no en el nuestro. En el segundo tipo de ataque y mas complejo el atacante redirigirá el tráfico al servidor original de modo que será capaz de ver todo nuestro tráfico tal y como lo vería si hubiera hecho un MiTM interceptado la conexión.

Ante estas amenzas tenemos un grupo de herramientas y precauciones a tomar que nos ayudarán a paliar en gran medida ambos ataques. La primera de ellas es utilizar de forma obligatoria FTPS, el protocolo seguro de FTP. De esta forma todo nuestro tráfico (usuarios, claves y comandos) viajarán de forma cifrada por la red. Con esta primera medida evitamos el primer tipo de MiTM, ya que si nuestro tráfico pasa por un router o equipo el cual ha sido sometido por un hacker éste verá el tráfico cifrado y no será capaz de ver la información sensible que estamos transmitiendo.

Alquien podría pensar que con esto ya es suficiente, pues al estar cifrado el tráfico queda protegido frente a terceros. Pero la realidad es que esto no es así y no porque el hacker pueda romper el cifrado (que también podría ser, aunque no es lo mas común) sino porque el hacker ha podido engañarnos y hacernos creer que nos estamos conectando a nuestro servidor cuando en realidad nos estamos conectando a uno suyo (MiTM alterando el host). Y en ese escenario nuestro tráfico estaría cifrado, si, pero sería un cifrando entre nosotros y SU servidor. Así que al llegar el tráfico a su servidor el hacker lo vería sin problema alguno. ¿Cómo evitamos esto? Aquí la segunda medida que WINSCP ya toma por nosotros por defecto, los certificados de seguridad.

Los certificados de seguridad y su fución para evitar MITM

La utilización de certificados se seguridad para evitar el segundo tipo de ataques MITM es crucial. La función de estos certificados es asegurar que realmente vamos a conectados a quien realmente queremos conectarnos y no a otra entidad. En el proceso de autentificación de usuarios entre un servidor y un cliente, lo primero es intercambiar sus firmas y llaves públicas, con la llave pública que nos da el servidor nsotros ciframos el tráfico de tal forma que solo el servidor puede descifrarlo con su llave privada, por otro lado nosotros damos al servidor nuestra llave pública para que el cifre los mensajes con nuestra llave pública y solo nosotros seamos capaces de descifrarlo con nuestra llave privada.  Mas adelante veremos mas a fondo en criptografía asimétrica cómo trabajar en profundidad con los certificados de seguridad. De momento quedarmos con el concepto de que en un sistema de criptografía asimétrica, cada parte tiene 2 llaves una pública y otra privada, la pública es la que se difunde para que todo el mundo la tenga, y todo lo que se cifre con la llave pública sólamente será descifrable por la llave privada.

La primera vez que nosotros nos conectamos a un servidor FTP con el modo seguro activado FTPS, WinSCP va a recibir la llave pública del servidor y nos la va a mostrar. Nos va a decir que NO LA CONOCE, y nos va a preguntar si realmente estamos seguros de que es el servidor al que queremos conectar. Así que la primera vez que os váis a conectar al servidor debéis estar seguros de que lo hacéis en unas condiciones de seguridad aceptables, o pedir al administrador que os de por correo electrónico la llave pública del servidor y no memorizarla en WinSCP hasta que verifiquéis que la llave que da el servidor FTP es la misma que os ha dado el administrador. En el caso de que seamos nosotros el administrado del servidor vamos a aprender a configurar nuestro servidor FTP (Filezilla) para trabajar en el modo seguro FTPS.

Configuración de certificados de seguridad SSL/TLS en Filezilla

En este apartado vamos a aprender a configurar nuestro servidor Filezilla para que sea capaz de trabajar con conexiones seguras SSL y así evitar en gran medida los ataques de tipo MiTM. El primera paso es pulsar sobre el icono de configuración, diriginos al apartado de SSL/TLS Settings, habilitar FTPS y generar los certificados:
Configuración habilitar SSL/TLS Filezilla server

Cuando pulsamos sobre el botón «Generate new certificate…» se nos va a abrir un diálogo en el que vamos a poder personalizar nuestro certificado. El primero punto es la robustez de la clave que podrá ser desde 1024 bits hasta 4096. Siendo 1024 menos robusta y 4096 la más fuerte. La ventaja de escoger un cifrado mas fuerte es que las posiblidadesde de crackeo baján de forma exponencial, como desventaja nuestro PC tendrá que realizar mas cálculos para cifrar y descifrar el tráfico, así que haremos que tanto el cliente como el servidor tengan que trabajar más. Nosotros hemos elegido 4096. Los siguientes datos hacen referencia a lo que querías que el cliente véa cuando le entreguéis el certificado:
Crear certificado seguridad 4096 bits SSL/TLS Filezilla

Al pulsar el boton «Generate certificate» WinSCP tardará un poco en generarlo, ya que ha de generar una clave aleatória, tarda unos segundos en los que puede parecer que se ha quedado pillado, pero finalmente os mostrará un mensaje en el que os confirmará que se ha generado correctamente. Ya tenemos generado nuestro certificado de seguridad y estamos en posición de avanzar al siguiente paso.

Configurar WinSCP para trabajar con SSL/TLS

Ahora que tenemos un servidor FTP securizado, tenemos que configurar nuestro cliente FTP WinSCP para que sea capaz de trabajar en el modo seguro de dicho servidor. Para ello, abrimos WinSCP, y editamos (o creamos si no la guardásteis) la sesión que teníamos de haber trabajado previamente. Cambiamos del puerto 21 al puerto 990 (que es el de SSL) y por defecto WinSCP nos dirá que ese puerto habilita por defecto la encriptación SSL/TLS que buscamos:
Configurar sesión SSL/TLS WinSCP

Guardamos nuestra sesión y pulsamos sobre conectar (Login). Entonces veremos cómo WinSCP nos muestra el certificado que hemos creado unos pasos antes en Filezilla:
Validación certificado seguridad SSL/TLS WinSCP

WinSCP nos muestra todos los datos de nuestro certificado y nos pregunta si realmente queremos guardarlo. Este punto es crítico. Solo debemos hacerlo si estamos totalmente seguros de que el certificado pertenece al servidor que queremos conectarnos, podríamos para ello copiar la clave (con el botón copy Key) y compararla con la que nos ha dado el administrador por correo. Estando seguros de esto, pulsamos sobre «Yes» para indicar que el certificado es correcto y que queremos conectarnos. WinSCP lo guardará y en sucesivas conexiones comprobará de forma automática que siempre que nos queramos conectar a este servidor éste nos entregue siempre el mismo certificado, ya que el certificado es algo que no cambia. Si cambia es que no nos estamos conectando al servidor que creemos estar conectándonos (o que el administrador ha cambiado el certificado, en cuyo caso debería avisarnos). 

Desde el vamos a ver qué ocurre si generamos otro certificado y pedimos a WinSCP que se conecte; WinSCP se va a dar cuenta de que el certificado no concuerda con el que tiene guardado y en consecuencia mostrará lo siguiente:
Certificado desconocido WinSCP, FTP TLS/SSL
Nos adevertirá de nuevo que no conoce el certificado, y no nos dejará conectar hasta que o bien aceptemos el nuevo certificado como váido o bien solucionemos los problemas por los cuales no nos estamos conectando al servidor que queríamos conectarnos realmente.

Por norma general, una vez que hemos guardado un certificado de seguridad en nuestra biblioteca de certificados de WinSCP no debemos aceptar un nuevo certificado de un servidor que ya teníamos almacenado, si esto ocurre debemos contactar con el administrador del servidor y verificar que ha sido el quien por algún motivo se ha visto obligado a cambiar el certificado. Los motivos por los cuales un administrador de servidores puede cambiar un certificado son varios; desde haber perdido sus certificados hasta que el servidor haya sido hackeado y el administrador considere que le han podido robar sus certificados, con lo cual debe generar otros para asegurar la integridad del sistema.

Continua leyendo

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Newsletter Signup

Suscríbete a nuestra lista si te interesa recibir turcos exclusivos sobre hacking y seguridad informática