Peticiones DNS a la fuga (segunda parte)

FUGA DE INFORMACIÓN POR DNS

Más o menos ya hemos recordado como funcionan las peticiones DNS y como funciona un servicio VPN. Pero, a raíz de esto, nos surgen ciertas dudas. ¿Siempre vamos a estar anónimos?. Es decir, ¿cómo sabemos que nuestras consultas DNS se envían a través de nuestro tunel VPN?. Se pueden dar varios casos por los que se están filtrando las peticiones DNS:

  • Mala configuración: las peticiones DNS no se están enrutando a través de la interfaz tun0 creada por la conexión VPN sino que se están realizando a través de nuestra interfaz wlan0 (o la que estemos usandola cual utiliza los DNS configurados en nuestro equipo, o en su defecto, los establecidos en el router, que suelen ser los del ISP.
  • Plugins y WebRTC: uno de los plugins más utilizados hasta hace poco es el de Flash. Este plugin es inseguro, aparte de muchas otras vulnerabildiades, por que realiza peticiones fuera del contexto del navegador utilizando los DNS configurados en el sistema. WebRTC es un API implementado en los navegadores para el desarrollo de aplicaciones relacionadas con llamadas y videollamadas que hace petciones a servidores STUN, que devuelven las direcciones IP utilizadas.
  • VPN caido: otro ejemplo de fuga de peticiones DNS sería si se cae nuestra conexión con la VPN, en la que el sistema intentaría realizar las peticiones a través de la interfaz de red wlan0 (o la utilizada) que utilizará como hemos visto anteriormente, los DNS configurados en el sistema, o en su defecto, los establecidos en el router, que suelen ser los del ISP.

A continuación vamos a utilizar el mismo ejemplo que el anterior pero en este se produce una fuga de peticiones DNS a los servidores DNS de nuestro ISP:

  1. DNS Local: el  navegador pregunta a la caché DNS local por la dirección ip asociada a nuestra VPN conectar.
  2. Peticiones 1 y 2: como la caché de DNS local de nuestro equipo no ha resuelto el nombre de dominio de la VPN en una dirección IP, se deriva la consulta al servidor DNS de nuestro ISP (o del DNS que tengamos configurado).
  3. Respuestas 1 y 2: el servidor DNS del ISP tiene cacheada la dirección IP asociada al dominio del servicio VPN y la devuelve.
  4. Peticiones 3 y 4: se envía la petición de conexión a nuestro servicio VPN. Una vez conectados es como si nuestro equipo se encontrase directamente en esta red. Se crea una nueva interfaz (que veremos más adelante) y se importan las direcciones IP de los servidores DNS utilizados por la VPN. Las peticiones realizadas a partir de aquí se encuentran cifradas. Abrimos un navegador e introducimos la dirección IP de www.amazon.es .
  5. Petición 5: aquí es donde nos encontramos el problema de fuga de peticiones DNS. Puede ser que en este punto el servicio VPN no nos haya proporcionado las direcciones de los servidores DNS que utiliza o que el propio servicio VPN se haya caído, por lo que, como se muestra en el gráfico, se utilizarán directamente las direcciones IP establecidas en el fichero /etc/resolv.conf o en su defecto en el router, que serán las del ISP.
  6. Petición 6: el servidor DNS del ISP recibe la petición y al no poder resolverla, la deriva al servidor ROOT DNS.
  7. Respuesta 3: el servidor ROOT DNS devuelve la dirección IP del servidor TLD DNS que puede resolver el dominio .es .
  8. Petición 7: el servidor DNS del ISP deriva la petición al servidor TLD DNS.
  9. Respuesta 4: el servidor TLD DNS devuelve la dirección del IP del servidor DNS que puede resolver el dominio amazon.es .
  10. Petición 8: el servidor DNS del ISP deriva la petición al servidor DNS que puede resolver el nombre de dominio www.amazon.es .
  11. Respuestas 5 y 6: el servidor DNS devuelve a nuestro navegador la dirección IP del dominio www.amazon.es que es 178.236.6.247 .
  12. Petición 9: el navegador envía una petición de consulta a la dirección IP de www.amazon.es que es 178.236.6.247 .
  13. Respuestas 7, 8 y 9: el servidor con dirección IP 178.236.6.247 devuelve el contenido de la página solicitada al navegador de nuestro equipo.

A pesar de haber utilizado casi todos los medios para mantenernos anónimos, un simple fallo de configuración provoca que se filtren las peticiones DNS.

COMPROBANDO FUGA PETICIONES DNS CON TCPDUMP

Tcpdump es una herramienta de red que nos permite escanear tráfico de red para poder analizarlo. En este caso escanearemos las peticiones DNS y comprobaremos como pasan de una interfaz a otra en función de si usamos la VPN o no. Para ello pondremos tcpdump en escucha en la interfaz wlan0 y tun0 a través del puerto 53 (puerto en el que se realizan las peticiones DNS por defecto). Se puede observar que durante el proceso de conexión con el servicio VPN, los datos se envían a través de la interfaz wlan0 (imagen izquierda) hasta que, una vez hemos establecido la conexión, los datos comienzan a enviarse automáticamente por la nueva interfaz tun0 (imagen derecha) :

Ahora vamos a proceder a realizar una petición a una página de Internet y durante la misma, provocaremos el cierre de la conexión VPN para ver que es lo que sucedería. Como seguimos conectados a la VPN, los datos se seguirán enviando a través de la interfaz tun0 (imagen derecha) pero al provocar la detención del servicio VPN, se observa como los datos, automáticamente, se siguen enviando pero a través de la interfaz wlan0 utilizando los servidores DNS configurados en el fichero /etc/resolv.conf que serán los del ISP:

De esta forma, el ISP tendrá constancia de los recursos que estamos solicitando.

SERVICIOS DE VERIFICACIÓN DE DNS LEAK

Para la verificación de la fuga de peticiones DNS disponemos de varios servicios en Internet de los cuales utilizaremos ipleak.net . Este servicio nos muestra toda la información referente a la dirección IP que utilizamos, los DNS que tenemos configurados, detección de WebRTC, información de plugins, etc… . Un ejemplo es el que se muestra en la siguiente imagen en la que no se ha utilizado el servicio VPN:

Se muestra la dirección IP pública que estamos utilizando, la dirección IP interna de red que estamos utilizando, que es filtrada por el API WebRTC, y los servidores DNS utilizados por nuestro ISP. Si realizamos la misma prueba pero haciendo uso del servicio VPN, el resultado es diferente:

En este caso la información mostrada difiere de la imagen anterior. Ahora, tanto la dirección IP utilizada como los servidores DNS son las utilizadas por el servicio VPN y no por nuestro ISP. Si entre las direcciones IP listadas encontramos alguna de las direcciones IP de los servidores DNS de nuestro ISP, se estarían produciendo una fuga de peticiones DNS y no es lo que queremos.

QUÉ ES WEBRTC Y COMO DESHABILITARLO

WebRTC es un API implementado en los navegadores y aplicaciones móviles que permite el desarrollo de aplicaciones para poder realizar llamadas, videollamadas o compartir ficheros sin hacer uso de plugins de terceros. Desafortunadamente, esta técnica también permite que las páginas envíen peticiones a los llamados servidores STUN (servicios VoIP), que devolverán las direcciones IP locales y públicas. Para poder deshabilitarlo vamos a seguir los siguientes pasos (el siguiente ejemplo lo vamos a llevar a cabo sobre firefox) :

  • Entrar en la configuración: en la barra de introducción de direcciones url escribiremos about:config . 
  • Filtrar resultados: aparecerán numerosas opciones del navegador en las que tendremos que filtrar por la que estamos buscando, por lo que introduciremos en el buscador el valor media.peerconection.enabled :
  • Cambiar el valor: haremos doble click en el valor true para que sea false y cerramos la pestaña

 

OTRAS RECOMENDACIONES

Otras recomendaciones que tenemos que tener en cuenta son las siguientes:

CAMBIAR LOS DNS

Como hemos visto en todos los ejemplos, los servidores DNS utilizados siempre suelen ser los establecidos por el ISP. Para evitar esto, es recomendable cambiarlos y establecer direcciones IP de servidores DNS públicos. Los más utilizados son los siguientes :

  • Google DNS: 8.8.8.8 y 8.8.4.4 .
  • OpenDNS: 208.67.220.220 y 208.67.222.222 .
  • Comodo Secure DNS: 8.26.56.26 y 8.20.247.20 .

ASIGNAR UNA IP ESTÁTICA

Al utilizar un servicio VPN se asigna, a través de DHCP, una dirección IP a nuestra interfaz tun0 . Debido a esto, todas las peticiones DNS que realicemos deberían enrutarse a través del tunel creado y gestionarse por el proveedor de VPN. Pero puede que a la hora de reservar una dirección IP se produzca algún error y el DHCP utilice los servidores DNS establecidos en el sistema operativo.

UTILIZAR VPNs Y CLIENTES CON DNS LEAK PROTECTION

No todos los servicios VPN y los clientes utilizados disponen de protección para evitar fugas de DNS. Conviene asegurarse de las características del servicio a utilizar o contratar.

NO UTILIZAR WINDOWS

Y la primera recomendación que tienes que tomar es…. no utilizar Windows !!! . Windows carece del concepto de DNS global. Cada interfaz de red puede tener su propio DNS, por lo que bajo ciertas circunstancias, el proceso del sistema svchost.exe enviará consultas DNS sin respetar la tabla de enrutamiento y la puerta de enlace predeterminada del túnel VPN, causando la fuga de peticiones.

Espero que os haya gustado.

Don’t give up. Great things take time.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *