Archivo

Posts Tagged ‘relays tor’

Creando sitios ocultos en TOR de forma programática con TxTorCon

diciembre 4, 2014 1 comentario

Anteriormente he hablado sobre el uso de Stem para controlar instancias de TOR, una potente librería que no solamente se aprovecha del protocolo de control de TOR para la administración remota de una instancia en ejecución, sino que también cuenta con algunas utilidades para arrancar una nueva instancia con configuración personalizada, descargar y parsear los descriptores emitidos por las autoridades de directorio, entre muchas otras funcionalidades útiles. Es una librería que se explota bastante bien en Tortazo, una de las herramientas que he escrito para realizar pruebas de penetración contra repetidores de salida y servicios ocultos en la red de TOR.
Aunque Stem es una librería muy potente, existen otras alternativas que cuentan con las mismas capacidades y en esta ocasión, voy a hablar sobre TXTORCON.

¿Por qué TxTorCon? Porqué se trata de una implementación del protocolo de control de TOR basada en Twisted y a diferencia de Stem, TxTorCon es una implementación asíncrona. Una librería como TxTorCon permitirá crear programas reactivos que se encargarán de ejecutar acciones sobre una o varias instancias de TOR ante una lista de eventos predefinidos.

En esta entrada se verá cómo se puede utilizar TxTorCon para crear servicios ocultos en TOR de forma programática y aunque lo que se verá a continuación también se puede hacer con Stem, se trata de un ejercicio practico muy interesante que servirá para conocer los elementos básicos y la “metodología” que se debe seguir cuando se programa con esta librería.

Antes de continuar, se recomienda al lector tener claros los conceptos básicos sobre la configuración de una instancia de TOR y conocer bastante bien las propiedades admitidas en el fichero “torrc”, aunque crear un servicio oculto no es una tarea compleja ya que solamente es necesario definir la opción de configuración “HiddenService” en el fichero de configuración “torrc” tantas veces como servicios ocultos se desee crear, lo que si que puede ser complicado es mantener el servicio oculto correctamente securizado, pero eso es un tema del que se hablará en un próximo artículo.

En primer lugar, es importante conocer el uso de la clase “txtorcon.TorConfig” ya que en dicha clase es donde definen todos los elementos de configuración de una instancia de TOR y dicho elemento puede ser utilizado para levantar la instancia de forma programática utilizando TxTorCon.

import txtorcon
config = txtorcon.TorConfig()
config.SOCKSPort = 9051
config.ORPort = 4443
…..
config.save()

La clase “txtorcon.TorConfig” maneja un diccionario interno con las propiedades que se pueden definir en un fichero de configuración de TOR, con lo cual el programador debe definir cada propiedad como un atributo de instancia.

Ahora bien, para definir uno o varios servicios ocultos, es necesario crear un listado de instancias de la clase “txtorcon.HiddenService”. Dicho listado se almacenará en la variable “HiddenServices” de la instancia de “txtorcon.TorConfig” creada previamente.
La siguiente función servirá para definir los detalles de configuración básicos para iniciar una instancia de TOR con un servicio oculto.

import txtorcon
import functools
import tempfile
import os
from twisted.internet import reactor 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating
a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not
exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,
hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),
serviceInterface, str(servicePort))] )]
    config.save()
    return config 

configuration('/home/adastra/Escritorio/django-hiddenservice',
'127.0.0.1')

La función “configuration” se encarga de recibir como argumento todos los elementos necesarios para establecer un servicio oculto en la configuración definida en el objeto “txtorcon.TorConfig” y posteriormente dicho objeto es retornado. Por otro lado, la función “createTemporal” es invocada internamente por la función “configuration” con el fin de devolver un directorio temporal para el servicio oculto en el caso de que el directorio indicado por parámetro sea invalido.

Ahora que la configuración se encuentra preparada, el siguiente paso consiste en utilizarla para iniciar la instancia de TOR en cuestión.

import txtorcon
import functools
import tempfile
import os
from twisted.internet import reactor 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),serviceInterface, str(servicePort))] )]
    config.save()
    return config 

def updates(prog, tag, summary):
    print "%d%%: %s" % (prog, summary) 

def setup_complete(config, proto):
    print "TOR Instance started!" 

def setup_failed(arg):
    print "SETUP FAILED", arg
    reactor.stop() 

def startTor(config):
    d = txtorcon.launch_tor(config, reactor,progress_updates=updates)
    d.addCallback(functools.partial(setup_complete, config))
    d.addErrback(setup_failed)
    reactor.run()
torrc = configuration('/home/adastra/Escritorio/hidden_service_django','127.0.0.1')
startTor(torrc)

En esta nueva versión del script se ha incorporado la función “startTor”, la cual se encarga de utilizar la configuración retornada por la función “configuration” para iniciar TOR. Como se puede apreciar, dicha función emplea la utilidad “txtorcon.launch_tor” enviando como argumentos, la configuración de TOR, el reactor de Twisted y una función de callback para procesar cada uno de los eventos producidos durante proceso de inicio. Finalmente, se adicionan dos funciones más en el caso de que el proceso de arranque haya ido bien o en el caso de fallo.

