Archive

Posts Tagged ‘directorio autoridad tor’

Instalación de un proxy TOR2WEB para acceder a servicios ocultos desde Internet

enero 22, 2015 1 comentario

Seguramente muchos de los que leéis este blog y os interesan temas relacionados con el anonimato, TOR y cosas similares, conocéis el proyecto “TOR2WEB”, pero para los que no, basta con decir que es una plataforma creada por el equipo de TOR que permite que los servicios ocultos que se publican internamente en la web profunda de TOR se encuentren disponibles desde Internet sin necesidad de que el cliente tenga que arrancar una instancia de TOR en su máquina. Esto quiere decir que cualquier usuario corriente en internet, utilizando cualquier navegador web, podrá acceder a un servicio oculto muy fácilmente.

TOR2WEB está diseñado para funcionar como un proxy reverso, que solamente se encarga de enrutar todas las peticiones entrantes desde la “clear web” a la “deep web” de TOR, con lo cual los servicios ocultos siguen siendo ocultos, incluso para un proxy TOR2WEB. No obstante, el cliente que visita dichos contenidos no lo es, a menos claro, que utilice TOR para acceder a dicho proxy algo que que no tiene mucho sentido, ya que al utilizar TOR ya se tiene acceso a la web profunda de TOR y realmente no seria necesario utilizar TOR2WEB.

“tor2web.org” está conformado por voluntarios en todo el mundo que configuran y exponen un servicio de TOR2WEB para que cualquier usuario en Internet pueda utilizarlo. Dado que se trata de un proxy, no almacena los contenidos de los sitios ocultos, simplemente se encarga de enrutar las peticiones entre la web profunda de TOR y la “web clara”.

Acceder a un servicio oculto en la web profunda de TOR es simple, solamente hace falta sustituir la cadena “.onion” de la dirección del servicio oculto por “.tor2web.org”.

Por ejemplo, si la dirección onion de un servicio oculto es la siguiente: “ajio7mfsscpvgd23.onion” la dirección que se debe utilizar para acceder a dicho servicio utilizando TOR2WEB es: “ajio7mfsscpvgd23.tor2web.org”.

Lo primero que verá el usuario cuando navega hacia dicho sitio es una nota legal que indica que TOR2WEB es solamente un servicio de proxy que tira de la web profunda de TOR y que los contenidos que el usuario visualizará son responsabilidad del creador del servicio oculto al que se intenta acceder. Si el usuario está de acuerdo con los términos expuestos por el proxy, puede continuar y acceder a los contenidos del servicio oculto. La siguiente imagen enseña enseña dicha advertencia.

tor2web1

 

Por otro lado, la plataforma también almacena unas estadísticas básicas sobre el número de accesos que ha tenido el servicio oculto el día anterior, por cuestiones de privacidad y para no generar registros sobre el uso de un servicio oculto, solamente se pueden ver las estadísticas del día anterior y no se almacena nada sobre los datos de otros días. Para acceder a dicha información basta con entrar a la uri “/antanistaticmap/stats/yesterday”. Por ejemplo: “ajio7mfsscpvgd23.tor2web.org/antanistaticmap/stats/yesterday”.
Como se ha mencionado anteriormente, TOR2WEB es un servicio que se encuentra soportado por varios voluntarios en Internet, los cuales configuran una instancia del proxy de TOR2WEB con un dominio propio o con el dominio de TOR2WEB.

Aunque el procedimiento de instalación de un nodo de TOR2WEB es una tarea que se encuentra documentada y bastante bien explicada en la documentación oficial del proyecto, en este artículo explicaré en detalle cómo se puede instalar, configurar y arrancar un nodo de TOR2WEB.

Instalación y configuración de un nodo de TOR2WEB

