Preservando el Anonimato y Extendiendo su Uso – GARLICAT en I2P – Parte XXIX

Anteriormente se ha mencionado el uso de OnionCat y como era posible acceder a Hidden Services TOR utilizando esta herramienta de forma segura y brindando magnificas facilidades a la hora de transmitir cualquier tipo de paquete IP de forma transparente en la capa de transporte soportado por redes como TOR o I2P. Como se ha mencionado anteriormente OnionCat es una red VPN point-to-multipoint entre servicios existentes en las capas superiores (transporte, sesión, aplicación) como cualquier VPN se encarga de facilitar las cosas a la capa de transporte, es decir, que esta normalmente se encuentra instanciada desde la capa de enlace y facilita la comunicación entre enlace y transporte, para que posteriormente los paquetes IP viajen a las demás capas de forma correcta. Para mayor información sobre el funcionamiento de OnionCat ver la entrada anterior de este Blog que habla sobre este tema en: http://thehackerway.com/2011/11/14/preservando-el-anonimato-y-extendiendo-su-uso-%E2%80%93-utilizando-onioncat-para-simplificar-el-acceso-a-hidden-services-%E2%80%93-parte-xvi/

No obstante, cual es el beneficio real de tener un software como OnionCat sirviendo de intermediario entre la capa de enlace y la capa de trasporte? La respuesta es simple, facilitar el uso de Hidden Services (en el caso de TOR) y mitigar algunas restricciones que se encuentran asociadas al uso de algunos protocolos de comunicación (por ejemplo UDP) dado que OnionCat construye una VPN transparente para manejar cualquier tipo de paquete IP sin alterar la funcionalidad de los servicios y sin afectar su anonimato, en el caso concreto de TOR, es altamente beneficioso para mitigar problemas tan frecuentes y tan “nefastos” para el anonimato como los conocidos DNS Leaks. Este el principal beneficio de OnionCat, no obstante el uso de OC esta relacionado de forma directa con TOR, específicamente con sus Hidden Services, dado que esta herramienta ha sido construida inicialmente con TOR en mente y no se tenia planteado dar soporte a otras redes como I2P, no fue sino hasta noviembre del 2009 cuando surgió GarliCat para I2P.

GarliCat se basa en el mismo concepto de OnionCat, de hecho comparten el mismo código fuente báse, solamente que GarliCat permite utilizar direcciones I2P para acceder a servicios anónimos dentro de la red I2P, es decir, del mismo modo que OnionCat funciona con servicios TOR *.onion, GarliCat es valido para direcciones b32.i2p

A continuación se procede a explicar el funcionamiento de GarliCat, se asume que ya se tiene instalado y correctamente configurado OnionCat tal como se menciona en la publicación que anteriormente se ha indicado.

CONFIGURACIÓN DE I2P Y GARLICAT

En primer lugar, para que I2P y GarliCat puedan ser integrados en un entorno de red virtual, es necesario un túnel en I2P servidor y un túnel cliente. El túnel servidor es evidentemente el receptor en el proceso de comunicación, mientras que el cliente representa al emisor. La creación de estos túneles se ha indicado en una entrada anterior sobre el uso de I2P para crear túneles SOCKS y acceder a servicios SSH, como se recordará, dichos túneles tienen una clave en base32 que es generada automáticamente por I2P. Esta clave será el punto de acceso de Garlicat para que este pueda traducir de forma directa esta clave en una dirección IPv6 valida y única.

Ahora bien, los pasos para hacer esto son realmente sencillos y no se necesitan conocimientos demasiado profundos, no obstante es necesario comprender los conceptos teóricos y la razón por la cual se utiliza OnionCat/GarliCat si esto no se comprende aún, se recomienda volver a leer las lineas anteriores y la publicación relacionada con este tema.

1. Es necesario crear el túnel servidor, para ello se utiliza la aplicación I2PTunnel la cual se ha mencionado en repetidas ocasiones en entradas anteriores y se encuentra ubicada en: http://127.0.0.1:7657/i2ptunnel/. Una vez allí se procede a crear un túnel del tipo “Standard” tal como se enseña en la imagen:

   Esto abrirá un formulario donde se deberán ingresar todos los datos relacionados con el nuevo túnel, la siguiente imagen enseña los campos requeridos que deben ingresarse, los demás valores del túnel pueden dejarse como están, a menos que se desee controlar alguna característica particular sobre la creación del túnel.
   Finalmente, se verá por la consola de mensajes de I2PTunnel, los mensajes relacionados con la creación del nuevo túnel, así como también se indica la clave del servicio.
   El siguiente paso sería desde el punto de vista del cliente, consiste en la creación de un túnel cliente del tipo SOCKS, los pasos para hacer esto ya se han indicado en una entrada anterior y pueden repasarse aquí: http://thehackerway.com/2011/12/07/preservando-el-anonimato-y-extendiendo-su-uso-servicios-anonimos-eepsites-y-ssh-en-i2p-parte-xxvi/ El puerto para el túnel SOCKS debe ser el 9051 sin embargo se puede especificar cualquiera, siempre y cuando el puerto indicado posteriormente sea especificado en la ejecución del comando gcat con la opción -t.

3. Ahora que se ha creado el túnel de servidor, es necesario obtener su identificador clave garlicat, el cual esta compuesto por los 16 primeros caracteres de la dirección en Base32 que ha generado I2P para dicho túnel y se adicionan el dominio “oc.b32.i2p”, de este modo si por ejemplo I2P ha generado la siguiente dirección para el túnel en Base 32: d6aysvh2345sjrktgucwgneuip6tgsdmimzro2xvnyyzxdgvff6b.b32.i2p El identificador clave garlicat será:

   d6aysvh2345sjrkt.oc.b32.i2p

   Este identificador es importante, ya que será utilizado por GarliCat para arrancar y generar una dirección IPv6 valida.

4. Ahora es el momento de ejecutar Garlicat, para ello se cuenta con la utilidad gcat la cual contiene básicamente las mismas opciones que ocat

   >gcat onioncat 0.2.2.r553 (c) Bernhard R. Fischer (GarliCat mode) usage: gcat [OPTIONS] <onion_hostname> -a create connect log at «$HOME/.ocat/gcat_connect_log» (default = 0) -b daemonize (default = 1) -B do not daemonize (default = 0) -h display usage message -H ignore /etc/hosts while in GarliCat mode -C disable local controller interface -d <n> set debug level to n, default = 7 -f <config_file> read config from config_file (default = /usr/local/etc/gcat.conf) -i convert onion hostname to IPv6 and exit -I GarliCat mode, use I2P instead of Tor -l [<ip>:]<port> set ocat listen address and port, default = 127.0.0.1:8061 -L <log_file> log output to <log_file> (default = stderr) -o <ipv6_addr> convert IPv6 address to onion url and exit -p use TAP device instead of TUN -P [<pid_file>] create pid file at location of <pid_file> (default = /var/run/gcat.pid) -r run as root, i.e. do not change uid/gid -R generate a random local onion URL -s <port> set hidden service virtual port, default = 8061 -t [<ip>:]<port> set Tor SOCKS address and port, default = 127.0.0.1:9051 -T <tun_device> path to tun character device, default = «/dev/net/tun» -u <user> change UID to user, default = «tor» -4 enable IPv4 support (default = 0)

   Como se aprecia, son las mismas opciones que ocat soporta, ya que como se ha mencionado anteriormente, el código base fuente es esencialmente el mismo, solamente que “gcat” esta adaptado para ejecutarse con redes I2P.

5. Verificar que GarliCat es capaz de convertir el identificador clave garlicat en una dirección IPv6 valida, para ello se ejecuta el siguiente comando:

   >gcat -i d6aysvh2s45sjrkt.oc.b32.i2p fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553

   Si el comando anterior retorna una dirección IPv6 indica que se puede arrancar sin problemas

   >gcat -B -u adastra d6aysvh2s45sjrkt.oc.b32.i2p

   Con lo anterior se ha tenido que generar una interfaz virtual valida, se procede a verificarlo y si es así, a levantarla.

   >ifconfig tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet6 addr: fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553/48 Scope:Global UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

6. Probar que es posible acceder a la máquina realizando un ping a la dirección IPv6 del siguiente modo

   >ping6 fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553 PING fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553(fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553) 56 data bytes 64 bytes from fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553: icmp_seq=1 ttl=64 time=0.038 ms 64 bytes from fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553: icmp_seq=2 ttl=64 time=0.046 ms 64 bytes from fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553: icmp_seq=3 ttl=64 time=0.040 ms ^C — fd60:db4d:ddb5:3f81:8954:fa97:3b24:c553 ping statistics — 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.038/0.041/0.046/0.006 ms

   Dado que existe respuesta por parte del servidor se puede asumir que Garlicat esta funcionando de forma correcta y ahora es posible que un cliente pueda realizar conexiones utilizando el túnel cliente creado anteriormente (Túnel tipo SOCKS)

Si se intenta realizar una conexión con otro GarlicCat que se encuentra en una máquina remota, es necesario que dicho nodo se encuentre registrado en el servicio de nombrado local, para ello, normalmente se utiliza SusiDNS desde el AddressBook Master, donde se debe ingresar el “HostName” y el “Destination” por lo tanto es necesario tener dichas referencias para poder contactar con dichos nodos, es en este punto donde se utiliza el túnel SOCKS creado anteriormente.

Por otro lado, puede seguirse el siguiente foro: http://zzz.i2p/topics/423 algunos usuarios han puesto sus direcciones para que otros puedan probar GarliCat, sin embargo estos hosts en ocasiones no se encuentran levantados, si se desea probar el acceso remoto, se deben seguir estos mismos pasos en una máquina distinta y que pertenezca a un segmento de red distinto, o bien contactar conmigo por medio de mi dirección de correo adastra@mail.i2p