Después de ejecutar el script anterior, se podrá ver por consola algo muy similar a lo que se enseña en la siguiente imagen.

txtorcon1

El script puede parecer complejo pero tal como se ha explicado anteriormente, si se conoce el funcionamiento de Twisted y las funcionalidades básicas de TxTorCon, no resulta tan complicado de comprender.
Hasta este punto se asume que en la máquina local se encuentra un servicio levantado y esperando conexiones, más concretamente en el puerto “8080”. Evidentemente, dado el escenario anterior es necesario levantar un servidor web con Tomcat, una aplicación con Django o cualquier otro servicio en dicho puerto, pero dadas las características de Twisted, también es posible crear un servidor web simple directamente desde el script y de esta forma, se contará con una herramienta completamente funcional que puede levantar un servicio oculto sin depender de ningún programa externo (excepto el propio ejecutable de TOR).

import txtorcon
import functools
import tempfile
import os
from twisted.web import static, resource, server
from twisted.internet import reactor
from twisted.internet.endpoints import TCP4ServerEndpoint 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),serviceInterface, str(servicePort))] )]
    config.save()
    return config 

def updates(prog, tag, summary):
    print "%d%%: %s" % (prog, summary) 

def setup_complete(config, proto):
    print "TOR Instance started!" 

def setup_failed(arg):
    print "SETUP FAILED", arg
    reactor.stop() 

def startTor(config):
    #Starting a simple web site.
    root = static.File('/opt/WebSite')
    site = server.Site(root)
    hs_endpoint = TCP4ServerEndpoint(reactor, 8080,interface='127.0.0.1')
    hs_endpoint.listen(site)
    d = txtorcon.launch_tor(config, reactor,progress_updates=updates)
    d.addCallback(functools.partial(setup_complete, config))
    d.addErrback(setup_failed)
    reactor.run() 

torrc =configuration('/home/adastra/Escritorio/django-hiddenservice','127.0.0.1')
startTor(torrc)

El programa anterior solamente añade los elementos necesarios para declarar un servidor web cuyo directorio raíz es “/opt/WebSite”. Dicho servidor web se levantará en el puerto 8080 en la interfaz de red local, tal como se ha definido en la configuración del servicio oculto. Con todo esto, después de que la instancia de TOR se levante y se creen los ficheros correspondientes al dominio “onion” y a las claves del servicio, cualquier cliente que intente ingresar por dicha la dirección onion del servicio oculto, podrá ver los contenidos del servidor web que se ha iniciado utilizando Twisted. La siguiente imagen enseña algo muy similar a lo que el usuario final verá en su navegador.

txtorcon2

Como se puede apreciar, al acceder a la dirección onion del servicio oculto, se pueden visualizar los contenidos del directorio “/opt/WebSite”, que es el directorio que se ha indicado como raíz del servidor web.

Aunque aquí se ha enseñado como crear un servicio web en la red de TOR, también es posible crear cualquier otro tipo de servicio siguiendo exactamente la misma dinámica que se ha explicado aquí, como por ejemplo por un servidor SSH/SFTP con Paramiko, un servidor FTP o incluso un servidor SMB. Tienes a tu disposición muchas alternativas a la hora de automatizar la creación de servicios ocultos en la web profunda de TOR.

Un Saludo y Happy Hack!

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 – Monitoreando TOR con ARM– Parte XI

noviembre 2, 2011 Deja un comentario

ARM es una herramienta de linea de comandos que permite monitorizar el comportamiento y los eventos ocurridos en TOR, funcionando de una forma muy similar a como lo hace el comando “top” en distribuciones basadas en Linux. Esta aplicación se encuentra escrita en python y no necesita un proceso de construcción/compilación e instalación previo siendo muy sencillo su uso. Para descargar esta herramienta se puede utilizar “APT” en distribuciones basadas en Debian, o directamente el “tarball” desde aquí: http://www.atagar.com/arm/download.php posteriormente se puede utilizar el script “setup” para instalar ARM

Leer más…

Preservando el Anonimato y Extendiendo su Uso – TAILS, TOR Browser Bundle y Orbot – Parte X

octubre 31, 2011 1 comentario

Actualmente existen algunas distribuciones que soportan TOR y otras herramientas adicionales para utilizar desde un ordenador cualquiera, siendo principalmente distribuciones que pueden arrancar desde un LiveCD o desde un dispositivo USB.

TAILS (The Amnesic Incognito Live System)

Se trata de una distribución basada en Linux (concretamente en Debian Squeeze) que contiene una serie de herramientas enfocadas en proteger la identidad del usuario y sus datos personales sin importar la maquina que utilice. Entre las herramientas que incluyen se encuentra evidentemente TOR y Vidalia para administrar el servicio utilizando su interfaz gráfica.

Leer más…

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 3 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…

Seguir

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

Únete a otros 1.148 seguidores

A %d blogueros les gusta esto: