Los mecanismos empleados hasta este punto para evitar fugas de información sensible ha abarcado únicamente el uso de TorButton para navegación por medio de un navegador web (herramienta completamente imprescindible cuando se trabaja con TOR) TorSocks y el soporte a Proxy SOCKS o HTTP que tienen algunas herramientas como Nikto o Hydra. No obstante, tal como se ha comentado en entradas anteriores, puede ocurrir que aunque se utilicen estos mecanismos para evitar DNS Leaks o ICMP Leaks (algunas herramientas realizan pings contra maquinas remotas para identificar si se encuentran activas) aun sigan ocurriendo sin que el usuario se entere de lo sucedido, por este motivo en primer lugar es recomendable no realizar ninguna petición DNS ni pings de forma manual (algo obvio no?) , además de que resulta bastante útil emplear algún sniffer para capturar todos los paquetes que utilicen el protocolo UDP o ICMP en la interfaz de red local, de esta forma se pueden ver los paquetes que se envíen a un destino utilizando uno de estos protocolos, de esta forma es posible saber si realmente existe alguna fuga de información, para esto normalmente se suele utilizar TCPDump o Wireshark.

En el caso de Wireshark solamente es necesario establecer el filtro del protocolo por ejemplo “udp” y automáticamente todos los paquetes capturados serán filtrados y solamente aquellos que viajen utilizando dicho protocolo serán los que aparezcan en el listado, en el caso de TCPDump es necesario ejecutar un comando como el siguiente:

>tcpdump -pni eth0 ‘port domain’

Con el comando anterior se pueden capturar las peticiones DNS que se realicen en la interfaz “eth0” donde la opción “-p” indica que la interfaz de red se encontrará en modo promiscuo, la opción “-n” indica que no se deben realizar conversiones de host a direcciones IP y viceversa y la opción “-i” indica la interfaz de red que se va a utilizar que como se puede ver es la “eth0”, finalmente TCPDump acepta expresiones regulares (del mismo modo que lo hace wireshark), en este caso solamente se indica un filtro muy simple donde el puerto saliente utilizado para realizar la conexión es el puerto de “domain” es decir, una conexión al servidor DNS que utiliza el sistema.