Antes que nada, el proyecto se encuentra alojado en la siguiente URL: https://github.com/globaleaks/Tor2web-3.0 y se recomienda navegar un poco por cada una de las secciones de la documentación para tener una idea más global del funcionamiento de Tor2Web. En primer lugar es necesario instalar el proyecto y dado que se encuentra pensado principalmente para plataformas basadas en Debian, el mecanismo de instalación consiste adicionar un repositorio a la lista del sistema y posteriormente ejecutar el comando “apt-get” o “aptitute”. Existe un script de instalación que se encarga de realizar todas estas tareas de forma automática y que se recomienda utilizar.

>wget https://raw.githubusercontent.com/globaleaks/Tor2web-3.0/master/scripts/install.sh

>chmod +x install.sh

>./install.sh

Cuando se ejecuta el script pide permisos de administrador para instalar el programa utilizando “apt-get”. Después de realizar la instalación, automáticamente se crea el directorio “/home/tor2web/certs” que es donde se deberán crear los certificados y las claves para el proxy.
Se deben ejecutar los siguientes comandos dentro de dicho directorio.

>openssl genrsa -out tor2web-key.pem 4096

>openssl req -new -key tor2web-key.pem -out tor2web-csr.pem

>openssl x509 -req -days 365 -in tor2web-csr.pem -signkey tor2web-key.pem -out tor2web-intermediate.pem

>openssl dhparam -out tor2web-dh.pem 2048

 

Con los pasos anteriores se encuentra casi terminada la instalación, sin embargo antes de poder arrancar el servicio, es necesario crear un fichero de configuración en “/etc/tor2web.conf”. Dicho fichero no existe por defecto, pero después de instalar Tor2Web, se crea automáticamente un fichero de configuración que sirve de ejemplo en “/etc/tor2web.conf.example”. Las propiedades de configuración que incluye el fichero permiten activar o desactivar varias características interesantes de TOR2WEB, sin embargo, las siguientes son las mínimas que se deben de incluir en el fichero de configuración antes de iniciar el servicio.

nodename: Identificador único del servicio. Es bastante útil para identificar las trazas que se envían a los administradores de TOR2WEB.

datadir: Directorio donde se encuentran los ficheros necesarios para el correcto funcionamiento del programa, incluyendo los certificados creados anteriormente.

processes y requests_per_process: Propiedades que permiten ejecutar el programa utilizando multiproceso. El valor recomendado para la propiedad “processes” es el número de cores del sistema +1.

basehost: Se trata del dominio base donde se ejecutará el proxy. TOR2WEB se puede desplegar en un dominio independiente al de tor2web y en tal caso, es necesario especificar dicho dominio en esta propiedad.

listen_port_http y listen_port_https: Puertos HTTP y HTTPS que serán utilizados por el proxy. Evidentemente los valores por defecto son 80 y 443 respectivamente.

sockshost y socksport: Son probablemente las propiedades más importantes, ya que permiten definir el host y el puerto en el que se encuentra en ejecución un proxy SOCKS de TOR. Es evidente la importancia de dichos valores, ya que TOR2WEB utilizará dicho proxy SOCKS para conectarse con la web profunda de TOR y devolver al usuario final los contenidos del servicio oculto que ha solicitado. En este sentido, para lanzar un nodo de TOR2WEB, es necesario tener una instancia de TOR levantada.

ssl_key, ssl_cert y ssl_dh: Se trata de propiedades que permiten especificar la ruta completa de los certificados y la clave privada que se han creado anteriormente para el servicio.

Con las propiedades anteriores se puede comenzar a utilizar TOR2WEB, sin embargo existen otras propiedades que habilitan características especiales del programa, por ejemplo la posibilidad de bloquear servicios ocultos con contenidos inapropiados, bloquear crawlers, sobre-escribir el fichero “robots.txt” y otras cosas que intentan “alejar” el contenido de servicios ocultos de buscadores como google.

