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 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.
