Archivo

Posts Tagged ‘bridges tor’

Crea tu propia red privada de TOR – Emulación de TOR con Chutney

noviembre 20, 2014 3 comentarios

Somos muchos los que nos interesa saber cómo funciona TOR, pero también somos muchos los que sabemos que existen varios riesgos cuando entramos a ese tipo de redes cuando lo único que queremos es hacer pruebas, por ese motivo, una buena forma de comprender el funcionamiento de todos los elementos que conforman TOR, sin acceder directamente a la red, es por medio de herramientas y librerías que permiten simular y/o emular la red.
En primer lugar, es necesario entender la diferencia entre simular y emular, ambos términos a veces suelen utilizarse como si se tratase de sinónimos, pero no son lo mismo. Cuando simulamos un sistema, contamos con modelo muy especifico que aplica a un contexto particular, por ejemplo, podemos simular el rendimiento midiendo los tiempos de respuesta y haciendo estimaciones sobre su comportamiento con una mayor carga o con más o menos recursos, es decir, una simulación es un mecanismo que permite modelar un sistema en unas condiciones determinadas y es muy útil para hacer estimaciones. Por otro lado, cuando se habla de emular, se duplica el sistema y se ejecuta de forma independiente al sistema original, es decir, se produce una replica del sistema y se puede observar y analizar su comportamiento, dando resultados mucho más exactos que los que puede proporcionar una simulación.
Ahora bien, las simulaciones y emulaciones son términos que seguramente resultarán bastante conocidos y utilizados a los administradores de sistemas y redes, ya que existen varias herramientas que emplean ambos mecanismos para medir los limites de un sistema o el número de clientes concurrentes que pueden estar conectados a una red sin deteriorar su rendimiento. En este sentido, es posible utilizar algunas de estas mismas herramientas para probar el funcionamiento de TOR sin necesidad de conectarse directamente a las autoridades de directorio oficiales. El objetivo de este articulo y el siguiente, es enseñar el uso de dos herramientas que son recomendadas por el equipo de TOR para hacer pruebas sobre la red, dichas herramientas son Chutney y Shadow, la primera es una herramienta de emulación y la segunda de simulación. En esta entrada nos centraremos en Chutney y en la próxima se hablará sobre Shadow.

Instalación y uso de Chutney

Chutney es una herramienta que permite emular y configurar una red privada con TOR muy rápidamente, permitiendo crear varios escenarios en los que Chutney es capaz de levantar autoridades de directorio, repetidores, clientes, bridges y cualquier elemento adicional que conforma la red de TOR. Usar Chutney no es complicado, de hecho es una herramienta bastante sencilla e intuitiva, pero para configurar escenarios de prueba, es necesario conocer bastante bien las propiedades de configuración que admite TOR, es decir, aquellas que típicamente se incluyen en el fichero de configuración “torrc”.
El proyecto se encuentra ubicado en la siguiente ruta: https://gitweb.torproject.org/chutney.git y para comenzar a usarlo, basta con clonar el repositorio GIT y lanzar la utilidad “chutney”

>git clone https://git.torproject.org/chutney.git
Clonar en «chutney»…
remote: Counting objects: 364, done.
remote: Compressing objects: 100% (170/170), done.
remote: Total 364 (delta 180), reused 282 (delta 137)
Receiving objects: 100% (364/364), 58.68 KiB | 0 bytes/s, done.
Resolving deltas: 100% (180/180), done.
Checking connectivity… hecho.
>cd chutney
>./chutney
Error: Not enough arguments given.
Usage: chutney {command} {networkfile}
Known commands are: configure hup restart start status stop verify

Para ejecutar “chutney” se debe indicar un comando y un fichero de configuración de red. Los comandos disponibles son “configure”, “hup”, “restart”, “start”, “status”, “stop” y “verify”. Además, se debe indicar la ruta del fichero de configuración de red como segundo argumento del comando.

Para que la herramienta funcione correctamente, el comando “tor” debe ser un comando valido para el usuario que lo ejecuta, es decir, que TOR se debe encontrar instalado en el sistema y el usuario en cuestión debe de tener los privilegios suficientes para poder ejecutarlo, de lo contrario, “chutney” enseñará el siguiente mensaje.

>./chutney configure networks/basic
Starting nodes
Cannot find tor binary ‘tor’. Use CHUTNEY_TOR environment variable to set the path, or put the binary into $PATH.

Basta con establecer la ruta donde se encuentra el ejecutable en la variable de entorno PATH.

>nano /home/adastra/.bashrc
export PATH=”$PATH:/TOR/tor-browser_40/Browser/TorBrowser/Tor/tor”
>source ~/.bashrc

Si TOR se ha instalado desde algún repositorio de Debian, CentOS o Fedora, no debería haber mayores problemas, sin embargo se recomienda instalar la última versión de TOR disponible, preferiblemente desde el código fuente.

Después de tener todos los elementos instalados y listos para ser utilizados, el primer paso en la puesta en marcha de “chutney” es invocar al comando “configure” para crear todos los directorios y las claves necesarias para instanciar las autoridades de directorio en la máquina donde se ejecuta la herramienta. Dicho comando se debe ejecutar sobre un directorio de configuración de red y en este caso, “chutney” cuenta con algunos ficheros de ejemplo que pueden ser útiles para probar la herramienta. Dichos ficheros se encuentran incluidos en el directorio “networks”.
Cuando se ejecuta el comando “configure”, la herramienta se encarga de crear automáticamente el directorio “net”, el cual incluye todos los elementos necesarios para emular la red de TOR.

>./chutney configure networks/basic
Creating identity key /chutney/net/nodes/000a/keys/authority_identity_key for test000a with tor-gencert –create-identity-key –passphrase-fd 0 -i /chutney/net/nodes/000a/keys/authority_identity_key -s /chutney/net/nodes/000a/keys/authority_signing_key -c /chutney/net/nodes/000a/keys/authority_certificate -m 12 -a 127.0.0.1:7000Creating identity key /chutney/net/nodes/001a/keys/authority_identity_key for test001a with tor-gencert –create-identity-key –passphrase-fd 0 -i /chutney/net/nodes/001a/keys/authority_identity_key -s /chutney/net/nodes/001a/keys/authority_signing_key -c /chutney/net/nodes/001a/keys/authority_certificate -m 12 -a 127.0.0.1:7001Creating identity key /chutney/net/nodes/002a/keys/authority_identity_key for test002a with tor-gencert –create-identity-key –passphrase-fd 0 -i /chutney/net/nodes/002a/keys/authority_identity_key -s /chutney/net/nodes/002a/keys/authority_signing_key -c /chutney/net/nodes/002a/keys/authority_certificate -m 12 -a 127.0.0.1:7002The tor binary at ‘tor’ does not support the option in the torrc line:’TestingDirAuthVoteExit *’
The tor binary at ‘tor’ does not support the option in the torrc line:
‘TestingDirAuthVoteExit *’
The tor binary at ‘tor’ does not support the option in the torrc line:
‘TestingDirAuthVoteExit *’

Como se puede apreciar en las últimas líneas, la opción de configuración “TestingDirAuthVoteExit” no se ha encontrado y aunque es posible seguir trabajando con “chutney” sin problemas a pesar de este error, se trata de una propiedad de configuración que se ha incluido a partir de la versión “2.6-alpha” de TOR y a la fecha de redactar este artículo, aun no se encuentra disponible en la versión estable.
Ahora que se encuentra la red privada configurada, se puede controlar con los comandos “start”, “stop” y “status” tal como enseña la siguiente imagen.

chutney

Comandos disponibles en chutney

La configuración básica funciona correctamente y como se puede ver, se han creado una serie de procesos que representan instancias de TOR que se están ejecutando en la máquina local. No obstante, no se trata de instancias de TOR que se levantan con las propiedades por defecto de TOR Browser, se trata de instancias especialmente configuradas para levantar clientes, autoridades de directorio, repetidores de salida, bridges, etc. En este caso concreto, el contenido del fichero “networks/basic” tiene lo siguiente.

Authority = Node(tag=”a”, authority=1, relay=1, torrc=”authority.tmpl”)
Relay = Node(tag=”r”, relay=1, torrc=”relay.tmpl”)
Client = Node(tag=”c”, torrc=”client.tmpl”)
NODES = Authority.getN(3) + Relay.getN(8) + Client.getN(2)
ConfigureNodes(NODES)

Aunque pueda parecer complejo, esta es la estructura de cualquier fichero de configuración de red de la herramienta y en este caso concreto, se están creando 3 instancias de TOR que actuarán como autoridades de directorio, 8 como repetidores y 2 como clientes, lo que nos da un total de 13 nodos ejecutándose en la máquina local.
La estructura del fichero utiliza la API de “chutney” que se encuentra escrita en Python y cuya clase principal es “Node”, en la que se permite crear una instancia de TOR con características muy concretas y además, cada una de dichas instancias contará con su propio fichero de configuración de TOR (torrc).
Si se mira con atención el fichero de configuración anterior, se puede apreciar que se compone de una serie de instancias de la clase “Node” las cuales son “clonadas” utilizando un patrón “singleton” con el método “getN” en el que se indica el número de instancias que se debe crear. Finalmente, la utilidad “ConfigureNodes” se encarga de configurar todas y cada una de las referencias declaradas.

Configuración personalizada de Chutney

Hasta este punto se ha podido apreciar que configurar “chutney” no es demasiado complejo, sin embargo se ha utilizado una configuración que viene por defecto en el fichero “networks/basic”. Para hacer pruebas un poco más robustas y que posteriormente puedan servir para detectar errores en el funcionamiento de TOR, es necesario aprender a crear ficheros de configuración de red personalizados, algo que tampoco es demasiado complejo si se conocen las principales propiedades que se pueden utilizar en TOR.
En primer lugar, es importante anotar que el constructor de la clase “Node” recibe dos argumentos que identifican la configuración que se debe aplicar en la instancia de TOR, el primero es “tag”, el cual indica si se trata de un repetidor, un cliente, una autoridad de directorio o un bridge y el segundo es el parámetro “torrc”, el cual recibe un nombre de fichero con extensión “tmpl”, el cual representa una plantilla con las propiedades soportadas por TOR.
En el ejemplo anterior, el fichero “networks//basic” ha utilizado las plantillas “authority.tmpl”, “relay.tmpl” y “client.tmpl” y dichas plantillas se encuentran definidas en el directorio “<CHUTNEY_DIR>/templates/”. Para que el lector se haga una idea sobre lo que pueden incluir dichos ficheros, el siguiente es el contenido de la plantilla “authority.tmpl”

${include:relay.tmpl}
AuthoritativeDirectory 1
V3AuthoritativeDirectory 1
ContactInfo auth${nodenum}@test.test
ExitPolicy reject *:*
TestingV3AuthInitialVotingInterval 300
TestingV3AuthInitialVoteDelay 2
TestingV3AuthInitialDistDelay 2
TestingV3AuthVotingStartOffset 0
# Work around situations where the Exit and Guard flags aren’t being set
# These flags are set eventually, but it takes ~30 minutes
# We could be more precise here, but it’s easiest just to vote everything
# Clients are sensible enough to filter out Exits without any exit ports,
# and Guards without ORPorts
# If your tor doesn’t recognise TestingDirAuthVoteExit, update your chutney
# to a version that includes the issue-13161-check-torrc-options features
TestingDirAuthVoteExit *
TestingDirAuthVoteGuard *

Efectivamente, se trata de ficheros muy simples que siguen la misma sintaxis y estructura que el fichero de configuración “torrc”. La única diferencia es que los ficheros plantilla de “chutney” deben incluir una declaración al principio del fichero en el caso de que sea necesario incluir otras plantillas y además, es posible acceder a variables globales “chutney” con “${variable}” tal como se ha visto en el fichero.

Para probar cualquier tipo de configuración es necesario conocer muy bien las propiedades de configuración de TOR y jugar con ellas!
Chutney ya se encarga de crear el entorno por nosotros y emular la red de TOR en nuestro ordenador, con tantas instancias como queramos. Además, como se verá en un próximo artículo, también es posible utilizar Chutney en otras máquinas del segmento de red para tener una emulación mucho más aproximada del comportamiento de TOR, desde un entorno controlado y sin necesidad de estar conectado a Internet.

Herramientas como Chutney son muy utilizadas actualmente por hackers e investigadores con el fin de estudiar el comportamiento de TOR en un entorno aislado para que de esta forma, sea más sencillo encontrar fallos en su implementación sin afectar directamente a la red. Es una herramienta que desde luego es muy recomendada para aquellas personas que quieran probar diferentes configuraciones de TOR en su red local.

Saludos y Happy Hack!

Preservando el Anonimato y Extendiendo su Uso – Utilizando SSH y TOR juntos – Parte IX

octubre 28, 2011 7 comentarios

En la entrada anterior se ha explicado como se pueden crear servicios ocultos (hidden services) en la red de TOR, de forma tal que otros usuarios conectados a la red puedan acceder a dichos servicios sin que sea necesario revelar el origen real de la máquina donde se ejecuta dicho servicio, esto es en efecto un servicio oculto o expresado de un modo mas adecuado, un servicio anónimo. Todo esto se consigue principalmente a las claves publicas de dicho servicio que son “dominios” especiales con “.onion”, se puede crear toda clase de servicios, desde acceso a servidores web, hasta accesos a bases de datos, frecuentemente utilizando un proxy socks/http/https de por medio (a menos que sea un servidor web, en tal caso solamente es necesario tener un navegador web correctamente configurado tirando de la red de TOR) una solución a dicha implementación de proxy, puede ser simplemente el uso de SOCAT para ejecutar un relay de la conexión entrante desde un puerto determinado en la maquina local hacia el servicio remoto. Dado que SSH es el protocolo principal para acceso remoto y tareas de administración (entre muchas otras cosas) el uso de SSH en TOR será el enfoque principal de esta entrada.

