bajo un Túnel DNS Solución Ej. Pr. 3.4.3.I.- Cómo Saltarse un Portal Cautivo mediante un Túnel DNS .......................................................................................................................................129

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

Práctica Nº3.-Proxy HTTP Caché. Squid

vez lo redireccione hacia quien corresponda (p.e. servidor Web www.google.es).

¡¡Advertencia!! Antes de empezar a implementar la práctica deberíamos tener en cuenta que un túnel DNS puede ser una vía de escape para poder navegar a través de una red controlada mediante un portal cautivo sin necesidad de autenticarnos, pero teniendo presente las limitaciones de ancho de banda que presenta a consecuencia de querer tunelizar tráfico HTTP/HTTPS sobre el protocolo DNS udp/53, el cual esta pensado originalmente para un trasiego de tramas de tamaño reducido y con necesidad de ancho de banda muy reducidas. Los desarrolladores de iodine advierten que el ancho de banda resultante que un equipo cliente puede llegar a obtener es de 680 Kbit/s de subida y 2,3 Mbit/s de bajada en una Intranet cableada, y de 50 Kbit/s de subida y 200 Kbit/s de bajada en una Intranet inalámbrica. Por este motivo, el uso de un túnel DNS puede ser interesante cuando queremos gestionar un servidor remoto mediante ssh, o queremos consultar un sitio Web con poca carga de contenidos, pero no en casos donde se requiera un importante ancho de banda.

Por esta razón, al final de la práctica se sugiere medir la velocidad de la conexión (p.e. mediante speedtest), y así advertir que tipo de conexiones abrir a través del túnel DNS.

En concreto para su implementación seguiremos los siguientes pasos, empezando en primer lugar por la configuración el servidor, y después con la del cliente: Paso Nº1.- Comenzaremos instalando el software servidor iodine en el servidor e iniciando su servicio iodined (demonio o servicio asociado a iodine). Señalar que las opciones de inicialización del servicio iodined son muy variadas (man iodine), pero destacaremos las siguientes: iodined [-f] [-P password] dirección_IP[/máscara] nombre_dominio

• -f, parámetro opcional que provoca que el servicio iodined se ponga a la escucha en modo foreground, evitando de esta forma que lo haga en background, lo cual nos permitirá desactivarlo en cualquier momento tecleando un CTRL+C. • -P, parámetro opcional que nos permitirá indicar una password que será necesaria para autenticarse. En caso de no indicarla se solicitará al ejecutar el comando iodined. • dirección_IP[/máscara], parámetro obligatorio que informará al servicio iodined de cual será la dirección IP que recibirá el extremo servidor del túnel DNS. En concreto, iodined creará una interfaz de red virtual en el equipo servidor, p.e. dns0, la cual recibirá la dirección IP indicada, modificando en consecuencia su tabla de enrutamiento, y que usará para comunicarse con el otro extremo del túnel (equipo cliente). Por tanto, la elección de la

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 130

Práctica Nº3.-Proxy HTTP Caché. Squid

dirección IP establecerá el rango de direcciones IP privadas que se usarán en la comunicación entre cliente y servidor, motivo por el cual es obligatorio que dicho rango de direcciones IP no se este utilizando simultáneamente en las redes privadas o Intranet en las cuales se encuentran cliente y servidor, ya que en ese caso la tabla de enrutamiento ocasionaría una ambigüedad al sistema al tomar la decisión de como enrutar los paquetes hacia el destino. En el caso práctico que aquí se resuelve se usa el rango de • nombre_dominio, parámetro obligatorio que establecerá bajo que resolución de nombres de dominio se encapsulará el trafico que genere el cliente hacia el servidor. [root@servidor]# apt-get install iodine [root@servidor]# iodined -f -P mipass 10.0.0.1/24 test.prub

Una vez iniciado el servicio podremos comprobar el aspecto que tiene su nueva tabla de enrutamiento abriendo una nueva terminal (iodined se inicia en modo foreground dejando inoperativa la terminal). En concreto, deberemos fijarnos en que se ha creado una nueva interfaz de red virtual, p.e. dns0, a través de la cual se enrutará todo el trafico dirigido hacia equipos de la red 10.0.0.0/24 (se supone que la dirección de red de la Intranet donde se encuentra el servidor iodined es la 192.168.1.0/24, y que su interfaz de red física es inalámbrica, wlan0). [root@servidor]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 wlan0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 dns0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 wlan0

Por último, para terminar de configurar el servidor iodined, deberemos activar el ip_forward y el enmascaramiento de los paquetes (repasar prácticas del firewall), con la finalidad de que el servidor pueda hacer las veces de puerta de enlace para los equipos clientes que establezcan el túnel DNS. [root@servidor]# echo 1 > /proc/sys/net/ipv4/ip_forward [root@servidor]# iptables -t nat -A POSTROUTING -j MASQUERADE

¡¡Observación Importante!! Para comprobar que el servicio iodined está a la escucha, puede hacerse una exploración de puertos mediante los comandos netstat o nmap (nmapfe o zenmap son herramientas basadas en nmap con entorno gráfico).

En el caso de usar netstat, es conveniente usar los siguientes parámetros para no obtener demasiada información: (1) -l, para filtrar los servicios que están a la escucha (listening), (2) -u, para indicar que en el resultado del escáner solo muestre información sobre los servicios UDP (el servicio DNS al que suplanta iodined trabaja por defecto bajo udp/53), (3) -p, para poder identificar el PID del proceso que da dicho servicio, y (4) -n, para informar mediante direcciones IP en lugar de nombres de dominio asociados. No obstante, también podemos filtrar al máximo el resultado apoyándonos en el comando grep. [root@servidor]# netstat -l -u -p -n

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 131

Práctica Nº3.-Proxy HTTP Caché. Squid

[root@servidor]# netstat -lupn | grep ":53 " [root@servidor]# netstat -lupn | grep iodined udp 0 0 0.0.0.0:53 0.0.0.0:* 32502/iodined

En el caso de usar nmap, sabiendo que por defecto iodined ofrece el servicio vía UDP por el puerto 53 (suplanta a un servidor DNS), le diremos que analice ese puerto directamente para evitar tiempo de computo innecesario. Las opciones -sU y -p nos permiten indicarle a nmap que únicamente analice protocolos UDP en el rango de puertos que le especifiquemos: [root@servidor|cliente|equipo_red]# nmap -sU -p 53 dirección_IP_Servidor_iodined PORT STATE SERVICE 53/udp open|filtered domain

Según lo anterior deberemos tener en cuenta que en el equipo servidor donde iniciemos iodined no debe estar iniciado simultáneamente ningún otro software servidor que de servicio por el mismo puerto udp/53 (algún servicio DNS), como podría ser bind9. En caso contrario, se produciría un conflicto entre ambos servicios, no pudiendo establecerse el túnel. Paso Nº2.- Tras configurar el servidor, continuaremos instalando iodine en el equipo cliente para posteriormente establecer el túnel DNS de comunicación. Respecto a los parámetros que podrían usarse en la aplicación cliente iodine, podríamos destacar los siguientes: iodine [-f] [-P password] [dirección_IP_Servidor] nombre_dominio

• -f, parámetro opcional, que al igual que en el servidor, provoca que iodine establezca el túnel de comunicación con el servidor en modo foreground, evitando de esta forma que lo haga en background, lo cual nos permitirá desactivarlo en cualquier momento tecleando un

CTRL+C. • -P, parámetro opcional que nos permitirá indicar una password que será necesaria en la autenticación contra el servidor. Obviamente indicaremos la que se asigno en el servidor al iniciar el servicio iodined. En caso de no indicarla se solicitará al ejecutar el comando iodine. • dirección_IP_Servidor, parámetro opcional que informará a iodine de cual será la dirección IP o nombre de dominio del servidor DNS que será usado para salir a Internet y conocer de esta forma la dirección IP asociada al servidor iodined. En concreto, para que la solicitud quede totalmente camuflada, debería adquirirse un nombre de dominio de segundo nivel (2LD, second Level Domain) con gestión propia, p.e. amromero.es, de tal forma que podamos asociar a su registro NS (NameServer) la dirección IP del servicio iodined. No obstante, si lo único que pretendemos de momento es realizar pruebas de funcionamiento, podremos poner directamente la dirección IP del servidor iodined, que es lo que se ha hecho en la resolución de la práctica. • nombre_dominio, relacionado con lo indicado en el punto anterior, este parámetro obligatorio indicará el nombre del dominio que cuya resolución nos llevará a conocer la dirección IP del servidor iodined. Éste deberá estar en consonancia con el dominio indicado al iniciar el servidor iodined. En el caso práctico que aquí se muestra, al indicar como dirección IP del servidor, la del servidor iodined, el nombre de dominio puede ser ficticio (p.e. test.prub).

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 132

Práctica Nº3.-Proxy HTTP Caché. Squid

[root@cliente]# apt-get install iodine [root@cliente]# iodine -f -P mipass dirección_IP_Servidor_iodined test.prub ... Setting IP of dns0 to 10.0.0.2 Setting MTU of dns0 to 1130 Server tunnel IP is 10.0.0.1 Testing raw UDP data to the server (skip with -r) Server is at dirección_ip_Servidor_iodined, trying raw login: OK Sending raw traffic directly to dirección_ip_Servidor_iodined Connection setup complete, transmitting data.

Tras lanzar el comando anterior y establecerse exitosamente el túnel DNS, debería haberse creado en el cliente, al igual que ocurrió en el servidor, una interfaz de red virtual dns0 con una dirección IP del mismo rango reservado por el servidor iodined 10.0.0.0/24. En concreto, si es el primer cliente que se conecta recibirá la dirección IP siguiente en el rango a la que se asigno al servidor 10.0.0.2. Es decir, que el servidor iodined actúa como un servidor DHCP asignando a los clientes una dirección IP del rango reservado.

Por lo tanto, si visualizamos la tabla de enrutamiento del equipo cliente deberíamos ver algo parecido a lo siguiente (se supone que el equipo cliente se encuentra en una Intranet con dirección de red 192.168.123.0/24, y que su interfaz de red física es inalámbrica, wlan0): [root@cliente]# route -n Destino Pasarela Genmask Indic Métric Interfaz 0.0.0.0 192.168.123.254 0.0.0.0 UG 0 wlan0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 dns0 192.168.123.0 0.0.0.0 255.255.255.0 U 9 wlan0

Por último, para aprovecharnos del túnel DNS creado, mediante el uso de reglas de enrutamiento estáticas redireccionaremos el trafico de Internet hacia el servidor iodined, sin olvidarnos de que para mantener el túnel DNS activo, deberemos introducir las reglas correspondientes de acceso al servidor a través de la puerta por defecto de la Intranet (suponiendo que el servidor DNS preferente configurado en el cliente es el 8.8.8.8): [root@cliente]# route add -host 8.8.8.8 gw 192.168.123.254 [root@cliente]# route add -host dirección_ip_Servidor_iodined gw 192.168.123.254 [root@cliente]# route del default gw 192.168.123.254 [root@cliente]# route add default gw 10.0.0.1

De esta forma la tabla de enrutamiento resultante debería quedar así: [root@cliente]# route -n Destino Pasarela Genmask Indic Métric Interfaz 192.168.123.0 0.0.0.0 255.255.255.0 U 9 wlan0 ip_Servidor_iodined 192.168.123.254 255.255.255.255 UH 0 wlan0 8.8.8.8 192.168.123.254 255.255.255.255 UH 0 wlan0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 dns0

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 133

0.0.0.0

Práctica Nº3.-Proxy HTTP Caché. Squid

10.0.0.1 0.0.0.0 UG 0 dns0

¡¡Observación!! Al indicarse en el comando iodine directamente la dirección IP del servidor iodined, en lugar de la dirección del servidor DNS permitido en la Intranet, es posible que en un entorno real no se pueda crear el túnel DNS, en función de como haya sido filtrado el servicio udp/53. Por ejemplo, si las consultas hacía el servicio DNS dentro de una Intranet protegida con portal cautivo han sido filtradas han sido filtradas y se permite únicamente consultar por ejemplo al servidor DNS 8.8.8.8 (repasar el capitulo de prácticas asociado al firewall iptables), no será posible establecer la conexión de la forma anterior. [root@firewall_Intranet] iptables -t filter -A FORWARD -p udp --dport 53 -d 8.8.8.8 -j ACCEPT [root@firewall_Intranet] iptables -t filter -A FORWARD -p udp --dport 53 -j DROP [root@firewall_Intranet] iptables -t filter -A FORWARD -p udp --dport 53 \ -m state --state ESTABLISHED,RELATED -j ACCEPT

En ese caso, al no poder hacer consultas DNS directamente tal como se ha indicado anteriormente será necesario registrar un nombre de dominio público, p.e. amromero.es, con la posibilidad de gestión de los registros DNS, e indicar que el servidor NS (NameServer) que el equipo encargado de resolver nombres asociados a dicho dominio es el servidor iodined. Es decir, podría ser algo así: amromero.es. IN NS iodined.amromero.es. iodined.amromero.es. IN A dirección_IP_pública_Servidor_iodined

Para terminar con la práctica, sería conveniente hacer un test de velocidad y así comprobar el ancho de banda que nos ofrece un túnel DNS, de tal forma que seamos conscientes de que tipo de aplicaciones podemos tunelizar: conexiones SSH, tráfico HTTP/HTTPS con pequeña carga en sus contenidos (texto, imagenes, etc.), transferencia de archivos de reducido tamaño, etc. Para la medición podemos descargarnos la aplicación python speedtest: [usuario@cliente]$ wget https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py [usuario@cliente]$ chmod +x speedtest_cli.py [usuario@cliente]$ ./speedtest_cli.py Retrieving speedtest.net configuration... Retrieving speedtest.net server list... Testing from Orange Espana (dirección_IP_pública_asociada_Servidor_iodined)... Selecting best server based on ping... Hosted by iA Soft Aragon (Zaragoza) [0.54 km]: 29.643 ms Testing download speed........................................ Download: 0.08 Mbits/s Testing upload speed.................................................. Upload: 0.10 Mbits/s

Seguridad Informática y Alta Disponibilidad – amartinromero@gmail.com 134