Imaginemos un país en el que la libertad de expresión no esté asegurada, España por ejemplo. Resulta interesante crear una web en la que pueda asegurarse la libertad de expresión puesto que no es posible saber la máquina física en la que se ejecuta el aplicativo web. Otro enfoque interesante puede resultar crear un servicio con la intención de que nadie acceda a él, esto es posible con TOR ya que la dirección de acceso a los servicios ocultos no es publicada, ni indexada por arañas o buscadores web por el simple hecho de estar levantadas. Evidentemente si alguien publica en una web la dirección de acceso una araña conseguirá indexarlo. La principal finalidad es mantener anónima la máquina física que ejecuta el servicio.

Si te interesa el tema te estarás preguntando cómo funcionan tecnicamente los servicios ocultos. Lo explico brevemente:
Cuando un servicio oculto se crea localmente en la máquina se producen un par de claves: pública y privada. Asímismo se crea lo que se llama un descriptor de producto, que consiste en la lista de direcciones de acceso al servico junto con la clave pública del mismo. Este descriptor se publica anónimamente en los servidores de directorio de TOR, y son estos los que redireccionan al sistema en concreto (no directamente) cuando un cliente de TOR solicita acceso a la dirección del servicio oculto solicitada.

En el presente artículo crearemos un servicio web oculto. Nos basamos en la guía oficial de creación de servicios ocultos.
El primer paso es crear ese servicio de manera normal en el sistema, en nuestro caso un simple servidor web con Apache en el que colocamos una página estática, como podemos ver a continuación:

Ahora nos centraremos en Torificar dicho servicio para hacerlo oculto. Partimos de la base de que tenemos un repetidor TOR instalado, para hacerlo podemos consultar el artículo al respecto que publiqué recientemente.
Una vez hecho simplemente tenemos que modificar dos variables en el fichero /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80

La variable HiddenServiceDir sirve para indicar un directorio del sistema en el que TOR guardará información necesaria para trabajar con el servicio oculto. Entre dicha información se encuentran la dirección de acceso al servicio, certificados, etc. Es necesario que solo root tenga acceso a dicho directorio, por ejemplo permisos 700.
La variable HiddenServicePort sirve para indicarle a TOR dónde se enucentra dicho servicio, el formato es “puerto IP:Puerto“, de esta manera indicamos el puerto al que deben referenciar los accesos y la IP y puerto real en la que el servicio se encuentra escuchando. esto es importante porque si bien en nuestro ejemplo el servicio se pide en el mismo puerto y máquina, podríamos referenciarlo a otro sistema y/o puerto.

Una vez configurado levantamos el servicio en cuestión y el servicio TOR. Para saber mediante qué dirección URL podemos acceder al servicio simplemente consultamos el nombre del mismo en el directorio local del sistema:

Para acceder a dicho servicio configuramos el navegador en la red TOR y pedimos la URL indicada:

Si observamos los ficheros de log de Apache podemos apreciar que no apareceran las IP’s de acceso de los visitantes, ya que estarán referenciadas por la IP que marcamos en el fichero de configuración de TOR:

Hasta aquí la creación de servicios ocultos, en próximos artículos me gustaría indagar sobre desventajas del uso de esta red y posibles defectos en ella. Pero eso será probablemente tras unas merecidas vacaciones.

Compártelo

No voy a explayarme porque no creo que pueda expresarlo mejor que la página oficial, con gráficos y demás. Analizar en profundidad esto queda fuera del objeto de este post pero quisiera remitir a los interesados unas URL’s para profundizar sobre el tema:

https://wiki.torproject.org/noreply/TheOnionRouter
https://git.torproject.org/checkout/tor/master/doc/design-paper/tor-design.pdf
https://git.torproject.org/checkout/tor/master/doc/spec/tor-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/control-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/rend-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt
https://git.torproject.org/checkout/tor/master/doc/spec/path-spec.txt

Entre las características interesantes que esta red ofrece destacan de manera especial los “servicios ocultos”, que son distintos tipos de servicios (web, irc, etc) que sólo son accesibles para y desde la red TOR, y que tienen la propiedad de que teóricamente no es posible saber el sitio físico o PC concreto en el que está alojado dicho servicio. En próximos post crearemos uno y hablaremos de ellos.

Una de las cosas importantes a tener en cuenta es que la “calidad” de la privacidad es directamente proporcional al número de repetidores que haya en la red. Este post se centrará en explicar brevemente cómo crear de manera sencilla un nodo repetidor de TOR sobre un sistema Linux, concretamente sobre un Fedora Linux 10.
Primero hay que destacar que hay dos tipos de repetidores, los internos y los de salida. Configurar un nodo de salida puede traer algunas complicaciones que explicaremos en un futuro post, y veremos cómo hacerlo. De momento nos centraremos en un repetidor interno, que basicamente sirve para marear peticiones con el objeto de conseguir una privacidad aceptable.

La página oficial de TOR tiene abundante documentación, recomiendo mirar la guía para configurar repetidores, aunque aquí explicaré brevemente como hacerlo en dos patadas.

== Instalando TOR ==

Tor está en los repositorios de Fedora por lo que instalar el software es tan sencillo como ejecutar el siguiente comando con privilegios de administración:

yum install tor

== Configurando TOR como repetidor interno ==

El fichero de configuración de TOR se encuentra en /etc/tor/torrc y para crear un sencillo repetidor interno basta con las siguientes opciones:

SocksPort 9050 # puerto para las conexiones locales
SocksListenAddress 127.0.0.1 # aceptar conexiones de localhost
Log notice file /var/log/tor/notices.log # fichero de log notice
Log debug file /var/log/tor/debug.log # fichero de log de depuracion
Log notice syslog # facility del syslog
RunAsDaemon 1 # ejecutar el servicio como demonio
DataDirectory /var/lib/tor/.tor # directorio de datos
Nickname mordor # nombre del repetidor
RelayBandwidthRate 50 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 50 KBytes # But allow bursts up to 200KB/s (1600Kbps)
ORPort 9001 # puerto en el que se esperan conexiones
DirPort 9030 # puerto para solicitar conexiones, ideal si tienes mucho ancho de banda para compartir
Group toranon # grupo con el que se ejecutará
User toranon # usuario con el que se ejecutará

hay que destacar que si tienes una conexión ADSL normal y corriente tendrás que hacer NAT contra tu sistema para los puertos definidos en las variables ORPort y DirPort.

== Comprobar que funciona ==

Para comprobar que está en ejecución sin problemas debemos recurrir al log, que se encuentra en la ruta /etc/tor/torrc, para que funcione debería tener un aspecto similar a esto:

May 02 01:12:06.368 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
May 02 01:12:06.368 [notice] Now checking whether ORPort 83.44.185.90:9001 and DirPort 83.44.185.90:9030 are reachable… (this may take up to 20 minutes — look for log messages indicating success)
May 02 01:12:11.307 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
May 02 01:12:11.528 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
May 02 01:12:30.024 [notice] Performing bandwidth self-test…done.

Adicionalmente una vez que el servidor es accesible a la red sus datos serán subidos a los llamados “descriptores de servidor” y en ellos podremos comprobar que nuestro nodo forma parte de la red TOR, en mi caso he usado un descriptor (http://moria.seul.org:9032/tor/status/authority) para comprobar que mi nodo “mordor” forma parte de la red:

== Funcionando ==

Una vez que funcione hay varias recomendaciones que pueden leerse en la guía oficial. Por mi parte simplemente he querido ver un poco qué es lo que se mueve en esta red y para ello he levantado un sniffer (tcpdump) y he inspeccionado el tráfico que pasa por mi nodo.
Tenemos por tanto un fichero .cap con el tráfico interceptado. Para analizarlo utilizaremos Wireshark. Vamos a distinguir dos tipos de comunicaciones:

1. Tráfico de solicitud de conexiones.
Este tipo de tráfico se transmite entre los nodos internos y los servidores de directorio y es necesario para poder calcular las rutas por las que viajarán los paquetes. Este tráfico utilza el puerto que hayamos definido en la variable DirPort, en nuestro caso el 9030, asique aplicaremos el siguiente filtro al Wireshark:

tcp.port == 9030 || udp.port == 9030

Si ensamblamos la comunicación TCP tenemos dos tipos de comunicaciones, en el primer tipo tenemos una comunicación parcialmente cifrada

La IP de nuestro repetidor es la 192.168.1.33 y por lo que podemos ver una IP perteneciente a otro repetidor (podemos contrastarlo consultando en el descriptor de servidor comentado anteriormente) realiza una petición http GET a la que nuestro repetidor contesta con un 200 OK.
El contenido de dicha respuesta está cifrado.

En el segundo tipo de petición tenemos algo similar a la anterior, pero con una respuesta negativa (400 NOT FOUND):

2. Tráfico entre repetidores.
Este es el tráfico más abundante y se realiza mediante el puerto definido en la variable ORPort, en nuestro caso el 9001, asique aplicaremos el siguiente filtro al Wireshark:

tcp.port == 9001 || udp.port == 9001

Como podemos comprobar en las siguientes capturas el tráfico va cifrado y se produce únicamente entre IP’s que pertenecen a repetidores (podemos contrastarlo consultando en el descriptor de servidor comentado anteriormente):

En las próximas entradas configuraremos un nodo de salida y comprobaremos cómo en este caso sí pueden inspeccionarse los datos de salida.

Compártelo