Inicio > Hacking, Networking, Services - Software > Preservando el Anonimato y Extendiendo su Uso – Utilizando SSH y TOR juntos – Parte IX

Preservando el Anonimato y Extendiendo su Uso – Utilizando SSH y TOR juntos – Parte IX


En la entrada anterior se ha explicado como se pueden crear servicios ocultos (hidden services) en la red de TOR, de forma tal que otros usuarios conectados a la red puedan acceder a dichos servicios sin que sea necesario revelar el origen real de la máquina donde se ejecuta dicho servicio, esto es en efecto un servicio oculto o expresado de un modo mas adecuado, un servicio anónimo. Todo esto se consigue principalmente a las claves publicas de dicho servicio que son “dominios” especiales con “.onion”, se puede crear toda clase de servicios, desde acceso a servidores web, hasta accesos a bases de datos, frecuentemente utilizando un proxy socks/http/https de por medio (a menos que sea un servidor web, en tal caso solamente es necesario tener un navegador web correctamente configurado tirando de la red de TOR) una solución a dicha implementación de proxy, puede ser simplemente el uso de SOCAT para ejecutar un relay de la conexión entrante desde un puerto determinado en la maquina local hacia el servicio remoto. Dado que SSH es el protocolo principal para acceso remoto y tareas de administración (entre muchas otras cosas) el uso de SSH en TOR será el enfoque principal de esta entrada.

UTILIZANDO SSH PARA CIFRAR TODO EL TRAFICO EN LA RED TOR

Esta es una técnica muy importante a la que el lector debe prestar atención, ya que es una excelente forma de cifrar completamente el trafico que viaja desde en la red TOR, ahora bien, el lector probablemente dirá: “Si los paquetes que viaja en la red de TOR ya viajan cifrados para que necesito que SSH los cifre por mi?” la razón es simple, la información viaja cifrada en todos los nodos de la red CON EXCEPCIÓN a los paquetes que van desde el nodo de salida hacia el destino final, por este motivo, un atacante puede crear un relay que actúa como nodo de salida y ejecutar en él un sniffer para capturar todos los paquetes que viajan hacia un destino determinado, como ya se ha indicado, los paquetes desde el nodo de salida y el destino viajan en texto claro, por lo tanto, el atacante solo debe esperar y tener un poco de suerte para capturar contraseñas y otra información sensible. Anteriormente se ha indicado el uso de TorButton y una extensión de Firefox llamada HTTPS Everywhere empleada principalmente para mitigar esta situación (un riesgo bastante latente) sin embargo, es algo valido si solamente se navega por internet utilizando un navegador web, pero si es necesario utilizar algún comando desde consola, evidentemente la extensión de Firefox ya no aplica.