Para conocer en mayor detalle todas las opciones de configuración disponibles, se recomienda revisar la documentación en la siguiente sección. https://github.com/globaleaks/Tor2web-3.0/wiki/Configuration-Guide
Para iniciar un nodo de TOR2WEB con la configuración mínima, se puede utilizar el siguiente fichero

[main]
nodename = AdastraTORY
datadir = /home/tor2web
processes = 5
requests_per_process = 100000
listen_port_http = 80
listen_port_https = 443
basehost = tor2web.org
sockshost = 127.0.0.1
socksport = 9150
ssl_key = /home/tor2web/certs/tor2web-key.pem
ssl_cert = /home/tor2web/certs/tor2web-intermediate.pem
ssl_dh = /home/tor2web/certs/tor2web-dh.pem
cipher_list = ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DES-CBC3-SHA
ssl_tofu_cache_size = 100

 

Con el fichero anterior ubicado en “/etc/tor2web.conf” ahora es posible iniciar el servicio como cualquier otro del sistema

>sudo /etc/init.d/tor2web start
Enabling Tor2web Apparmor Sandboxing
* Starting Tor2web tor2web…
* Starting tor daemon… [ OK ]
>

Con los pasos anteriores, ahora ya contamos con una instancia en ejecución de TOR2WEB en local y disponible para desplegar en algún servidor en Internet.

Saludos y Happy Hack!
Adastra.

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

noviembre 20, 2014 5 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 dúplica 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!

Hacking con Python Parte 25 – Atacando Repetidores de Salida de TOR

julio 22, 2014 1 comentario

Script que utiliza STEM, Python-Nmap y Shodan para atacar los repetidores que se encuentran registrados en los descriptores publicados por las autoridades de directorio.
Se trata de una versión inicial, que modificaré y extenderé en los proximos días.
Publicaré un post para explicar en que consistiran las caracteristicas que quiero implementar y como utilizarlo.

attackTor: https://github.com/Adastra-thw/pyHacks/blob/master/attackTOR.py

Repositorio GIT de la serie:
https://github.com/Adastra-thw/pyHacks.git


Make a Donation Button

Hacking con Python Parte 24 – Consulta de descriptores de TOR con Stem

julio 15, 2014 1 comentario

Conceptos basicos sobre los descriptores de TOR utilizando la API de STEM.

Repositorio GIT de la serie:
https://github.com/Adastra-thw/pyHacks.git


Make a Donation Button

Hacking con Python Parte 23 – Controlando instancias de TOR con Stem

julio 8, 2014 2 comentarios

Utilizando la API de Stem para acceder a repetidores locales de TOR.

Repositorio GIT para la serie:
https://github.com/Adastra-thw/pyHacks.git


Make a Donation Button

TORTAZO para auditar nodos de salida de TOR

marzo 5, 2014 5 comentarios