Leer más…

Preservando el Anonimato y Extendiendo su Uso – Hidden Services en TOR – Parte VIII

octubre 26, 2011 2 comentarios

Una característica interesante en TOR es la capacidad de crear servicios “ocultos” entre los usuarios de la red, brindando así acceso a mensajería instantánea, servidores web, acceso a servicios de administración entre otros, todo esto sin dejar al descubierto la ubicación real de la máquina que presta el servicio. Para conseguir este nivel de anonimato, TOR emplea un formato de direcciones *.onion que permite que dichos servicios se encuentren disponibles de forma anónima por medio de la red TOR. Ahora, para dejar los conceptos claros, la mejor forma es enseñando con un ejemplo sobre cómo se pueden crear servicios a los que podrán acceder otros usuarios sin exponer la dirección IP de la máquina donde se encuentra en ejecución dicho servicio. En este caso concreto, se instalará Tomcat 7 como servidor web y posteriormente se publicará dicho servicio en TOR, para esto se siguen los siguientes pasos:

Leer más…

Preservando el Anonimato y Extendiendo su Uso – Relay y Bridges en TOR – Parte VII

octubre 24, 2011 Deja un comentario

BRIDGES EN TOR

En algunos casos, existen elementos “externos” que tratan de bloquear el acceso de un usuario a la red de TOR, con frecuencia es el ISP que presta el servicio de salida a internet el elemento “externo”, desde luego es una situación desagradable e injusta, ya que si pagas por una tener una conexión a internet, deberías tener derecho a navegar por donde te de la gana (considerando que no es poco lo que se paga hoy en día a un ISP para que solamente proporcione una dirección IP publica con salida a internet un par de servidores DNS con rendimientos precarios) por este motivo existen los “Bridges” en TOR, que son simplemente un conjunto de relays que no se encuentran en el directorio principal de relays de TOR, la diferencia entre un relay normal y un bridge solamente esta en que un relay aparecerá en el directorio publico, mientras que un bridge no aparece en el directorio publico y puede ser localizado única y exclusivamente desde el servicio automático de TOR dispuesto para tal fin, como se verá en el próximo aparatado sobre los mecanismos de localización de bridges.
Debido a que no existe una lista publica del total de relays que se ejecutan en la red de TOR, el ISP no podrá filtrar todos los relays ya que no dispone de la información completa de los que realmente se encuentran en ejecución, sin contar con que se trata de una red que evoluciona y crece constantemente.

Leer más…

Preservando el Anonimato y Extendiendo su Uso – Relay y Bridges en TOR – Parte VI

octubre 21, 2011 1 comentario

Es posible crear y configurar un relay desde Vidalia utilizando su interfaz gráfica, que como ya se explicado en la entrada anterior, consiste básicamente en establecer la maquina local como un nodo de salida en la red TOR, de esta forma se consiguen beneficios tales como mejor anonimato y mejor desempeño en la experiencia de usuario (navegación un poco mas rápida) además de la posibilidad de compartir y mejorar el poder de la red de TOR. Desde Vidalia se pueden indicar todos y cada uno de los atributos que se han indicado aquí, de hecho, lo que realmente se intenta hacer, es crear el fichero torrc al vuelo para establecer los valores que el usuario se encuentra ingresando, es un proceso muy sencillo el de crear correctamente un relay funcional, las siguientes son imágenes de cada uno de los pasos que se deben llevar a cabo para crear un relay TOR con Vidalia:

Leer más…

Preservando el Anonimato y Extendiendo su Uso – Relay y Bridges en TOR – Parte V

octubre 19, 2011 2 comentarios

TOR es un proyecto que además de brindar la posibilidad a sus usuarios de proteger sus datos personales, también tiene un enfoque social y colaborativo, cada usuario que participa en la red de TOR libremente puede configurar un relay en su servicio de TOR y actuar como un nodo de salida para otros usuarios que también navegan de forma anónima. La razón de esto es precisamente para asegurar de una forma más eficiente el anonimato de los usuarios, ya que entre mas nodos de salida existan, será mucho más difícil determinar el origen de las peticiones de los usuarios. Allí radica el valor de esta red y es una forma de contribuir con su desarrollo, además de esto, también ayuda a mejorar la experiencia de los usuarios, principalmente porque entre mas nodos de salida existan, mayor será el ancho de banda y el rendimiento será mucho mayor.

Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.119 seguidores

A %d blogueros les gusta esto: