Copy Link
Add to Bookmark
Report
SET 027 0x08
-[ 0x08 ]-------------------------------------------------------------------
-[ Freenet ]----------------------------------------------------------------
-[ lindir ]---------------------------------------------------------SET-27--
Freenet. Una red totalmente distribuida y anonima.
por Lindir.
- ---------------Indice ---------------
0. Introduccion.
1. El problema del anonimato.
1.1 Anonimato del cliente.
1.1.1 Anonimato del atacante.
1.1.2 Anonimato de un usuario legitimo.
1.2 Anonimato del servidor.
1.3 Problemas de seguridad.
1.4 Soluciones a estos problemas.
2. Freenet.
2.1 Freenet es anonima tanto para cliente como para servidor.
2.2 Freenet consigue que la informacion mas valiosa sea mas accesible.
2.3 Freenet hace que la informacion menos valiosa desaparezca.
2.4 Los problemas de freenet.
2.4.1 El malgasto de recursos.
2.4.2 La inundacion.
2.4.3 La identificacion de datos.
2.4.4 Las actualizaciones.
2.4.5 El software.
2.5 Freenet en Internet.
3. Conclusiones.
- -------------------------------------
0. Introduccion.
La red Freenet es un tipo de red montada sobre redes TCP/IP que intenta
solucionar varios problemas inherentes a Internet, principalmente la falta de
anonimato. Es una red que surge como consecuencia practica del estudio "A
Distributed Decentralised Information Storage and Retrieval System", realizado
por Ian Clarke en la Universidad de Edimburgo.
En estas lineas intentare dar una idea general del funcionamiento teorico de
dicha red, extrapolable a otras posibles redes que se creasen utilizando las
mismas tecnicas.
1. El problema del anonimato.
En internet, el anonimato es una utopia. En redes TCP/IP con el modelo cliente-
servidor todos los datagramas IP que llegan a un nodo contienen tanto la
direccion IP de origen como la direccion IP de destino.
1.1 Anonimato del cliente.
1.1.1 Anonimato del atacante.
Un problema inherente a cualquier ataque a seguridad por parte del atacante
consiste en esconder el origen del mismo. Para ello usualmente se utilizan
tecnicas como el Bouncing o Spoofing, ampliamente conocidas pero que no
solucionan totalmente el problema del anonimato. El spoofing es especialmente
útil para ataques a torres de protocolos que no requieren conexion, del estilo
de "nukes", o para el "sesion hijacking" y variantes, pero tiene que darse un
escenario concreto para poder usarlo. El bouncing permite hacer mas dificil
encontrar el origen real de una conexion, pero es posible (con tiempo, medios
y un poco de suerte) trazar todos los saltos de una conexion hacia atras,
encontrando al usuario final que lanzo la misma.
1.1.2 Anonimato de un usuario legitimo.
Cualquier usuario que se conecte a un servidor TCP o UDP debe saber que
su consulta puede quedar registrada en una base de datos, con todas las
posibilidades que ello conlleva de trafico de informacion, cosa que es
dificilmente detectable y no digamos ya evitable.
Incluso utilizando servidores DHCP que proporcionen una IP distinta cada vez
(como ocurre con ciertos ISPs), el servidor DHCP puede controlar dichos
datos y almacenar un registro de los mismos, de forma que un ataque a un ISP
(cosa que no es tan descabellada, en vista del nivel de seguridad en los
mismos, sobre todo debido a sus usuarios) puede proporcionar informacion
sobre los accesos de cualquier cliente del mismo.
Si se utiliza un proxy o NAT, el nivel de detalle que puede obtenerse
trazando las conexiones salientes del mismo es menor, ya que no se sabe en
principio cual de todos sus usuarios es el que causa el inicio de conexion
por parte del proxy, pero se puede tener una idea de las preferencias del
grupo, lo cual tampoco esta nada mal...
1.2 Anonimato del servidor.
Si el anonimato del cliente es dificil, el del servidor es nulo. Todo
servidor debe ser accesible a partir de su direccion IP bien conocida, ya
sea porque es una IP fija o mediante una traduccion DNS en servidores DynDNS
(tipo no-ip). El caso es que toda informacion publicada en Internet tiene la
marca del servidor en que se alberga. Asi pues, censurar contenidos en la
red es tan sencillo como cerrar el servidor, bien por via legal, bien por
via intimidatoria. Esto último quiere decir que se puede amenazar a la
empresa que aloja los contenidos con una demanda si no retira los mismos. Si
el interesado en retirar los contenidos tiene suficiente poder economico, la
empresa que los alberga preferira retirarlos antes que enfrentarse a un
pleito que posiblemente perdera. Como muestra, la desaparicion repentina de
todas las peliculas ilegales DiVX de servidores Web debido a la presion de
la industria cinematografica y las distribuidoras, el cierre de Napster,
Audiogalaxy, etc.
1.3 Problemas de seguridad.
Puesto que es imposible que un servidor sea anonimo a los clientes que a el
acceden, atacar al mismo es siempre posible. No hay ningún modo de
"esconder" al servidor de forma que los atacantes no puedan encontrarlo. Por
ello la seguridad al cien por cien nunca es garantizable. Esto ocurre con
todo tipo de servidores, incluso con servidores DNS o con pasarelas, ambos
necesarios para el correcto funcionamiento de la red.
Si se consigue "tirar" un gateway, el segmento de subred al que este esta
conectado queda inaccesible, y el resto de la red queda a su vez inaccesible
para esta subred. Por lo tanto, se producen "cuellos de botella" en cuanto a
disponibilidad de la red, que podrian ser subsanados si dichos
servidores/pasarelas fueran anonimos.
1.4 Soluciones a estos problemas.
Las principales soluciones a los problemas de seguridad consisten en evitar
que un ataque sea fructuoso. Esto se hace mediante cortafuegos, parches,
politicas de seguridad, concienciacion del usuario... Tambien puede
albergarse la informacion en distintos "mirrors", de forma que sea dificil
cerrarlos o practicar ataques DoS contra todos, pero otra vez dados tiempo y
medios suficientes esto puede no ser eficaz.
Las soluciones a la libre difusion de contenidos por la red se basan hoy en
dia en conexiones punto a punto entre clientes, del estilo edonkey. En
estos sistemas, el servidor no contiene la informacion, sino son los
clientes los que la almacenan y comparten. De esta forma, no es posible
cerrar el servidor por almacenar informacion ilegal ya que este solo se
ocupa de conectar a los clientes entre si, en hacer que sean "visibles" unos
y otros. Pero aún asi, sigue sin haber anonimato, ya que debemos indicar a
cada host al que queremos conectarnos cúal es nuestra IP.
2. Freenet.
En este apartado intentare ofrecer una somera imagen del funcionamiento de
la red freenet, sin entrar en muchas honduras. Si alguien esta realmente
interesado en el tema, lo remito a la web oficial en sourceforge,
freenet.sourceforge.net, donde podra encontrar documentacion exhaustiva
sobre el tema, amen de software de acceso a la red.
2.1 Freenet es anonima tanto para cliente como para servidor.
La red freenet se basa en esta red TCP/IP no anonima y crea una red anonima
mediante un sencillo mecanismo. Cada host no se conecta directamente al
servidor que contiene la informacion, sino que se crea una malla de
servidores/clientes totalmente descentralizada.
La idea es que cada host actúa tanto de cliente como de servidor y que todos
tienen el mismo poder dentro de la red. Cuando un usuario quiere conseguir
cierta informacion, su host comprueba si la tiene. Si no es asi,
redirecciona la peticion a una lista de hosts que tiene. Estos comprueban si
la informacion esta almacenada en ellos, y si no la tienen almacenada a su
vez redireccionan la peticion a otros hosts.
Una vez se llegue a un nodo que contenga dicha informacion, este nodo la
envia al nodo anterior que la pidio, quien a su vez la manda al anterior que
la pidio, y asi hasta que se llega al nodo que inicialmente lanzo la
peticion, el cual pasa la informacion al usuario.
Lo bueno que tiene este sistema es que cada nodo recibe peticiones otros
nodos "proximos", pero no sabe si el sumidero de informacion sera el nodo
que le hizo la peticion o si este esta redireccionando una peticion de un
nodo anterior.
Asimismo, cuando un nodo contesta un mensaje de peticion y envia la
informacion, el siguiente nodo que la recibe no sabe si los datos estan
almacenados en el nodo que se la manda o este esta redireccionando los datos
desde otro nodo anterior.
Un ejemplo ayudara a aclarar el mecanismo de funcionamiento. Supongamos que
hay un nodo A que, debido a una peticion de un usuario, quiere encontrar el
archivo "datos.dat". Este nodo esta conectado a los nodos B, C y D. El nodo
B esta a su vez conectado al nodo E, el cual contiene precisamente el
archivo "datos.dat", y los nodos C y D estan conectados a otros nodos que no
tienen dicho archivo. Un esquema seria:
El usuario quiere datos.dat
+-------Nodo A----------+
| | |
Nodo B<-+ +->Nodo C+ +->Nodo D--->A otros nodos
| |
Nodo E<--| A otros nodos<-+
·"datos.dat"
Cuando el nodo A recibe la peticion de su usuario, comprueba si tiene el
fichero en su disco duro. Como no lo encuentra, lanza un mensaje de peticion
a los nodos B, C y D. Los nodos C y D comprueban que no tienen el mensaje e
intentan reenviar la peticion a otros nodos. Supondremos que el mensaje, que
tiene un "tiempo de vida" (al igual que los datagramas IP) muere antes de
llegar al nodo E por estos caminos.
En cambio, el nodo B reenvia el mensaje al nodo E, el cual si tiene la
informacion pedida. Entonces el nodo E contesta enviando el fichero al nodo
B, el cual a su vez lo envia al nodo A. Una vez llega al nodo A, el
protocolo de freenet pasa los datos al usuario, y ahi termina el proceso.
Entonces el paso de informacion seria
a) Nodo A ==pide "datos.dat"==> Nodo B ==pide "datos.dat"==> Nodo E
b) Nodo E ==da "datos.dat"==> Nodo B ==da "datos.dat"==> Nodo A
a = peticion, b = respuesta.
Vemos que el nodo B solo sabe que el nodo A quiere "datos.dat" pero no sabe
si quiere el archivo para el o para otro nodo que se lo ha pedido. Lo mismo
ocurre con el nodo E: solo ve que B le pide el archivo, pero no sabe si lo
quiere para el (de hecho, en este caso lo quiere para A, pero ni el nodo B
ni el E saben quien es el receptor final de la informacion).
Con la respuesta ocurre exactamente lo mismo. B no sabe si E tiene el
fichero o si lo esta recibiendo de otro nodo y lo esta reenviando. A solo ve
que B contesta con el archivo pedido, pero no sabe que el nodo que realmente
lo tiene es E.
De esta forma, el anonimato esta garantizado.
2.2 Freenet consigue que la informacion mas valiosa sea mas accesible.
En efecto, la informacion mas valiosa en freenet es la mas accesible. Lo
primero que cabe preguntarse es ¿cúal es la informacion mas valiosa? La
respuesta es simple: la que mas veces se pide.
Supongamos que cierto archivo es muy solicitado por distintos nodos que
conforman la red. Para evitar tener que realizar las costosas (a nivel de
recursos de ancho de banda) peticiones que deben ser reencaminadas, cada
nodo tiene una "cache". En dicha cache se almacenan los archivos que han
sido obtenidos de la red, pero se diferencia de las caches de, por ejemplo,
los navegadores en que esta cache sirve a todos los nodos de la red. Esto
quiere decir que si un nodo recibe una peticion de un archivo que esta en su
cache, dicho nodo contestara enviando el archivo al que lo pidio. De este
modo, puesto que el nodo final que pide el archivo replica el mismo en su
cache, la informacion esta siendo duplicada en cada acceso. Asi, si por
ejemplo existe cierto archivo muy solicitado, este archivo estara replicado
en distintos nodos a lo largo de la red, de forma que para acceder a el
sera necesario dar menos saltos que si solo estuviera en un nodo.
Ademas, asi se hace virtualmente imposible un ataque de negacion de servicio
sobre dicha informacion: ahora esta replicada en distintos nodos
desconocidos para el atacante. Un ejemplo que el autor Ian Clarke explica es
el caso en que un archivo situado inicialmente en EE.UU. sea muy solicitado
por usuarios de Japon. Este archivo debe cruzar el cable transatlantico, lo
que supone un fuerte consumo debido a la escasez de ancho de banda del
mismo. Pero una vez esta replicado en un nodo en Japon, los nodos japoneses
realizaran la peticion y seran atendidos por el nodo que la ha replicado en
Japon, en lugar de por el originario estadounidense.
2.3 Freenet hace que la informacion menos valiosa desaparezca.
Todo esto de la cache es estupendo, pero hay un pequeño problema: los discos
duros son finitos y no pueden almacenar todos los ficheros que se reciban.
Llega un momento en que habra que borrar algo de la cache para poder guardar
nuevos datos en ella. Y lo que se borra es, precisamente, lo que ha sido
menos pedido en un tiempo determinado.
De esta forma, si un archivo deja de ser pedido por los usuarios, este ira
desapareciendo paulatinamente de cada nodo de la red que lo almacene, salvo
que vuelvan a realizarse peticiones del mismo.
Un efecto que puede darse es que un archivo se mueva de su ubicacion inicial
hacia otros nodos mas o menos lejanos que tengan alrededor muchos nodos que
pidan ese archivo. Por ejemplo, en el caso del nodo japones anterior, puede
ocurrir que dicho archivo sea un texto en japones. Lo mas normal sera
entonces que reciba muchas mas peticiones en Japon que en EE.UU., lo cual
hara que, con el paso del tiempo, el nodo original estadounidense lo borre
de su cache al no recibir suficientes peticiones. En cambio, si el archivo
es bastante popular, el nodo japones y sus colindantes lo consideraran
informacion valiosa, y no la borraran. De esta forma, la informacion ha
"viajado" desde su origen en EE.UU. hasta su "nuevo hogar" en Japon
(precioso, ¿no es asi? ;-)) Se supone que asi se consigue atender a la
mayoria de personas, o a minorias lo suficientemente numerosas y
localizadas.
El problema son las minorias no localizadas. Si alguien escribe un articulo
sobre la cria del galapago en cautividad pero los pocos usuarios interesados
se encuentran desperdigados entre Madagascar, Nueva Zelanda, Nepal y
Honduras, dicho articulo tiene alta probabilidad de desaparecer de la red
(¡mala suerte!).
2.4 Los problemas de freenet.
Todo este sistema teorico parece bastante bonito, pero la cosa no es tan
sencilla como parece.
2.4.1 El malgasto de recursos.
El principal problema que tiene freenet es el despilfarro de recursos de red
del que hace gala. Si en una conexion "peer to peer" IP en la que los
paquetes dan N saltos de un nodo a otro se consume N x R donde R son los
recursos en ancho de banda y tiempo de proceso necesarios para transmitir
los datos, en freenet no es asi.
Primero, los datos no van directamente de un extremo al otro, sino que pasan
por varios nodos intermedios. Si el numero de nodos intermedios es I, se
consume entonces teoricamente (en una red en la que los nodos I esten unidos
por enlaces directos) I x R, y ademas I debe ser mayor o igual que N
(generalmente, sera mucho mayor que N).
Pero es que ademas la red freenet esta montada sobre una red TCP/IP ya
existente, con lo cual entre cada par de nodos intermedios la conexion no
sera directa, sino que los datos daran un número de saltos determinado por
la estructura actual (recordar que el encaminamiento en IP es dinamico) de
la red TCP/IP. Si suponemos que el número de saltos entre cada par de nodos
es M, los recursos consumidos son entonces I x R x M. ¡Ejem! Creo que hemos
aumentado la cantidad de recursos necesarios en un orden de magnitud, asi
que todo aquel que estuviera pensando bajarse peliculas DiVX o archivos mp3
de forma totalmente anonima, mejor que vaya olvidando la idea: tardaria
BASTANTE mas que con programas como edonkey.
Una solucion a esto consiste en el ya dicho uso de la cache, de forma que
este despilfarro de recursos solo debe darse en la primera peticion del
archivo. Tambien ocurre que si los datos estan en la cache de algún nodo
cercano, el número de saltos que hay que dar para llegar a los mismos se
reduce, reduciendose a su vez el impacto de la peticion en el resto de la
red. Pero esto depende de cúanto se pida el archivo, donde, a que otros
nodos este conectado nuestro host, etc. y nunca es una solucion mejor que
una conexion extremo a extremo.
2.4.2 La inundacion.
Otro malgasto de recursos se da debido a que, puesto que no conocemos el
host que contiene los datos que queremos, debemos inundar la red de
peticiones de forma que lleguen al host adecuado. Esta inundacion es
controlada por dos mecanismos: el tiempo de vida y la deteccion de bucles.
El tiempo de vida de un mensaje, al igual que en IP, es un contador que cada
nodo va decrementando al reencaminar dicho mensaje. Una vez llega a cero, el
mensaje se desecha y se envia una indicacion al nodo que inicio la peticion.
El problema ahora es que el nodo que la inicio no es conocido, de forma que
la única manera de llegar a el es seguir el camino inverso, enviando la
indicacion al nodo anterior, que la enviara a su anterior, etc. Entonces
estamos gastando muchos recursos tambien en mensajes de control, no solo en
los mensajes de datos. Pero esto es siempre mejor que dejar que un mensaje
inunde la red y nunca muera, consumiendo recursos de forma ilimitada y,
finalmente, saturando la red. Tambien hay que enviar indicaciones de que el
mensaje ha muerto al nodo inicial porque si no, nunca sabra que paso con su
peticion (y posiblemente la respuesta del mismo sea repetirla, con lo que se
inicia de nuevo el proceso de consumo de recursos). Ademas, el tiempo de
vida lo decide el nodo inicial, de forma que si este valor es muy alto, la
propagacion de la peticion puede llegar a ser brutal (recordar que en una
red en arbol el crecimiento del número de mensajes reencaminados es
exponencial).
La deteccion de bucles ocurre cuando un nodo recibe una misma peticion desde
dos nodos anteriores distintos. Esto ocurre porque hay un bucle en la red y
este nodo debe tirar uno de estos mensajes (y, por supuesto, no reenviar la
peticion a ninguno de estos otros nodos). En el modelo de freenet, la
deteccion de un bucle genera a su vez un mensaje de indicacion al último
nodo que realizo la peticion repetida, de forma que este sepa que la
informacion no va a encontrarse por ese camino (puesto que, si se encuentra,
se reenviara al nodo que envio primero la peticion duplicada). Nuevo consumo
de recursos.
2.4.3 La identificacion de datos.
Puesto que los datos pueden estar duplicados, nada impide a un usuario
malicioso contestar una peticion con datos que no sean realmente los
requeridos, sino con otros datos cualesquiera. Para evitar esto hay que
utilizar mecanismos de firma digital de los datos. Pero al final las claves
públicas para verificar las firmas deben estar almacenadas en algún servidor
"confiable", esto es, que sepamos quien nos esta dando estas claves. Por lo
tanto la red freenet no es autonoma y dependera de otras redes (por ejemplo
la World Wide Web) en las que los servidores no sean anonimos.
2.4.4 Las actualizaciones.
Si queremos publicar una version actualizada de un documento, nos
enfrentamos a un problema: existiran versiones antiguas del mismo circulando
por la red. ¿Como resolverlo? Mediante la firma digital podremos certificar
que somos el creador del documento inicial y que queremos actualizarlo,
enviando mensajes de actualizacion por la red para que todos los nodos que
contengan versiones antiguas las reemplacen por la nueva. El problema es que
es imposible asegurar que estos mensajes llegaran a todos y cada uno de los
nodos que contengan la version antigua del documento, y puede ser que haya
nodos que sigan manteniendo esta version aún tras la actualizacion.
Si estos nodos reciben muchas peticiones del documento, esta version antigua
puede ser replicada muchas veces aunque haya una version nueva. Incluso podria
ocurrir que, debido a que la version antigua sea mas facilmente accesible
que la moderna, esta última desapareciese "asfixiada" por la antigua. Para
evitar esto, las nuevas versiones deben inundar la red de mensajes de
actualizacion, volviendo de nuevo al problema del malgasto de recursos.
2.4.5 El software.
El último problema que voy a tratar se refiere a la implementacion real de
la red freenet, siendo los anteriores de tipo teorico y aplicables a
cualquier red de este tipo.
El problema de la freenet real es que esta implementada en Java. Supongo que
habra seguidores acerrimos de dicho lenguaje, pero como persona interesada
en el tema de las redes de ordenadores y el bajo nivel, personalmente creo
que sacrificar velocidad en favor de portabilidad para una red que ya de por
si es lenta no ha sido la mejor eleccion.
Ademas, existen problemas de compatibilidad del cliente/servidor freenet con
distintas maquinas virtuales Java (principalmente por ello aún no he podido
probarla personalmente, pero lo hare), lo cual me hace pensar en hasta que
punto es realmente portable un programa en dicho lenguaje. Bueno, esto es
cuestion de gustos.
2.5 Freenet en Internet.
Freenet es un proyecto software albergado en sourceforge (sourceforge.net),
es totalmente freeware y desde aqui os animo a que lo probeis. Como antes he
comentado, yo no lo he hecho porque paso bastante de Java y la maquina
virtual que tengo instalada es incompatible, asi que en cuanto tenga tiempo
y ganas me bajare una version compatible y hare mis pinitos en la red
anonima. Como antes he dicho, la web oficial de freenet en sourceforge es:
freenet.sourceforge.net
El cliente/servidor se arranca en nuestro host y permite conexiones
directamente, reencaminandolas hacia freenet. De esta forma, es posible
hacer una peticion desde el mismo navegador que usamos para la web, puesto
que el cliente/servidor actúa como una especie de proxy entre freenet y
nuestro navegador. Ademas es configurable para que sirva de acceso a otros
host (de forma que actúe como "portal" hacia freenet), pero esta forma de
uso no esta recomendada por los creadores, puesto que rompe con la filosofia
de "totalmente descentralizado" del proyecto, creando posibles
vulnerabilidades frente a ataque DoS contra estas "pasarelas".
Ademas, hay varios programas que permiten otras funcionalidades aparte del
acceso Web, como por ejemplo un chat totalmente anonimo. No puedo hablar
mucho sobre ellos porque no he podido probarlos.
3. Conclusiones.
Cualquiera que haya seguido el documento presente puede pensar que he dado
una imagen bastante negativa sobre la red freenet. Yo creo que no es asi.
Pienso que es una gran idea para ciertas cosas, pero que es una solucion
equivocada para otras.
Si lo que se busca es evitar la censura, me parece un mecanismo perfecto
para ello. La única manera de censurar contenidos seria prohibir la red,
cosa que no es imposible pero poco probable de momento. Si el aumento en el
número de usuarios es significativo y los intereses afectados importantes,
puede ser que eso ocurra.
Para el intercambio de informacion ilegal, bueno... Principalmente señalar
que no estoy a favor de la pirateria, pero tampoco en contra. Cada cual alla
con su conciencia. Personalmente prefiero el software libre, pero claro, hay
veces que esto no es posible... Desde luego, utilizar freenet para
distribuir de forma masiva cantidades ingentes de informacion (lease
peliculas, archivos mp3, etc.) me parece una idea un poco infantil, dado que
ya existen otros mecanismos mucho mas eficientes para ello. Para distribuir
informacion no muy extensa pero que puede ser censurada (lease insultos al
gobierno, etc. :-)) si es un buen metodo.
Pero para lo que me parece una solucion bastante eficaz y realmente útil es
para evitar ataques a seguridad. El nivel de seguridad una vez conseguido el
anonimato aumenta sorprendentemente (en cuanto a fallos del sistema se
refiere, no en cuanto a usuarios incompetentes en este aspecto). La proteccion
frente a los ataques DoS sobre todo aumenta de forma espectacular, tanto por
el anonimato como por la replicacion ("He visto cosas que vosotros humanos no
vereis jamas. He visto arder naves mas alla de Orion...") de la informacion.
Finalizando, un invento que habra que seguir de cerca y que, como tantos
otros en el mundo de la seguridad informatica, puede ser usado tanto para
fines buenos como para otros que no lo son tantos. Que ustedes lo disfruten
:-D.
Lindir.
*EOF*