Hace algunos meses he comenzado a jugar con Stem para TOR (https://stem.torproject.org/ ) y claro, ya que se trata de una librería muy completa y que permite extraer casi cualquier tipo de información sobre los repetidores conectados en la red de TOR, una cosa llevo a la otra y al final he terminado creando TORTAZO.

Se trata de una herramienta que aun se encuentra en estado de desarrollo y que de momento tiene las siguientes características:

  • Permite extraer información de los Server Descriptors del último consenso emitido por las autoridades de directorio y filtrar por sistema operativo y número de repetidores máximo a recuperar.
  • Realiza un escaneo inicial contra los nodos encontrados utilizando Nmap y genera un fichero de texto con los puertos abiertos para cada una de las máquinas encontradas.
  • En el caso de que tengamos el fingerprint del nodo de salida que queremos auditar, podemos realizar la extracción de información y posterior análisis utilizando como filtro ese fingerprint
  • Después de realizar el escaneo con Nmap, opcionalmente Tortazo puede buscar en Shodan cualquier información adicional sobre el nodo de salida.
  • Opcionalmente, permite realizar ataques por diccionario contra servidores SSH y FTP. En tal caso, admite como argumento un diccionario conformado por pares de usuarios y claves. Si no se especifica un fichero de diccionario, Tortazo utilizará algunos de los ficheros de usuarios y passwords existentes en el proyecto FuzzDB (para la primera versión de Tortazo, utiliza la versión 1.09 de FuzzDB que es la última disponible). Este proceso, como todos los ataques de “bruteforcing”, es muy ruidoso y puede llevar mucho tiempo en ejecutarse.
  • En el caso de que se consiga acceso a un servidor SSH, se actualiza el fichero tortazo_botnet.bot el cual contiene en cada linea, el host, usuario y contraseña. Esta información luego es utilizada para ejecutar comandos de forma paralela sobre todos los servidores SSH definidos en dicho fichero o solamente sobre un conjunto determinado.

Esto es un resumen de las características que he incluido en la primera versión de está herramienta, sin embargo, mi imaginación tiende a volar y constantemente se me van ocurriendo cosas que me gustaría hacer. Para las nuevas versiones que comenzaré a desarrollar desde mañana (en mis ratos libres, porque desafortunada o afortunadamente, según se mire, tengo que currar) incluiré las siguientes funcionalidades:

  • Integración de herramientas como Nessus, OpenVAS y Metasploit
  • Generar informes un poco más “profesionales” que simplemente ficheros de texto
  • Incluir las nuevas características de la API de Shodan.
  • Recolectar información sobre dispositivos con SNMP y detectar aquellos que tienen nombres de comunidades por defecto.
  • Implementar un sistema de plugins que le permita a otras personas integrar sus rutinas de código en Tortazo.
  • Implementar funciones para GeoLocalización de los servidores encontrados (usando varias bases de datos de GEOLocalización).
  • Analizar más protocolos… (HTTP/HTTPS, SMTP, POP, NNTP, NTP, SMB). El cielo es el limite 😛

Creo que la versión 1.1 será la que realmente le empezará a dar forma a Tortazo, el tiempo lo dirá, pero de momento la primera versión servirá como base para desarrollar las demás características que se me vayan ocurriendo.

Si te parece interesante lo que te estoy contando y quieres saber un poco más, he incluido más detalles en el fichero README del proyecto, el cual se encuentra en el repositorio GitHub: https://github.com/Adastra-thw/Tortazo
Si quieres colaborar en el desarrollo, ya sea con código o con ideas que puedan implementarse, estoy abierto a sugerencias 🙂

 Un Saludo y Happy Hack!

Preservando el Anonimato y Extendiendo su Uso – Funcionamiento de los Directorios Autoritativos y de Cache en TOR – Parte XXI

noviembre 25, 2011 2 comentarios

Como se ha mencionado anteriormente en estas entradas, el directorio de TOR almacena información sobre nodos disponibles en la red y cada nodo puede tener el suyo propio con el fin de descentralizar aun más este servicio, dado que cada nodo tiene una copia de esta información y la cachea de forma automática en su estructura interna. La razón por la cual se utilizan estos elementos en la red de TOR ha sido principalmente porque en las primeras versiones, cada cliente tenia conocimiento de los routers que componían los circuitos entre él y sus correspondientes destinos, disponía de un listado de routers que eran confiables (algo que no siempre podría ser cierto) y conocía las claves de cada uno, sin embargo, dada la naturaleza cambiante de la red, este listado se encontraba rápidamente desactualizado, conteniendo nodos que posiblemente ya no se encontraban disponibles o que sus correspondientes claves publicas habían cambiado (un poco menos frecuente, pero también podía ocurrir), lo que obligaba al cliente a realizar una nueva lista con bastante frecuencia. Para ello en TOR se han creado los directorios Autoritativos que contienen el estado actualizado de routers confiables y sus correspondientes estados. A continuación se indican los conceptos teóricos/funcionales y las opciones de configuración.

Leer más…

A %d blogueros les gusta esto: