Archive for Anonimato

I2P-Bote: Correo seguro y anónimo

En artículos anteriores, vimos un sistema de correo electrónico, basado en el protocolo de BitCoin, que no tenía un servidor central (ServerLess). Este tipo de servicios, pretenden resolver problemas de ataques a un servidor centralizado, así como preservar la privacidad de sus usuarios. Para ello, todos los usuarios del servicio, forman una red y comparten su ancho de banda y almacenamiento.

Hoy voy a hablaros de un servicio similar que, además de preservar la privacidad, intenta preservar el anonimato. El concepto es similar al de Bitmessage, en el sentido de que no existe un servidor central. Sin embargo, aborda el problema de una forma muy diferente.

En primer lugar, utiliza la red I2P para garantizar el anonimato de sus usuarios. El alojamiento y distribución de correos se realiza mediante una modificación del protocolo P2P Kademlia, para permitir el borrado. Todos los usuarios se unen a una red de tipo Kademlia (¿os acordáis del eMule? Pues es una modificación del protocolo) y, cuando envían un correo, va a parar a esta red.

Read more

Bitmessage : 2º Parte

En el post anterior os hablé sobre Bitmessage. En éste, vamos a ver qué nos ofrece esta aplicación de correo electrónico distribuido.

En primer lugar, instalamos el cliente. Desde la web oficial, vemos que está disponible para Windows, Mac OS y, en el caso de Linux, tenemos el código fuente. Está escrito en Python. De hecho, el protocolo se llama Bitmessage y, el cliente, pybitmessage.

Una vez iniciamos la aplicación, nos pide si necesitamos configurar la red, o no es necesario. Esto es por si necesitamos indicar un proxy o similar.

Una vez iniciado, se conectará con la red y empezará a descargar la lista de mensajes, claves públicas, etc. Hay que recordar que su funcionamiento está inspirado en el protocolo de Bitcoin. Todos los mensajes pasan por todos los nodos y, la forma de saber si es nuestro o no, se basa en si tenemos la clave privada para descifrarlo.

Read more

Bitmessage

Una alternativa al correo electrónico tradicional, es Bitmessage. Es un protocolo inspirado en BitCoin, que pretende resolver el problema de la utilización de un servidor de correo por un lado y, por otro, la privacidad en la comunicación entre dos usuarios.

Nació en noviembre del 2012, con licencia MIT. Tras las denuncias de espionaje masivo efectuadas por Edward Snowden, en junio del 2013, su utilización se disparó, multiplicándose por cinco las descargas de este software.

La idea es la siguiente:

  • Creamos una red P2P anónima, que los usuarios van a utilizar para enviar sus mensajes.
  • Los usuarios van a poder crear diferentes identidades (desaparece el concepto de cuenta), que constará de una clave pública, con la que se cifrará el mensaje, y su correspondiente clave privada, para poder descifrarlo. Estas claves son compatibles con las utilizadas por BitCoin.
  • Los mensajes cifrados completamente (en el correo tradicional solo se cifra el mensaje y los archivos adjuntos), incluyendo emisor, receptor, asunto y, por supuesto, el mensaje, se copia a la red P2P, junto con los mensajes del resto de usuarios. Todos los mensajes pasarán por todos los clientes (nodos). El mecanismo para saber si un mensaje es nuestro o no, es sencillo: Si podemos descifrarlo, el mensaje es nuestro.
  • Los mensajes se almacenan cifrados en los nodos que componen la red P2P.

Read more

Convirtiendo un Proxy en Transparent Proxy

En algunas ocasiones queremos utilizar de manera transparente un servidor proxy, ya sea para saltar un firewall o, simplemente, para enrutar por él determinadas conexiones o las conexiones de determinados usuarios o grupos. Pero no siempre es posible, porque no todos contemplan la posibilidad de Transparent Proxy.

Si utilizamos Privoxy con la opción accept-intercepted-requests, nos sirve para redirigir el tráfico vía firewall. Sin embargo, no podremos redirigir el tráfico https. Además, una vez que activemos la opción accept-intercepted-requests, no podremos utilizarlo manualmente desde la aplicación deseada.

También se puede utilizar un proxy Socks5 creado con ssh. A él no podremos redirigir el tráfico directamente vía firewall.

Si queremos redirigir el tráfico con nuestro firewall a un proxy como los anteriores, podemos utilizar RedSocks. Esta herramienta nos permite crear un proxy transparente http, http-connect, socks4 o socks5 y actuará de túnel con el proxy real. De esta manera, podremos “convertir” un proxy que no es Trasnparent Proxy, en uno, y dirigir a él el tráfico que necesitemos.

Una ventaja adicional es que puede enrutar también el tráfico DNS. Si disponemos un proxy Socks5, que no sea creado con ssh, también podremos redirigir por él el tráfico UDP.

Vamos a ver un ejemplo de uso. Para ello, vamos a enviar todo el tráfico http y https a Privoxy.

Privoxy, en principio, enrutará todo el tráfico a través de TOR. La ventaja de pasar previamente por Privoxy es poder aprovechar los filtrados que proporciona, como publicidad, etc., además de poder decidir desde él qué hacer con cada URL. El resto del tráfico, lo enrutaremos por TOR. Todo esto se realizará siempre que la aplicación/herramienta se haya lanzado con un grupo de usuarios concreto.

Nos va a permitir utilizar estos proxys sólo cuando la aplicación se lance con un determinado grupo, de manera que no vamos a “Torificar” todas las salidas, solo aquellas que nos interesan.

La instalación la vamos a realizar sobre Kali. En el resto de distribuciones basadas en Debian será similar. En ArchLinux, podemos encontrar Redsocks en el AUR o, si hemos añadido a los repositorios BlackArch, lo tendremos ya disponible, dado que forma parte de esta distribución.

Empezamos instalando:

apt-get update && apt-get install redsocks privoxy tor

Una vez instalados los paquetes, vamos a configurarlos. Primero, editamos el fichero /etc/tor/torrc. Necesitaremos mapear los dominios onion, activar el servicio de DNS de TOR y el TProxy. Para ello, al final del archivo añadimos:

VirtualAddrNetwork 10.192.0.0/10
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion

DNSPort 53
TransPort 9040
SocksPort 9050

Con esto tenemos que, el servidor de DNS estará escuchado en localhost:53, los dominios onion los mapeará con una ip aleatoria del rango 10.192.0.0/10 y tendremos el TProxy en el 9040, además del proxy socks habitual en el 9050.

Ahora vamos a editar la configuración de Privoxy y añadir al final de la misma:

forward-socks5 / 127.0.0.1:9050 .
forward localhost/ .
forward 127.*.*.*/ .
forward 192.168.*.*/ .

Bien, ya tenemos Tor y Privoxy configurados, pasemos a RedSocks. Primero sacamos un backup del fichero /etc/redsocks.conf. En él tenemos todas las opciones disponibles, con sus respectivos comentarios. Hecho esto, lo editamos y le añadimos el siguiente contenido:

base {
 log_debug = off;
 log_info = on;
 log = "syslog:daemon";
 daemon = on;
 user = redsocks;
 group = redsocks;
 redirector = iptables;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8218;

ip = 127.0.0.1;
 port = 8118;


 // known types: socks4, socks5, http-connect, http-relay
 type = http-relay;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8318;

ip = 127.0.0.1;
 port = 8118;

type = http-connect;
}

Básicamente, hemos creado un TProxy en el puerto 8218 que apunta al 8118 (Privoxy), de tipo http-relay y otro en el 8312, de tipo http-connect (https), que también apunta a Privoxy.

Ya tenemos la configuración inicial, vamos a arrancar los servicios:

systemctl start tor privoxy redsocks

Ahora vamos a añadir un grupo. Será el que utilicemos para enrutar de manera transparente sus conexiones:

groupadd socksified

Hecho esto, añadimos los usuarios que necesitemos al grupo:

usermod --append --groups socksified USUARIO

Con esto ya tenemos casi todo lo necesario. Toca configurar el firewall. Editamos/creamos el fichero /etc/network/iptables.rules y añadimos lo siguiente:

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:REDSOCKS - [0:0]

# Los DNS se los dejamos a TOR
-A OUTPUT -p tcp --dport 53 -j REDIRECT --to-ports 53
-A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 53

# El grupo socksified se redirige a REDSOCKS
-A OUTPUT -p tcp -m owner --gid-owner "socksified" -j REDSOCKS

## Redes internas
-A REDSOCKS -d 0.0.0.0/8 -j RETURN

# Usamos parte de 10.0.0.0/8 para onion, entonces:
-A REDSOCKS -d 10.0.0.0/9 -j RETURN
-A REDSOCKS -d 10.128.0.0/10 -j RETURN

-A REDSOCKS -d 127.0.0.0/8 -j RETURN
-A REDSOCKS -d 169.254.0.0/16 -j RETURN
-A REDSOCKS -d 172.16.0.0/12 -j RETURN
-A REDSOCKS -d 192.168.0.0/16 -j RETURN
-A REDSOCKS -d 224.0.0.0/4 -j RETURN
-A REDSOCKS -d 240.0.0.0/4 -j RETURN

## Redirecciones
# Privoxy, peticiones http
-A REDSOCKS -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8218

#Privoxy, peticiones "Connect" (https)
-A REDSOCKS -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8318

#Direcciones onion
-A REDSOCKS -d 10.192.0.0/10 -p tcp -j REDIRECT --to-ports 9040

COMMIT

Una vez tenemos las reglas, ejecutamos:

iptables-restore < /etc/network/iptables.rules

Y ya solo nos queda probar si todo es correcto:

# No sale por privoxy
curl https://check.torproject.org | grep -i congra
#ahora, como lanzamos curl con el grupo socksified, sí que lo hace
 sg socksified 'curl https://check.torproject.org |grep -i congratulation'

Como puede observarse, este mecanismo nos puede ser muy útil para dirigir el tráfico a uno u otro proxy, dependiendo, por ejemplo, del grupo con el que se lance la aplicación. También podría hacerse por usuarios. Además, podemos añadir tantas secciones Redsocks como necesitemos, permitiéndonos “jugar” bastante con nuestro sistema, para adecuarlo correctamente a nuestras necesidades.

¡¡Espero que os haya gustado !!

Anonimizando la Kali con anonym8

En determinadas ocasiones, necesitamos utilizar nuestra máquina de auditorías de manera anónima. La mayor parte de herramientas cuentan con una opción para configurar un proxy, ya sea http o sock, con lo que puede configurarse para utilizar TOR.

Sin embargo, no todas tienen esta característica, con lo que nos vemos obligados a utilizar herramientas adicionales como proxychains. Además, en muchas ocasiones queremos también comprobar el tráfico UDP, y esto no es posible hacerlo con TOR.

También es posible que queramos suplantar la MAC de la tarjeta de red, cambiar el nombre del host, no tener fugas de DNSs y, una vez terminada la auditoría, dejar todo como estaba, eliminando, por supuesto, los rastros que hayamos dejado en SWAP, cachés, etc.

privacy

Bien, para hacer todo esto, disponemos de un script que nos va a facilitar todo el trabajo. Lo podéis encontrar en https://github.com/HiroshiManRise/anonym8, y es válido para distribuciones basadas en Debian, por ejemplo, Kali.

Read more

¿TOR? ¡ No en mi servidor !

Sin duda las redes TOR han adquirido un protagonismo considerable en estos últimos años. Ya debemos saber que no siempre TOR, se usa para realizar actos delictivos sino también para evadir censuras en países autoritarios y dónde la democracia y libertad de expresión es un lujo escaso.

No obstante, nosotros siempre nos centramos en las posibilidades que puedan dar las redes TOR, tanto ofensivamente como defensivamente.

Hoy toca ser defensivos, y vamos a ver como poder parar de forma simple, visitas desde redes TOR a un servicio apache nuestro, publicado en Internet. Las reglas pararán cualquier intento de conexión pero utilizaremos apache como sonda de prueba.

La idea me surgió hace tiempo pero hoy he podido plasmarla en el artículo. Y es que entrando en pequeños debates de como mejorar servicios de Firewalls conocidos, con un gran profesional al que aprovecho y le mando saludos, me propuse hacer algo básico para trasladar mi idea y/o ponerla en práctica.

Empecemos pues.

La idea: No permitir accesos desde redes TOR a nuestro servidor y de paso, bloquear IPs que hayan sido reportadas o estén listadas en repositorios dedicados a recopilar esto.

¿Qué vamos a usar?

  • IPTables
  • IPSet
  • Feeds de IPs/Maliciosas y TOR
  • Script base de trick77(Github: https://github.com/trick77/ipset-blacklist)

torblocklogo Read more