Para solventar esto se puede utilizar un túnel local utilizando SSH que reciba las peticiones por un puerto y posteriormente las canalice a otro donde se puede encontrar en ejecución un proxy socks como Privoxy o directamente el servicio de TOR. A continuación se enseñan los pasos para demostrar lo sencillo que es establecer un puente local con SSH para cifrar todas las peticiones que viajen por medio de dicho túnel.

  1. Utilizando TorTunnel, se inicia la conexión con un nodo de salida, (ver entradas anteriores sobre esta serie para conocer en profundidad el uso de TorTunnel)

    >./torproxy 24.141.199.42

    torproxy 0.2 by Moxie Marlinspike.

    Retrieving directory listing…

    Connecting to exit node: 24.141.199.42:443

    SSL Connection to node complete. Setting up circuit.

    Connected to Exit Node. SOCKS proxy ready on 5060.

    Queda iniciado el servicio SOCKS en el puerto 5060. Ahora ha establecer el puente local SSH.

  2. Iniciar el túnel en la maquina local

    >ssh -L 5050:127.0.0.1:5060 -CN -f root@127.0.0.1

    >netstat -ano | grep 5050

    tcp 0 0 127.0.0.1:5050 0.0.0.0:* LISTEN off (0.00/0/0)

    tcp6 0 0 ::1:5050 :::* LISTEN off (0.00/0/0)

    El puente se ha creado correctamente, en el puerto 5050 se encuentra en ejecución el túnel local, el cual posteriormente realizará un “forward” de los paquetes recibidos al puerto 5060.

  3. Editar el fichero de configuración de proxychains ubicado en /etc/proxychains.conf y definir como servidor SOCKS el puerto 5050 (túnel local SSH iniciado en el paso anterior)

    socks5 127.0.0.1 5050

  4. Ejecutar un simple comando nmap con proxychains para probar el comportamiento

    >proxychains nmap -P0 -n -sT -p80,22,443 74.125.93.147

    ProxyChains-3.1 (http://proxychains.sf.net)

    Starting Nmap 5.51 ( http://nmap.org ) at 2011-09-06 00:19 CEST

    |D-chain|-<>-127.0.0.1:5050-<><>-74.125.93.147:80-<><>-OK

    |D-chain|-<>-127.0.0.1:5050-<><>-74.125.93.147:443-<><>-OK

    |D-chain|-<>-127.0.0.1:5050-<><>-74.125.93.147:22-<–timeout

    Nmap scan report for 74.125.93.147

    Host is up (0.62s latency).

    PORT STATE SERVICE

    22/tcp closed ssh

    80/tcp open http

    443/tcp open https

    Como se puede ver, proxychains se ha conectado correctamente con el túnel local en el puerto 5050 y posteriormente el paquete es enviado a TorTunnel el el puerto 5060. La salida de TorTunnel enseña la siguiente traza.

    Got SOCKS Request: 74.125.93.147:80

    Successfully opened Tor exit Node stream…

    CIRCUIT: Close called…

    Got SOCKS Connection…

    Got SOCKS Request: 74.125.93.147:443

    Successfully opened Tor exit Node stream…

    CIRCUIT: Close called…

    Got SOCKS Connection…

    Got SOCKS Request: 74.125.93.147:22

    Error opening stream: system:111

    El nodo de salida de Tor automáticamente envía la petición a la dirección remota en cada uno de los puertos indicado en el comando nmap.

  5. Finalmente, tras ver el trafico de paquetes en la interfaz local (que es el origen de los paquetes en primer lugar) se puede apreciar que viajan cifrados, pasando primero por SSH y posteriormente por TorTunnel, desde un Sniffer como wireshark no es posible visualizar información en texto claro, todo esta cifrado desde su propio origen, por este motivo un atacante en un nodo de salida, tendrá los mismos resultados desde su nodo de salida malicioso

Por otro lado, otra forma de realizar estas mismas actividades, es utilizando la opción Socks5Proxy en el fichero de configuración de TOR, (normalmente ubicado en /etc/tor/torrc) dicha propiedad tendrá el siguiente valor en este caso concreto

Socks5Proxy 127.0.0.1:5050

De esta forma, todo lo que viaje por TOR ira cifrado desde su origen, siendo este el mejor mecanismo (y evidentemente el recomendado) para asegurarse de que todos los paquetes viajan cifrados en cada nodo de la red TOR, incluyendo el nodo de salida.

CONEXIÓN A UN SERVICIO SSH EN LA RED DE TOR.

Aunque como se ha podido comprobar en la entrada anterior, realizar una conexión a un servidor web ubicado en algún nodo (ubicación real desconocida) en la red de TOR es tan sencillo como abrir un navegador web, dirigir el trafico a TOR (como por ejemplo con TorButton) y acceder a la dirección publica del servicio, finalizada con .onion, en el caso de SSH este procedimiento no es tan sencillo como simplemente acceder directamente a la dirección .onion creada por TOR para su posterior acceso, para acceder al servicio TOR desde el cliente SSH, es necesario utilizar un proxy o un relay SOCKS que permita recibir la petición del cliente SSH y enviarla por la red de TOR, para hacer esto pueden existir muchas alternativas sin embargo las mas conocidas son, utilizar SOCAT como relay o utilizar un proxy.

Utilizando connect-proxy

Se trata de una pequeña aplicación escrita en lenguaje C que actúa como un Relay entre un cliente y un proxy SOCKS o un túnel HTTP, esta funcionalidad permite a cualquier cliente realizar conexiones a dicho relay y enviar paquetes de datos a un destino determinado, para instalar esta utilidad basta con ejecutar el comando “APT”

>apt-cache search connect-proxy

connect-proxy – Establish TCP connection using SOCKS4/5 or HTTP tunnel

>apt-get install connect-proxy

Posteriormente, su uso es sencillo, solamente basta con editar el fichero de configuración del cliente SSH ubicado en /etc/ssh/ssh_config e incluir la opción “ProxyCommand” tal como se indica a continuación:

ProxyCommand connect -S localhost:9050 %h %p

Una vez editado el fichero de configuración, es posible realizar la conexión con el servicio SSH por medio de la red de TOR utilizando la dirección onion generada por SSH de la siguiente forma:

>ssh adastra@mik3lryhrqkt6rts.onion -p 22

El comando anterior ejecutará antes que nada, el comando “connect” con los parámetros establecidos, de esta manera se podrá realizar una conexión directamente a TOR, (se asume que se encuentra en ejecución en el puerto por defecto 9050, en el caso de que sea otro distinto, indicarlo en el la opción ProxyCommand)

Utilizando SOCAT

Este caso es también muy sencillo, solamente es necesario utilizar SOCAT para abrir un puerto en la máquina local y posteriormente ejecutar el relay de cualquier conexión entrante por dicho puerto hacia el servidor remoto pasando por un servidor SOCKS (que en este caso es evidentemente el servicio de TOR).

La apariencia de dicho comando puede ser similar a la siguiente:

>socat TCP4-LISTEN:4444,reuseaddr,fork SOCKS4A:127.0.0.1:ik3lryhrqkhDDSrts.onion:22,socksport=9050

En este caso, se abre el puerto 4444 en la maquina local, indicando que cualquier conexión debe ser bifurcada a un proceso hijo, de modo tal que si dicha conexión finaliza, aun el puerto continué abierto, por otro lado con la especificación SOCKS4A se indica que se utilizará un proxy SOCKS4A para realizar la conexión remota cuyo puerto es el 9050 (puerto por defecto de TOR, especificar otro en el caso que sea distinto a este), posteriormente se indica la dirección onion donde se encuentra localizado el servicio en la red TOR y su puerto correspondiente.

Una vez se ha iniciado este relay con SOCAT, se utiliza el cliente SSH para realizar la conexión con el servicio SSH remoto realizando la conexión con el puerto que se ha abierto con SOCAT (4444).

>ssh adastra@localhost -p 4444

Se introduce la contraseña y con esto se completa la conexión con el host remoto.

Utilizando Corkscrew

Corkscrew es una herramienta escrita con el fin de realizar “tunneling” de sesiones SSH a través de proxies HTTP.

Dado que funciona como proxy HTTP no es posible utilizarlo junto con TOR, sin embargo se indica su uso ya que es otra solución de “tunneling” de sesiones SSH

En primer lugar es necesario instalar Corkscrew, la versión a la fecha de escribir este documento es la 2.0 y se puede descargar el código fuente, compilarlo e instalarlo. Descargar desde: http://www.agroman.net/corkscrew/corkscrew-2.0.tar.gz

Descomprimirlo y posteriormente instalar utilizando configure y make

>./configure

>make

>make install

Posteriormente, editar el fichero de configuración del cliente SSH, que como ya se ha dicho se encuentra ubicado en /etc/ssh/ssh_config e incluir la linea que indica que se debe ejecutar el proxy

ProxyCommand corkscrew proxy 8080 %h %p

Asumiendo evidentemente que en la maquina “proxy” se encuentra un proxy HTTP en ejecución en el puerto 8080.

Posteriormente, tal como ya se ha visto, se intenta realizar una conexión con el servicio SSH utilizando corkscrew

>ssh -p 22 root@maquina_remota

Los mecanismos indicados permitirán realizar una conexión con la maquina remota sin conocer la ubicación real de la misma (sin conocer la dirección IP o algún nombre de dominio), aunque evidentemente, si el usuario que se conecta a la maquina remota no se encuentra en un entorno chrooted o los permisos de ejecución de ciertos comandos no se encuentran correctamente restringidos, para dicho usuario no será difícil saber exactamente donde se esta ejecutando el servicio, por este motivo se recomienda seguir las pautas pertinentes al momento de exponer este servicio por medio de TOR.

  1. gaucho
    diciembre 8, 2011 en 8:42 pm

    mis felicitaciones por esta serie de entradas por demás interesantes y sobre todo útiles.

    [......puede utilizar un túnel local utilizando SSH que reciba las peticiones por un puerto y posteriormente las canalice a otro donde se puede encontrar en ejecución un proxy socks como Privoxy o directamente el servicio de TOR.....]

    si no he comprendido mal tu esquema seria el siguiente:
    tunel ssh—–>proxy (polipo o privoxy)——->tor.

    ahora bien, las peticiones cuando llegan al proxy están cifradas, el proxy es capaz de leer esa info?

    no seria mejor proxy—>tunel—->tor ?

    bueno….perdon por ensuciar tu exelente trabajo con este comentario.

    saludos.

    • diciembre 8, 2011 en 9:00 pm

      Has comprendido correctamente.
      Sobre tu pregunta, el túnel recibirá los paquetes enviados por SSH y posteriormente los enrutará a su correspondiente destino (por medio de TOR) el proxy es capaz de enrutar esta información dado que el cifrado que realiza SSH es end-to-end a nivel de aplicación, mientras que los circuitos de TOR realizan cifrado a nivel de la capa de transporte. Por esta razón puede transferir dichos paquetes sin problemas. Sin embargo esto NO significa que cualquier router en el circuito de TOR o incluso el proxy, pueda leerlos en texto claro, es decir, puede transportar los paquetes a su correspondiente destino, pero al no poseer la clave correspondiente que los descifra, no puede acceder a su forma original.

  2. gaucho
    diciembre 8, 2011 en 9:56 pm

    por lo tanto lo correcto mas seguro seria tu esquema?
    lo he implementado y probado como salida para svn,obteniendo los resultados deseados segun wireshark.

    ejem: proxychains svn update
    proxychains—>tunel ssh—–>polipo—–>tor

  3. diciembre 8, 2011 en 10:47 pm

    En principio resulta bastante seguro, especialmente debido a uno de los principales problemas que tiene TOR: Los Exit-Nodes. Como ya sabrás, todo el canal de comunicación en un circuito TOR es cifrado, a excepción de los paquetes que viajan entre el nodo de salida y el destino, los cuales viajan en texto claro, por lo tanto para un atacante es muy fácil sniffear con wireshark, tcpdump o cualquier sniffer, el hecho de cifrar los paquetes desde el origen (con SSH en este caso) permite tener la tranquilidad de que no cualquiera podrá ver los paquetes en texto claro.

    Sobre tu prueba me parece correcta, de esa forma todos lo paquetes que envías cuando ejecutas “ProxyChains” son cifrados por el túnel SSH y de ahí en adelante, Polipo y TOR hacen “su magia”.
    Un Saludo.

  4. Deco
    agosto 31, 2012 en 5:06 pm

    Hola Adastra, felicidades por el blog antes de nada.
    Estoy practicando un poco con tus explicaciones y me quedo atrancado en el siguiente punto:

    Activo ssh asi:

    service ssh start

    ssh -L 5050:127.0.0.1:5060 -CN -f root@127.0.0.1

    Al ejecutar este comando me aparece:
    Read from socket failed: Connection reset by peer

    No entiendo qu’e pasa.

    Gracias!

    • septiembre 1, 2012 en 1:04 am

      Hola,
      Asegurate que el proxy SOCKS se encuentra abierto y escuchando en el puerto 5060

      netstat -antp | grep 5060

      El error indica que el puerto esta cerrado.

  1. diciembre 7, 2011 en 5:02 pm

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 926 seguidores

%d personas les gusta esto: