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!