Inicio > Hacking, Networking, Services - Software > Preservando el Anonimato y Extendiendo su Uso – Evitando DNS (UDP) Leaks y otras fugas de Identidad – Parte XIV

Preservando el Anonimato y Extendiendo su Uso – Evitando DNS (UDP) Leaks y otras fugas de Identidad – Parte XIV

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.

  1. Guillermo
    marzo 13, 2012 en 4:02 pm

    Hola, he estado buscando el fichero torrc, pero no aparece… lo mas parecido (en cuanto a nombre de fichero) son los ficheros torrc.sample y torrc.sample.in. Sin embargo, difieren mucho del fichero de ejemplo mostrado en este post…

    Por cierto gran post…

    Me gusta

  2. marzo 13, 2012 en 4:22 pm

    La ubicación de dicho fichero depende de como estes ejecutando TOR, por lo que comentas, seguramente lo estas ejecutando con Vidalia, en tal caso, el fichero torrc se encuentra en el directorio de Vidalia, por ejemplo en sistemas windows:

    C:\<USUARIO\Datos de programa\Vidalia\torrc

    en sistemas Linux:
    ~/.vidalia/torrc

    Me gusta

  3. Guillermo
    marzo 14, 2012 en 10:18 am

    Perdona, no te comenté… ejecuto tor + privoxy en una BT R2. los logs de arranque y uso de tor indican que no existe este fichero torrc.. Mi pregunta es debo crearlo y luego ejecutar el script para las restricciones de trafico?

    Si no es demasiado, me gustaria que me comentases tambien, si a efectos de anonimato, es mejor hacer correr a tor bajo sockets4a.
    Gracias de antemano

    Me gusta

    • marzo 14, 2012 en 11:44 am

      Vale, tienes que crearte un fichero torrc y pasarlo como parámetro cuando ejecutes tor, esto es importante para que te funcione todo correctamente. Correr con socks4a es mejor que sock4 y socks5 principalmente por el tema de los DNS Leaks. Fijate en las publicaciones anteriores en esta serie sobre anonimato para entender mejor los conceptos clave.
      Un Saludo.

      Me gusta

  4. Guillermo
    marzo 14, 2012 en 11:58 am

    Si he estado leyendo sobre eso… y más o menos es lo mismo que habia deducido, aun no logro hacer correr a tor bajo socks4a, (a pesar de la especificicacion forward-socks4a / 127.0.0.1:9050 en el fichero de configuración de privoxy) supongo que algo se me debe estar pasando…
    Gracias por tu respuesta… repasare tu gran serie de publicaciones sobre el tema antes de ponerme a ello.
    Un saludo.

    Me gusta

  5. Guillermo
    marzo 14, 2012 en 4:06 pm

    Una cosa más, existe/conoces alguna forma de montar o pasar un test de comprobación de DNS Leaks?

    Me gusta

    • Guillermo
      marzo 14, 2012 en 4:39 pm

      En fin, se que existen algunos via web, pero no conozco la fiabilidad de los mismos…

      Me gusta

    • marzo 14, 2012 en 5:48 pm

      Montandote un servidor DNS en local y analizando todos los paquetes que pasan por el puerto 53

      Me gusta

  6. javi
    agosto 16, 2012 en 7:50 pm

    Hola, tengo configurado Debian con tor, privoxy, proxychains, torsocs, y el fichero torrc de esta manera:
    AutomapHostsOnResolve 1
    AutomapHostsSuffixes .
    DNSPort auto
    DNSListenAddress
    ClientDNSRejectInternalAddress 1
    TransPort 9040
    TransListenAddress
    VirtualAddrNetwork 10.192.0.0/10
    Tambien he puesto el scrip con iptables y cambiado el nameserver a 127.0.0.1.
    El problema es que cuando uso tor-resolve a una direccion me da la ip 10.192.0.1, si lo intento con otra la ip que me da es 10.192.0.2 y asi sucesivamente.
    ¿Me podriais decir porque pasa esto y como arreglarlo si es posible?
    Gracias y un saludo

    Me gusta

    • agosto 16, 2012 en 8:21 pm

      Intenta dándole valor a estas propiedades.
      DNSPort
      DNSListenAddress

      Esta pillando los valores por defecto, intenta utilizar los valores de configuración que especifico en esta publicación y probar que tal funciona.
      Desde ya te puedo decir, que el problema esta relacionado con la resolución DNS local y esto lo controlas desde las propiedades DNS*

      Me gusta

  7. javi
    agosto 16, 2012 en 11:01 pm

    hola, he hecho unos cambios, como me has comentado:

    AutomapHostsOnResolve 1
    AutomapHostsSuffixes .
    DNSPort 53
    DNSListenAddress 127.0.0.1
    ClientDNSRejectInternalAddress 1 > aqui tiene que terminar en “es”
    TransPort 9040
    TransListenAddress 127.0.0.1
    VirtualAddrNetwork 10.192.0.0/10

    Pero me da un warn :

    notice : opening DNS listener on 127.0.0.1:53
    warn : could not bin to 127.0.0.1:53 Permission denied

    Estoy confuso por esto, ¿como debo de editarlo para que tenga permiso?
    Gracias por tu ayuda

    Me gusta

    • agosto 16, 2012 en 11:12 pm

      Sip, este error se debe a que no tienes permisos para abrir el puerto 53 (bind port) todos los puertos inferiores a 1024 son reservados y solamente el usuario con privilegios de root puede abrirlos, seguramente no estas ejecutando TOR como root y haces bien! debes seguir ejecutando TOR como lo haces hasta ahora, solamente que debes utilizar una herramienta como authbind para que puedas abrir el puerto 53 con los privilegios de root y una vez abierto, remover automáticamente los privilegios de root y volver a tu cuenta de usuario limitada.

      Puedes ver como se hace desde este articulo:
      https://thehackerway.com/2011/10/07/bind-a-puertos-reservados-utilizando-usuarios-sin-privilegios-de-root/

      Seguir las recomendaciones del enlace anterior siempre son una buena practica, ya que muchos servicios importantes (como servidores web, ssh, ftp, etc.) se ejecutan sobre puertos inferiores a 1024 y muchos administradores los arrancan con el usuario root sin ser del todo conscientes del riesgo que esto supone… en fin, esto te servirá no solamente para TOR, sino para configurar cualquier servicio que requiera privilegios de root.

      Me gusta

  8. javi
    agosto 17, 2012 en 8:44 pm

    Hola, gracias por el enlace de authbind, es realmente ha tenerlo muy en cuenta. Despues de probar varias cosas ya funciona, asi es como lo he dejado:
    SocksPort 9050
    SocksListenAddress 127.0.0.1
    AutomapHostsOnResolve 1
    AutomapHostsSuffixes .exit, .onion
    DNSPort 8853
    DNSListenAddress 127.0.0.1
    ClientDNSRejectInternalAddress 1
    TransPort 9040
    TransListenAddress 127.0.0.1
    VirtualAddrNetwork 10.192.0.0/10
    ControlPort 9051
    ControlListenAddress 127.0.0.1
    Con authbind DNSPort 53 funciona perfectamente, luego mire un archivo torrc que usaba el 8853 y he comprobado que tambien funciona.

    El nameserver se renueva a cada reinicio, es algo que no tuve en cuenta, ¿es posible dejarlo con la ip 127.0.0.1 y que no cambie al reinicio?
    Un sincero gracias.

    Me gusta

  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: