Práctica Nº3.-Proxy HTTP Caché. Squid
Ej. Práctico 3.4.3: Evitar un Portal Cautivo mediante el Encapsulamiento HTTP/HTTPS bajo un Túnel DNS En este ejercicio práctico se propone la implementación de un Túnel DNS con la finalidad de detectar alguna de las vulnerabilidades que ofrece un portal cautivo. Es decir, a lo largo del ejercicio se explicará dicha vulnerabilidad, y se detallarán los pasos necesarios para implementar un Túnel DNS mediante el software iodine, lo que nos permitirá encapsular sobre dicho túnel las tramas HTTP/HTTPS que generamos cuando navegamos.
Solución Ej. Pr. 3.4.3.I.- Cómo Saltarse un Portal Cautivo mediante un Túnel DNS Una vez implementado el portal cautivo, si repasamos el protocolo de actuación entre el cliente y el servidor, podremos detectar que tiene un pequeño resquicio de vulnerabilidad que podremos aprovechar para saltárnoslo, y evitar tener que autenticarnos. Esto nos permitiría saltarnos esta herramienta de control de acceso en la mayor parte de los hoteles, bibliotecas, centros comerciales, o aeropuertos que la implementan. Es decir, cuando un cliente quiere intentar navegar en un entorno donde hay implementado un portal cautivo, a grandes rasgos, sucede lo siguiente: (1) El cliente, normalmente de manera inalámbrica, se conecta a la red WIFI abierta del entorno en que se encuentra. (2) A continuación, el cliente inicia un cliente Web (p.e. Mozilla Firefox o Chrome) con la intención de navegar por Internet. Para ello coloca en la barra de direcciones del navegador "http://" seguido del nombre de dominio correspondiente al servidor HTTP/HTTPS al que se desea conectar. (3) Al darle al botón de "Ir" o "Navegar", siendo transparente para el usuario, en primer lugar el equipo cliente hace una solicitud de resolución DNS para conocer cual es la dirección IP pública correspondiente al nombre de dominio del servidor al que se desea conectar. Para ello, a no ser que la resolución ya se encuentre cacheada en algún servidor DNS Caché de la Intranet, la solicitud DNS del cliente sale a Internet para averiguarlo. (4) Una vez que el equipo cliente recibe el resultado de la resolución es cuando por fin intenta realizar una conexión HTTP/HTTPS (tcp 80/443) a la dirección IP asociada al servidor Web. (5) El equipo Gateway/Proxy/Firewall detecta que el cliente quiere navegar vía tcp 80/443, y mediante una NAT PREROUTING redirige la petición hacia el portal cautivo solicitándonos una autenticación. Según todo lo anterior, podremos advertir que en el paso (3) la solicitud DNS generada por nuestro equipo navega por Internet sin tener que pasar por el control de acceso del portal cautivo, aspecto que muchos desarrolladores de software han tenido en cuenta para crear herramientas (p.e. iodine) que permitan navegar al usuario vía protocolo DNS udp/53, mediante la creación previa de lo que se denomina un tunel DNS, consistente en encapsular tramas del protocolo HTTP/HTTPS dentro de las tramas DNS. No obstante, cabe resaltar que existen de igual forma otras herramientas software de detección que tras analizar las tramas DNS pueden detectar nuestra intención y descartarla. En definitiva, tal como vamos a poder comprobar mediante la implementación del siguiente ejercicio práctico, se va a implementar una "especie de VPN" mediante un túnel DNS udp/53, que nos permitirá encapsular todo el trafico que genere el cliente hacia el servidor, para que este a su
Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 129
