viernes, septiembre 27, 2013

Conéctate a TOR con tu propio nodo y sin Internet "normal"

Anoche en la fiesta de speakers de Ekoparty tuvimos una buena charla durante un buen rato donde acabamos contándonos esas historias de no dormir que han pasado a uno u a otro hacker en algún momento. Cosas de esas que asustan un poco si te dedicas a esto que nos tocó por pasión. Por supuesto llegamos al tema de la red TOR, las conexiones anónimas o no, y el caso del hacker "hache" para discutir técnicas de cómo había podido ser detectada su dirección IP de conexión a Internet real.

En el caso de la red TOR, parece que el exploit de Mozilla Firefox usado por el FBI - y que ahora está incluido dentro del framework de Metasaploit - es el que se ha llevado por delante el anonimato de muchas personas, revelando la dirección IP de la máquina, la dirección MACy el nombre del sistema en una conexión HTTP realizada a un servidor de Virgina, USA, por lo que si se quiere ser anónimo hay que pensar en alguna capa de protección extra a nivel de red.

En medio de esas conversación, Juliano Rizzo nos comentó que lo mejor era solucionarlo con un sencillo truco de arquitectura en la cada de red, que debería utilizar todo el que quiera investigar en la red TOR o darse un paseo por la Deep Web, y que os lo dejo por aquí por si os sirve de utilidad.
- Sin conexión a Internet: Suponiendo que haya un exploit del navegador con el se conecta alguien a TOR, lo mejor es que esa máquina no tenga conexión a Internet sin pasar por TOR, eso evitaría que se revelara la dirección de conexión a Internet.  
- Red local privada aislada de la de trabajo: En el caso de que el exploit tenga acceso a la configuración local de la dirección IP, como en el caso de WebRTC en Mozilla Firefox y Google Chrome, lo que se debe evitar es que la dirección IP de la máquina pública, por lo que se debe crear una red privada aislada.  
- No Macs ni hostname identificativos: Se deben utilizar direcciones MAC spoofeadas y nombres de equipos que no identifiquen para nada al usuario de la máquina o su localización. 
- Con tu nodo TOR de por medio: Por último, mejor tener claro a que nodo de entrada te conectas, así que evita conectarte a un nodo TOR de otro que pueda ser malicioso en primer lugar. Si lo puedes tener en una máquina Raspberri Pi o similar separado, mejor que mejor.
Con todos estos ingredientes, la solución es una arquitectura más o menos como la que se ve en la imagen. La maquina de trabajo tendrá el hipervisor donde deben correr dos máquinas en un segmento de red aparte. Una que será el nodo de la red TOR - y tendrá conexión a Internet - y la otra, la máquina virtual desde la que se conecta el cliente a la red TOR, y que si no hay conexión vía TOR, no tiene conexión a Internet, para evitar reportar tráfico por una conexión fuera de la red.

Figura 1: Sugerencia de arquitectura de conexión a red TOR

Es una forma sencilla de tomar una precaución extra que evitaría caer en esquemas de ataques client-side, Javascript Botnets, o rogue node TORs de entrada, basados en data leaks y que parece más fácil de montar por cualquiera. Por supuesto, si te lanzan un exploit con elevación de privilegios y control total de la máquina, capaz de saltarse la VM y pasar a la máquina física la historia se acabó, pero el trabajo que hay que realizar es mucho mayor al que es necesario con solo tener un cliente TOR en tu máquina física.

Saludos Malignos!

10 comentarios:

Anónimo dijo...

Pero si la VM con tor es 0wneada, se podría pivotear a cualquier host de la dmz o lan y asi comprometer toda la red.

Chema Alonso dijo...

@anónimo, claro. Por eso se puede poner un nodo hw aparte, pero ya estamos hablando de exploits de ejecucíón de código, elevación de privilegios y evasión de VM, algo totalmente disitinto a un data leak que pueda ser utilizado.

Saludos!

Anónimo dijo...

Hoy no trolleo ,

amen al post txemita,

ssherpa

Hiroki Protagonist dijo...

Creo que voy a intentar currarme un esquema como ese con VirtualBox. Por cierto, me encanta como se puede hacer de fácil esto en Qubes http://theinvisiblethings.blogspot.com.es/2011/09/playing-with-qubes-networking-for-fun.html

Migue G dijo...

Me pregunto si la configuracion propuesta soluciona el problema de DNS leaks, que suceden por ejemplo si nuestro ISP usa un proxy transparente, teniendo acceso asi a nuestro historial de webs navegadas, dado que la resolucion de nombres de cada nuevo web site pasaria por los DNS del ISP si es que no hacemos algo para evitarlo, mas alla de que usemos la red TOR. en dnsleaktest.com proponen una solucion, igual me gustaria saber si seria necesario implementarla. Saludos!

Anónimo dijo...

Virtual con Tails como primer nodo TOR y Whonix para el resto con algún tipo de deepfreeze sería algo válido??

Alex.

Anónimo dijo...

buenas, se que este post es viejo pero podrian hacer un post ( si es que aun no existe) implementando la idea, de como crear tu propio nodo tor, en el escenario de usarlo en vmware para que el trafico de una segunda maquina fluya solamente atravez de tor y no tenga salida a internet , gracias.

Anónimo dijo...

Que hay Este pos es viejisimo Pero Muchas Gracias por tu explicasion Increible como
Saves tanto algún día quiero saber igual que voz

Santeador dijo...

Yo prefiero una Raspberry Pi y un viejo portátil con una live distro ;-)

http://www.it-cave.com/openwrt-tor-en-una-raspberry-pi/

Anónimo dijo...

soy novato en esto, pero tener un primer nodo en mi red no revelaría directamente mi ip a el nodo intermedio haciendo más fácil revelar con quien me estoy comunicando violando mi privacidad que es lo que busca la red tor?
Osea los ataques de marcado temporal y otros para revelar mi identidad no se podrían realizar desde el nodo intermedio?
gracias por sus comentarios

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares