Evitando DNS Leaks y fugas de informacion en Tor

Las fugas de información por peticiones DNS o simples "pings" contra un servidor remoto, constituyen uno de los problemas más comunes cuando se trabaja con TOR. Como toda las peticiones que viajan por medio de un circuito Tor, deben utilizar obligatoriamente el protocolo TCP ya que es el único protocolo soportado por la red. No obstante, es habitual encontrar aplicaciones como navegadores web que ejecutan peticiones DNS de forma autmática contra servicios en internet para resolver su dirección IP o nombre de dominio.

Dado que el protocolo DNS se apoya sobre UDP, y dichas peticiones se ejecutan de forma directa contra el objetivo, exponiendo de esa forma la firección IP real del usuario.

Por otro lado, también existen aplicaciones como el caso de Nmap que también pueden ejecutar este tipo de peticiones o lanzar "pings" para comprobar la disponibilidad del objetivo y evidentemente, dado que las peticiones "echo request" utilizan el procolo ICMP, dichas peticiones también se ejecutarán de forma directa contra el objetivo, sin pasar por medio del circuito Tor.

Existen algunas directivas de configuración que permiten crear un proxy transparente que permita el tratamiento dinámico de los paquetes que viajan por la interfaz del a red espacificada y además, es posible utilizar "iptables" para capturar y analizar el protocolo de los paquetes para posteriormente, ejecuatar la redirección de todos aquellos que utilizan un protocolo distinto al TCP. Para conseguir esto se siguen los siguientes pasos.

Se deben especificar las opciones de configuración Tor adecuadas, las cuales permitirán crear un servicio DNS apra tratar todas las peticiones a nombrar un dominio utilizando la red Tor. A continuación, se indican rápidamente cúales son esas opciones de configuración.

1. AutomapHostsOnResolve: Cuando esta opción se encuentra activa (con valor 1) se mapea cualquier petición que tenga al menos uno de los sufijos indicados en la opción "AutomapHostsSuffixes" a una dirección virtual, esto a efectos prácticosquiere decir que si se realiza una petición DNS para resolver un nombre de dominio, Tor se encargará de retornar una dirección IP virtual que servirá de puente entre el nombre de dominio y el cliente.
2. AutomapHostsSuffixes: indica los sufijos que se utilizán en la opción "AutomapHostsOnResolve" para la asignación dinámica de direcciones virtuales. Los valores por defecto de esta opción son ".exit" y ".onion". Cuando se indica el valor de "." es evidentemente a todas las direcciones o todos lso nombres de dominio en todos los sufijos.
3. DNSPort: Tor indicará un servicio DNS para qualquier tipo de petición de resolución. Se asume un valor numérico, debe tenerse en cuanta que dicho valor es el puerto por el cual Tor indocará el servicio, por esta razón debe encontrarse disponible. Por lo tanto, tambien puede encontrarse el valor de "auto" para que Tor escoja un puerto para iniciar el servicio.
4. DNSListenAddress: la dirección IP en la que se iniciará el servicio DNS, cuando no se especifica eta opción el valor por defecto de la dirección local (127.0.0.1).
5. ClientDNSRejectInternalAddress: Asume el valor 0 o 1 (por defecto 1) e indica que cualquier petición DNS cuyo resultado sea una dirección IP interna, será automáticamente rexhazada. Esta opción es importante dado que evita posibles ataques "client-side" que puede darse contra navegadores web en sitios miliciosos.
6. TransPort: Se utiliza para iniciar un servidor proxy transparente y permite especificar un puerto donde Tor esperará conexiones. En el sistema objetivo se debe utilizar un firewall que sirva como proxy transparente, como por ejemplo "iptables" y que permitirá que todas las peticiones entrantes sean redireccionadas al puerto indicado en esta opción de configuración. Por convención se asigna el 9040, pero puede declararse cualquier otro.
   Esta opción también requiere que se indique la opción "VirtualAddrNetwork".