Con estas medidas se puede determinar si existe alguna posible fuga, sin embargo es mucho más interesante implementar un mecanismo que de forma efectiva “suprima” este tipo de problemas, es aquí donde entra en juego el concepto de “Proxy Transparente” que consiste en el tratamiento dinámico de los paquetes que viajan en la interfaz de red local utilizando una herramienta como iptables para capturar y analizar el contenido de los paquetes capturados y posteriormente ejecutar la redirección de todos los paquetes que cumplan con los filtros de iptables hacia el dominio de TOR, estos filtros en iptables deben incluir aquellas peticiones que utilizan un protocolo distinto al TCP Para conseguir esto se siguen los siguientes pasos:

  1. Definir las opciones de configuración de TOR adecuadas, hace algún tiempo TOR incluye un servicio DNS que permite tratar todas las peticiones a nombres de dominio de forma segura utilizando la red TOR, en concreto estas opciones son:

    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ácticos quiere decir que si se realiza una petición DNS para resolver una dirección de nombre de dominio a dirección IP, 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 utilizará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 equivalente a todas las direcciones o todos los nombres de dominio en todos los sufijos.

    3. DNSPort:

      TOR iniciará un servicio DNS para cualquier tipo de petición que desee resolver ya sea un nombre de dominio o una dirección IP, (siempre y cuando la opción se encuentre activada especificando un valor mayor a 0) asume un valor numérico, debe tenerse en cuenta que dicho valor es el puerto por el cual TOR iniciará el servicio, por esta razón debe encontrarse disponible sin ningún otro servicio escuchando en él. Por otro lado también puede especificarse 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 esta opción el valor por defecto es la dirección local (127.0.0.1)

    5. ClientDNSRejectInternalAddress:

      Asume el valor de 0 o 1 (por defecto es 1) indica que cualquier petición DNS que tenga por resultado una dirección IP interna, será automáticamente rechazada, esta característica es importante dado que evita posibles ataques “client-side” que pueden darse contra navegadores web en sitios web maliciosos. No se recomienda desactivar esta opción.

    6. TransPort:

      Esta opción es la que realmente, es utilizada para soportar un “Proxy Transparente” se especifica un puerto donde TOR escuchará en espera de conexiones, el sistema operativo objetivo (en este caso Linux) debe utilizar un firewall que sirva como proxy transparente (en este caso iptables) que permitirá que todas las peticiones entrantes sean redireccionadas a este puerto, por convención se asigna el 9040, pero puede declararse cualquiera, esta opción requiere que se indique también la opción “VirtualAddrNetwork”

    7. TransListenAddress:

      Asigna una dirección IP y un puerto para establecer conexiones al “Transparent Proxy” esta opción es útil para declarar el proxy a todo el segmento de red, sino se especifica solamente aplica a la maquina local.

    8. VirtualAddrNetwork:

      El valor de esta opción le permite a TOR utilizar una nueva dirección virtual, esta característica es utilizada por la propiedad AutomapHostsOnResolve

      Las opciones anteriores se incluyen en el fichero de configuración torrc y como se ha hecho en entradas anteriores, un fichero de configuración valido con estas características habilitadas puede ser el siguiente:

      AutomapHostsOnResolve 1

      AutomapHostsSuffixes

      ContactInfo midireccion6 at gmail dot com

      ControlPort 9051

      DataDirectory /home/adastra/tor-vidalia

      DirPort 80

      DNSPort 53

      ExitPolicy accept *:80,accept *:443,accept *:110,accept *:143,accept *:993,accept *:995,reject *:*

      HashedControlPassword 16:E73A00A7CC2A2F3F601B4B2DF5651F36744DBE0C96C26A0574DF63238A

      HiddenServiceDir /home/adastra/hidden_service_ssh/

      HiddenServicePort 22 127.0.0.1:22

      Log debug file /home/adastra/tor_data_directory/tor_log.log

      Nickname AdastraTORY

      ORPort 443

      RelayBandwidthBurst 10485760

      RelayBandwidthRate 5242880

      TransPort 9040

      VirtualAddrNetwork 10.192.0.0/10

  2. Ahora se deben redireccionar todas las peticiones hacia TOR utilizando IPTables tal como se ha indicado anteriormente, para ello se pueden utilizar el siguiente script (bash) que utiliza iptables para establecer las restricciones de trafico que deben aplicarse

    #!/bin/sh

    # destinations you don’t want routed through Tor

    NON_TOR=»192.168.1.0/24 192.168.0.0/24″

    # the UID Tor runs as

    TOR_UID=»1000″

    # Tor’s TransPort

    TRANS_PORT=»9040″

    iptables -F

    iptables -t nat -F

    iptables -t nat -A OUTPUT -m owner –uid-owner $TOR_UID -j RETURN

    for NET in $NON_TOR 127.0.0.0/9 127.128.0.0/10; do

    iptables -t nat -A OUTPUT -d $NET -j RETURN

    done

    iptables -t nat -A OUTPUT -p udp –dport 53 -j REDIRECT –to-ports 53

    iptables -t nat -A OUTPUT -p tcp –syn -j REDIRECT –to-ports $TRANS_PORT

    iptables -A OUTPUT -m state –state ESTABLISHED,RELATED -j ACCEPT

    for NET in $NON_TOR 127.0.0.0/8; do

    iptables -A OUTPUT -d $NET -j ACCEPT

    done

    iptables -A OUTPUT -m owner –uid-owner $TOR_UID -j ACCEPT

    iptables -A OUTPUT -j REJECT

    En este pequeño script (que ha sido tomado de la documentación oficial de TOR) se puede ver que en primer lugar se han declarado el puerto en el cual se encuentra en ejecución el Transparent Proxy, el cual debe coincidir con el valor establecido en el fichero de configuración de TOR (el valor en este caso es 9040) por otro lado también se indica el UID del usuario que inicia TOR, anteriormente se ha indicado como recomendación (casi obligatoria) que debe ser un usuario con privilegios limitados sobre el sistema y este usuario evidentemente no debería ser el usuario “root” por razones de seguridad. Posteriormente se ejecutan las reglas de iptables necesarias, en este caso, todas las peticiones que se lleven a cabo dentro de la red de área local, no necesitan ser “anónimas” y por ende no es necesario que sean filtradas por TOR, por este motivo las conexiones que se lleven a cabo hacia una dirección IP interna (o en la maquina local) no encontrarán ningún tipo de limitación o de tratamiento. Por otra parte las peticiones que se dirijan hacia una red externa (como por ejemplo internet) deben pasar por medio de TOR, en concreto deberán pasar por el puerto 9040.

  3. Con los pasos anteriores será suficiente para tener el “TransProxy” activo y listo para ser utilizado, no obstante aun pueden existir fugas de información, especialmente cuando se realizan peticiones desde ciertas aplicaciones, aquí se pueden aplicar las siguientes recomendaciones para garantizar completamente el anonimato sin sentir preocupación por los DNS Leaks.

    1. Como se ha mencionado con anterioridad, utilizar TorSocks cuando se utilice cualquier tipo de aplicación que se ejecute desde consola, (también aplica la ejecución de un navegador web) de esta forma cualquier petición que no viaje utilizando el protocolo TCP será terminada adecuadamente.

    2. NO realizar peticiones DNS ni Pings de forma directa contra maquinas remotas. Se recomienda en cualquier caso, emplear la utilidad tor-resolve para obtener la dirección IP de un nombre de dominio concreto.

    3. Finalmente, se recomienda utilizar el servidor DNS iniciado por TOR (El servidor que se ha iniciado utilizando opciones tales como DNSPort y DNSListenAddress) para resolver cualquier petición DNS que se realice. Para esto es necesario editar el fichero “/etc/resolv.conf” en maquinas Linux, el cual contiene el listado de nameservers que serán utilizados por el cliente para resolver un nombre de dominio a una dirección IP y viceversa. Evidentemente es el mejor mecanismo que se puede aplicar, no obstante es necesario que solamente exista solamente un “nameserver” en dicho listado (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 obviamente, necesario para poder navegar por internet. En el fichero resolv.conf debe existir el siguiente contenido (esto en el caso de que el servidor DNS de TOR se ejecute solamente en local)

      nameserver 127.0.0.1

      Con esto será suficiente para resolver cualquier nombre de dominio a dirección IP de forma “anónima” utilizando TOR como relay de la conexión, siendo un mecanismo sencillo, seguro y fácil de implementar con el fin de evitar molestas fugas de identidad.