7. TransListenAddress: Asigna una IP y un puerto para establecer conexiones a un proxy transparente que será indicado pro la instancia Tor. Esta opción es útil para declarar el proxy a todo el segmento de la red y si no se especifica solamente aplica a la máquina local.
8. VirtualAddrNetwork: El valor de esta opción le permite a Tor utiliza una nueva dirección virtual, esta característica es soportada por la propiedad de configuración "AutomapHostsOnResolve" visita unos párrafos más arriba.

Las opciones anteriores se incluyen en el fichero de configuración "torrc":

AutomapHostsOnResolve 1
AutomapHostsSuffixes
ControlPort 9051
DataDirectory /home/adastra/tor
DirPort 80
DNSPort 53
Log debug file /home/adastra/tor_data_directory/tor_log.log
TransPort 9040
VirtualAddrNetwork 10.192..0.0/10

A continuación se deben enrutar todas las peticiones hacia el proxy transparente, para ello se puede utilizar "iptables" en sistemas Linux.

El script anterior ha sido todado de la documentación de Tor y tal como se puede apreciar, en primer lugar se ha declarado el puerto que se encuentra en la ejecución el servidor proxy transparente, el cual debe concidir con el valor establecido en el fichero de configuración de Tor (puerto 9040).
Por otro lado también se indica el UID del usuario que inicia Tor, que debe ser un usuario con privilegios limitados sobre el sistema y evidentemente no debería ser un usuario "root" por razones de seguridad. Posteriormente se ejecutan las reglas de iptables necesarias. En este caso, todas las peticiones que se llevan a cabo dentro de la red de área local no necesitan pasar por nedio del proxy transparente de Tor, por ese motivo las conexiones que se llevan a cabo hacia la dirección IP interna o en la máquina local, no encontrarán ningún tipo de limetación o fitrado. Por otra parte, las peticiones que cuyo destino sea internet, deben pasar por medio del proxy transparente que se ha indicado en el puerto "9040".
Con los puntos anteriores será suficiente para tener el "TransProxy" activo y listo para ser utilizado, no obstante aun puede existir fugas de información, especialmente cuando se realizan peticiones desde ciertas aplicaciones. A continuación, se listan un conjunto de recomendaciones adicionales para evitar DNS Leaks.

1. Utilizar TorSocks cuando sea necesario ejecutar cualquier tipo de aplicación desde la consola, de esta forma cualquier petición que no viaje utilizando el protocolo TCP será terminada adecuadamente.
2. No realizar peticiones DNS ni ejecutar el comando "ping" de forma directa contra sistemas remotos. Se recomienda en cualquier caso, emplear al unidad "tor-resolve" para poder resolver nombres de dominios o direciones IP.
3. Se recomienda utilizar el servidor DNS iniciado por una instancia Tor que utilice las opciones de configuración "DNSPort" y "DNSListenAddress" para resolver cualquier petición DNS que se realice. Para esto es necesario editar el fichero "/etc/resolv.conf" en sistemas Linux, el cual contiene el listado de "nameservers" que serán utilizados por el cliente para resolver un nombre de dominio o dirección IP y viceversa.
   Evidentemente es el mejor mecanismo que se pueda aplicar, no obstante es necesario que exista un "nameserver" en dicho listado, el caul corresponderá a la dirección local o aquella en la que se encuentra el servidor DNS de Tor en ejecución, además de que el sistema entero dependerá de que Tor se encuentre en ejecución para que se puedan resolver nombres de dominio, lo que es necesario para poder navegar por internet. En el fichero "resolv.conf" debe existir el siguiente contenido en el caso de que el servidor DNS de Tor sea ejecutado localmente.
   

   nameserver 127.0.0.1

Con esto será suficiente para resolver cualquier nombre de dominio de forma anónima utilizando Tor, siendo un mecanismo sencillo, seguro y fácil de implementar con el fin de evitar fugas de información.

por Daniel Echeverri Montoya.