Serverless & Bullet-Proof Web Sites (1 de 2)

En este artículo me gustaría contaros una pequeña PoC que hicimos en el equipo de Ideas Locas que teníamos guardada para algún evento de Web3, pero que como tengo ganas de contárosla, he decidido hacerlo desde hoy. No es un estudio completo, ni mucho menos, porque el escenario es enorme, pero se basa en un idea muy sencilla, que es hacer Serverless & Bullet-Proof WebSites, capaces de soportar el intento de bloqueo o censura de cualquier entidad.

Figura 1: Serverless & Bullet-Proof Web Sites (1 de 2)

Esto no es algo nuevo, y la Serverless Web lleva tiempo estudiándose, y trabajándose con diferentes arquitecturas, todas ellas totalmente distribuidas.

Dust-RSS

Uno de esos ejemplos fue un proyecto personal del equipo de Ideas Locas, en aquel entonces en Informática 64, en aquel entonces del año 2010, y que presentamos en la RootedCON de 2011 y se llamó Dust-RSS.

Figura 2: Dust-RSS en su presentación en RootedCON 2011

La idea era muy sencilla, evitar la censura de los servidores RSS de los blogs para permitir que cualquiera que tuviera algo que comunicar lo pudiera hacer siempre, y para eso diseñamos una arquitectura muy sencilla, basado en claves PGP y una red P2P para hacer la distribución. Esto hacía que no hubiera un único punto de fallo en el servidor web, ni en el DNS, y que con tener la clave pública PGP del publicador se pudiera buscar por redes P2P las publicaciones. 

Figura 3: Demo de Dust RSS funcionando

De esta forma, el publicador lo único que debía conservar era su clave PGP privada para poder poner en la red P2P una nueva publicación. La arquitectura funcionaba, pero se quedó en una PoC que presentamos en DefCON 2012, y que se quedó como un bonito experimento.

OSIRIS SPS

Uno de las arquitecturas que buscaba solucionar estos problemas de censura de servidores Web se trataba de OSIRIS SPS (Serverless Portal System) y su Gateway ISIS, para poder publicar servidores Web que no dependieran de un único punto de fallo. Para ello, la solución era similar a tener a páginas web cacheadas y compartidas por una red P2P.

Figura 4: Foro de Anime publicado en Osiris SPS visible vía Isis Gateway

Las páginas web de los portales que se ven a través de esas URLs realmente no están en ningún servidor web concreto, sino distribuidos por toda la red P2P de Osiris SPS, lo que impediría un bloqueo o censura del sistema. Es perfecto para crear foros y portales de denuncia social que no puedan ser quitados de Internet si no quieren sus usuarios.

DeepWeb: TOR, I2P, FeeNet, Hyperboria, CJDNS

Todas estas soluciones no accesibles a través de los navegadores de "superficie", son consideradas redes de la DeepWeb, no solo porque no son accesibles con las herramientas más comunes de Internet, sino porque además cuentan con herramientas y protecciones contra el control, ya sea cifrados especiales o como hemos visto, para evitar el bloqueo de sus contenidos, como en el caso de OSIRIS SPS o el sistema DUST RSS que utiliza mecanismos P2P para ello.  q

Figura 5: Libro de Deep Web: TOR, FeeNEt & I2P.  Privacidad y Anonimato 
de Daniel Echevarry a.k.a. "adastra" en 0xWord.

Por supuesto, muchas de las funciones de seguridad que se buscan en estas redes, están en las más conocidas de la DeepWeb como son  TOR, FreeNET e I2P, donde el cifrado de las comunicaciones es una de las claves en todas ellas.

Figura 6: Arquitectura de conexión CJDNS para la red Hyperboria

Pero la búsqueda de arquitecturas distribuidas y seguras ea algo que se ha estudiado mucho, como el caso de CJDNS y su red Hyperboria con conexiones cifradas y certificadas sobre IPv6, GNUNet, Lantern, YaCy para conseguir que no puedan ser accesibles los contenidos por nadie.

Malware en BlockChain

Por supuesto, pensar en arquitecturas Serverless y Distribuidas, es hablar del core de las cadenas de bloques de BlockChain, y utilizar las capacidades que tiene para poder almacenar datos de forma permanente y protegida con la distribución por diseño que tiene esta tecnología.

Figura 7: PoC de C&C con OP_Code en cadena de BitCoin

propuesta por Yaiza Rubio y Felix Brezo en EuskalHack 2017

En la EuskalHack del 2017, Felix Brezo y Yaiza Rubio hacían una demostración de cómo se podrían almacenar comandos de un C&C de una Botnet de malware en el campo OP_CODE la cadena de bloques de BitCoin.

Figura 8: Libro de "Bitcoin: La tecnología Blockchain y su investigación"
de Yaiza Rubio y Félix Brezo en 0xWord

Esto, al precio que está hoy el BitCoin parece un poco caro, pero esta idea de usar la cadena de OP_CODE para hacer servicios no es nueva, y algunos proyectos lo han utilizado en el pasado, aunque co la proliferación de cadenas de bloques a precios mucho más más económicos, hace que ya no sea necesario centrarse en ese campo.

Figura 9: Análisis del malware de Etherhiding

Y como muestra de esto lo hemos tenido con el caso del malware de Etherhiding, donde el binario del malware se han escondido dentro de la cadena de Binance Smart Chain, y ha utilizado SmartContracts para actualizarse.

Redes Sociales Descentralizadas

Por supuesto, la explosión de las cadenas de Blockchain, y otras arquitecturas distribuidas, hayan ido apareciendo en todos los verticales tecnológicos nuevos servicios que pretenden ser más resistentes contra los ataques a servicios descentralizados, como son las Redes Sociales.

Figura 10: Yo tengo mi curenta en Mastodon

Ahí, propuestas como Mastodom, Diaspora, Matrix, Block Square, que son sólo una pequeña muestra, han ido apareciendo por todos los rincones de Internet, y se han convertido en parte de la transformación y disrupción que se está viviendo en este mundo de las redes sociales.

Figura 11: Red social Diaspora 

Pero la descentralización de todos los servicios digitales que se están construyendo hoy en día. Algunos que se han hecho piezas fundamentales en las arquitecturas Web3, como el almacenamiento IPFS (Inter Planetary File System) del que ya hablamos.

Y esto nos lleva a nuestra PoC, que es cómo aplicar todas las arquitecturas al servicio fundamental de la web, y que como veremos es rápido y sencillo, pero será en la segunda parte de este artículo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Blockchain & Smart Contrats: El Internet descentralizado y el almacenamiento Off-Chain con IPFS

Durante la serie de Smart Contracts y Blockchain hemos visto diferentes maneras de descentralizar parte de la lógica de una aplicación, pero los Smart Contracts y la tecnología Blockchain no son la única manera de hacerlo. En sus inicios Internet podría haberse considerado descentralizado puesto que solo corría en algunos ordenadores distribuidos por unos pocos garajes y salas de universidades del mundo. Con el paso de los años y la creación de centros de datos y la llegada del “Cloud Computing” Internet se ha ido centralizando hasta hoy día en el que un par de empresas prácticamente poseen Internet.

Figura 1: Blockchain & Smart Contrats: El Internet descentralizado

y el almacenamiento Off-Chain con IPFS

Con el resurgimiento de la tecnología Blockchain en 2013 volvió la idea de descentralizar Internet, para tener así una red mundial resistente a la censura en el que los dueños de los datos tuvieran el control de verdad sobre ellos. Y desde entonces se han dado grandes avances como el surgimiento de redes sociales descentralizadas y Open Source, protocolos para la descentralización de internet como el proyecto DUST-RSS para usar PGP e P2P para tener blog serverless sin censura, los portales web serverless distribuidos con Osiris SPS o el archi-famoso hoy en en día IPFS que vamos a ver en esta serie

Redes sociales descentralizadas

Está claro que el paradigma de hoy día que siguen la mayoría de redes sociales es el de la WEB2.0 un modelo en el que rige la centralización y el comercio de los datos del usuario, en el que esté casi no tiene ningún control sobre cómo se maneja su propia información. En la actualidad tenemos el paradigma de WEB3 en el que gracias a la tecnología Blockchain y a los Smart Contracts pueden crearse “fácilmente” plataformas descentralizadas. Sin embargo no ha sido del todo necesaria esta tecnología para crear redes sociales de este tipo véase el ejemplo de las siguientes, de las cuales algunas incluso surgieron antes que los smart contracts.

● Mastodon: Esta red social es totalmente Open Source además claro de ser descentralizada dada la arquitectura que tiene. La estructura que sigue es muy parecida a la de nodos entrelazados además de que implementa el protocolo Activity Pub, un protocolo open source para la descentralización de servicios.

Figura 2: Página web de Mastodon 

En esta red cada nodo puede ser alojado en un servidor normal o en tu mismo pc y da igual al nodo que te conectes, ya sea un gran servidor o tu propio ordenador estarás conectado con todos los demás.

● Diaspora: Surgió alrededor de agosto de 2012, aunque sus creadores empezaron con ello en 2010. Sus tres ideas claves como medio de conexión social son: libertad, descentralización y privacidad(donde tú eres el dueño de tus datos), asimismo también es Open Source (repo). 

Figura 3: Red social Diaspora 

 

Para lograr su descentralización siguen una arquitectura similar a la de Mastodon, solo que en este caso en vez de usar nodos usan pods, que son servidores auto alojados a la hora de ejecutar la app.

● Matrix: Fue creada en 2019 y se definen a sí mismos de la siguiente manera “Matrix is an open source project that publishes the Matrix open standard for secure, decentralised, real-time communication.”

Figura 4: Representación gráfica del funcionamiento de Matrix

Proveen de un gran SDK para desarrolladores con el fin de que estos creen diferentes apps y web que funcionen sobre su infraestructura, la cual es descentralizada también y que funciona de manera similar a los nodos de la blockchain en los que se va replicando toda la información en tiempo real.

● Block Square: Hace unas semanas Jack Dorsey dejó su puesto de CEO de Twitter por continuar su proyecto personal, en su momento se llamaba Square y tenía como objetivo ser una red social descentralizada que ofreciera servicios SaaS.

Figura 5: Logo de las empresas Square y Block

Pero ahora con su salida de Twitter ha surgido Block que será un conglomerado tecnológico que aúne Square, Cash app, Spira y Afterparty con su reciente adquisición para poder operar transacciones en Europa.

Almacenamiento Descentralizado

Si has leído alguno de mis anteriores artículos sobre Smart Contracts sabrás que a la hora de crear uno es muy importante optimizar al máximo posible el almacenamiento que va a utilizar puesto que existen unos límites que no son rebasables y todo aquello que se almacena en la Blockchain tiene un coste y no suele ser bajo.

• Blockchain & SmartContracts: Una serie para aprender
• BlockChain & SmartContrats: Primer SmartContract con Solidity
• Blockchain & SmartContracts: Cómo probar y desplegar un SmartContract en Ethereum
• WWW, Web 1.0, Web 2.0, Web 3.0, Web3 y ¿Web 4.0?
• Metaverso, multiverso y las tierras digitales en que vivimos en forma de avatar
• Los Fan Tokens vs. las Criptomonedas y los NFTs: Level 101
• Tokenomics: Las criptomonedas y las "Proof-of-work": Level 101
• Los NFTs y el registro mundial de los dueños de activos digitales en el Metaverso
• BitCoin: Blockchain y su investigación
• BlockChain & SmartContrats: El Internet descentralizado y el almacenamiento off-chain en IPFS
• Reentrancy Attack: Cómo te roban criptomonedas por un bug en tu SmartContract
• BlockChain & SmartContract: Bugs que pueden dejar tu SmartContrat "fuera de juego"
• Blockchain & SmartContracts: Patrones y buenas prácticas de seguridad
• Blockchain & SmartContracts: Herramientas de Auditoría de Seguridad de SmartContracts
• Blockchain & SmartContracts: Herramientas de análisis de código estático

Teniendo esto vemos que es prácticamente imposible montar una red social completamente descentralizada en la que todos los datos se guarden en la propia Blockchain y si aun así fuera posible a día de hoy los costes serían inasumibles.

Figura 6: Entender e investigar BlockChain & BitCoin
de Felix Brezo y Yaiza Rubio en 0xWord

Por ello existen soluciones Off-Chain (fuera de la propia cadena de Blockchain) que se encargan de almacenar datos de manera descentralizada asegurándonos que los archivos subidos son inmutables. Permitiéndonos así delegar parte del almacenamiento a otros servicios que no sean la Blockchain sin tener que romper los principios de la descentralización en nuestra aplicación.

IPFS (Inter Planetary File System)

Un buen ejemplo de almacenamiento Off-Chain es IPFS o "Inter Planetary File System", un sistema que permite guardar archivos en su red descentralizada para que estos estén siempre accesibles. En el sitio web oficial se definen como:

“A peer-to-peer hypermedia protocol designed to preserve and grow humanity's knowledge by making the web upgradeable, resilient, and more open.”

A un alto nivel cuando se sube un archivo al sistema este separa tu archivo en pedazos más pequeños y a cada uno le asigna un identificador único después a cada uno lo envía a diferentes nodos de la red que se encargaran de almacenarlos.

Figura 7: IPFS - Internet Planetary File System

Cuando se requiera un archivo del sistema este pedirá a los diferentes nodos que envíen las diferentes partes que almacenan con el identificador único que antes nos dio. Además cuando un nodo descarga u observa un fichero al completo lo copia y lo cachea para que así próximas veces el archivo esté disponible más rápidamente. Luego cuantas más veces sea accedido un archivo más rápidamente estará disponible desde los diferentes nodos de la red, con lo que se crea una especie de servicio CDN (Content Delivery Network) en el que los archivos más “populares” son aquellos serán más rápidamente accesibles.

Figura 8: Estructura de almacenamiento

Los archivos una vez subidos a la red son inmutables y por lo tanto resistentes a la censura y al cambio. Y lo más interesante aún es que para subir un archivo a la red simplemente hay que correr su programa en el ordenador o utilizar algún servicio como Infura que nos cobrará 0.2 dólares/GB. Estas son unas sumas ridículas si la comparamos con la cifra de 76.000 dólares/GB que cobra Ethereum a día de hoy.

Figura 9: El almacenamiento distribuido de IPFS

Por supuesto, esta es una explicación del funcionamiento de IPFS hecha de una manera muy abstracta y a alto nivel, para aquellos que queráis entender más en profundidad cómo funciona el sistema os dejo aquí el enlace del whitepaper original de IPFS. Hoy día cada vez son más los protocolos y redes como IPFS que facilitan la descentralización de las aplicaciones y sus datos pero aún falta mucho camino y tecnologías para que internet pueda ser descentralizado pero quién sabe qué nos deparará el futuro ;)

Figura 10: Whitepaper de IPFS (Draft 3)

Si tenéis cualquier duda con algo de estos artículos sobre el mundo de la Web3 estaré encantado de responderos tanto en mi perfil de MyPublicInbox como en mi cuenta de Twitter (aparece en mi perfil de MyPublicInbox). Nos vemos en los siguientes artículos.

Autor: Chema Garabito. Desarrollador Full-Stack. Ideas Locas Telefónica CDO.

Figura 11: Contactar con Chema Garabito en MyPublicInbox

Hay otro Internet en las Wireless Meshnets: De Hyperboria a Freifunk pasando por B.A.T.M.A.N. o MeshBerry

Muchas veces, cuando se habla de la Deep Web se tiende a pensar que esta es lo mismo que TOR, y ni mucho menos es así. La Deep Web es un concepto mucho más genérico que habla de aquellos contenidos que no se encuentran accesibles por los canales de flujo masivo de conexiones, como son los buscadores como Google, Bing, o los grandes centros de compartición de información, como son Facebook, Twitter, Youtube, etcétera.

Figura 1: Hay otro Internet en las Wireless Meshnets

El concepto de Deep Web viene de un artículo publicado en el año 2001 en el que se ahonda en la dificultad de localizar aquel contenido que está fuera de los sistemas masivos de indexación, catalogación y búsqueda. Desde páginas web que quedan en el índice secundario de Google, hasta contenido que se encuentra almacenado en redes que necesitan de software especial de conexión, o lugares en los que son necesarias credenciales de acceso.

Figura 2: Artículo del año 2001 que introduce el concepto de Deep Web

En esta catalogación, por supuesto, entra la red TOR, las redes FreeNet o I2P, pero también una gran cantidad de redes P2P - donde yo ideé mi Dust-RSS, redes serverlesss como ISIS & OSIRIS, o la cada vez más popular red CJDNS y su famosa Hyperboria.

Figura 3: Charla en RootedCON 2011 sobre DUST-RSS

A lo largo de este tiempo, las comunidades han seguido desarrollando ideas para crear redes propias, fuera de los canales tradicionales, con diferentes arquitecturas descentralizadas, tal y como funciona TOR o CJDNS. En el año 2014, en las famosas conferencias HOPE (Hackers On Planet Earth) de New York, se impartió una charla sobre cómo estas redes podían hacerse a nivel local con la proliferación y abaratamiento de conexiones Wireless.

Figura 4: Wireless Meshnets

En esa charla se habló del proyecto NYC Mesh, una red comunitaria en la ciudad de New York para conectarse sin necesidad de contar con una infraestructura concreta. Dicha red se crea con la unión de nuevos nodos a la misma que configuran protocolos especiales de encaminamiento que permiten la conexión entre ellos de manera dinámica. Para ello, utilizan una distribución con todo lo necesario para conectarse en una distribución de Raspberry Pi a la que llaman Meshberry.

Figura 5: Meshberry v0.2 en NYC Mesh

Uno de estos tipos de redes comunitarias, descentralizadas, y disponibles para cualquiera que quiera ser parte de ella, es Freifunk, muy popular en Alemania y que se basa en el protocolo de enrutamiento B.A.T.M.A.N. (Better Approach To Mobile Ad-hoc Networking), que resuelve el problema de envío de los paquetes en una red cambiante, descentralizada y móvil en la capa 2.

Figura 6: Vídeo que explica el concepto de las redes Freifunk

Llegué a esta red por casualidad, revisando unos mapas que mi amigo rootkit me había enviado, donde se puede ver de forma abierta todo lo que está pasando en cada una de estas redes Freifunk desplegadas por las diferentes regiones de Alemania.

Figura 7: Gráfico de una de las redes Freifunk en Alemania. Está bien nutrida

No es que me guste especialmente, pensando en la privacidad, que se puedan ver las conexiones con direcciones MAC de muchos de los equipos que están haciendo uso de ella desde una web, pero supongo que los que utilizan estas redes ya deben saber cambiar la dirección MAC, además de otras medidas de privacidad.

Figura 8: Región de Alemania cubierta de redes Freifunk

Lo bueno de utilizar una red como Freifunk, es que también te puedes conectar a Internet, lo que permite que, por ejemplo desde una conexión a la red Freifunk hagas uso de una conexión a la red TOR para contar con una capa extra de anonimato.

Al margen del uso que le quiera dar cada uno a este tipo de redes, desde el punto de vista técnico, es precioso ver cómo se siguen creando nuevas tecnologías día a día, y se consiguen proyectos de gran utilidad para muchas personas a base del esfuerzo y el conocimiento de unos pocos. Hay otro Internet fuera del mainstream.

Saludos Malignos!

Vídeos de (casi) todas mis charlas en el canal YouTube

Hace cosa de un mes comencé a recuperar algunas de las charlas que he ido dando a lo largo de los últimos años. Es un trabajo arduo porque muchas tienen más de 10 años, y no las encuentro por ningún sitio, pero al menos he recuperado una buena cantidad de ellas, y las he consolidado en mi canal Youtube.

Figura 1: Hay más de 120 vídeos en el canal

Para que sea más fácil de localizar una charla, las conferencias completas, o los programas y documentales de televisión en los que he participado, los he clasificado en algunas listas por años y por temas. De momento he subido conferencias desde el 2007.

Figura 2: Listas de vídeos por años, programas de TV y charlas en inglés

Seguiré recuperando todas las conferencias que pueda, para dejarlas ahí. La primera charla de Black Hat 2007 sobre LDAD Injection & Blind LDAP Injection aún no la he localizado, pero tienes las primeras charlas de FOCA, de Connection String Parameter Pollution, de Time-Based Blind SQL Injection using heavy queries, de Evil FOCA, de DUST RSS, etcétera, etcétera por allí.

Saludos Malignos!

DEF CON me gusta mogollÓN

La primera vez que fui a Defcon era la edición número 16, y llegué muerto de miedo. Estuve semanas enteras preparando la charla sobre Time-Based Blind SQL Injection & Marathon Tool, porque el lugar me daba todo el respeto que merece dicho evento.... y me lo pasé genial, y estuve arropado por un montón de amigos.

Al año siguiente en la Defcon 17 fui con mi amigo Palako, a hablar de Tactical Fingerprintng using Metadata, Hidden Info and Lost data, y a sacar a pasear la FOCA, en una charla que creo nos quedó como nunca. Recuerdo que no salí tan satisfecho de una charla nunca. Trabajar con Palako en aquella charla fue una pasada, y creo que en su memoria también estará ese buen recuerdo. En la mía, nunca se borrará el incidente por el que casi acabo en la cárcel.

En Defcon 18 repetí con Palako, después de haber pasado por la Yahoo! Security Week y volvimos a hablar de FOCA en este caso la versión 2 "The FOCA Strikes Back", donde fue genial ver que teníamos a la gente del año pasado y se acordaban de los chistes del anterior. A día de hoy, cuando Moxie Marlinspike me encuentra por cualquier conferencia del mundo, le oigo decir eso de "FOCA is working, FOCA is working...".

Este año, también nos animamos a impartir otra charla, en este caso la de Connection String Attacks, donde hablamos de Connection String Parameter Pollution y sacamos a pasear el CSSP Scanner. Creo que también nos quedó chula, aunque el comentario del final casi me cuesta un disgusto...


En Defcon 19, el año que ganamos el triplete [Eurocopa, Copa del Mundo y HackCup], primero hablé sobre DUST: Your RSS Feed Belongs to you, en un sitio donde no tenía todas conmigo de que el tono de la charla fuera a ser entendido.


Después, en esa misma edición de Defcon, acompañado por Juan Garrido "Silverhack", hablamos sobre Bosses Love Excel, Hackers Too, en una charla en la que Juan y yo trabajamos lo indecible. Puede que parezca que todo es muy sencillo, pero entender todas las políticas, las versiones, y afinar las demos nos llevó al trianero y a mí horas y horas y horas de trabajo, pero el resultado fue muy satisfactorio, y he de reconocer que después de ya varias charlas en Defcon, me sentí muy cómodo en el escenario en todo momento, aunque me pasé todo el tiempo trabajando.

Ahora, la charla de Owning Bad Guys {and mafia} with JavaScript Botnets que dimos en la Rooted ha sido seleccionada para la Defcon 20 (parece que ya es costumbre eso de presentar primero en RootedCON lo que luego haremos en Defcon), y la verdad es que estamos muy contentos. Creo que el espíritu de esa charla encaja mucho con el espíritu de Defcon [version No Lusers]

Actualización: Esta es la versión de la charla que impartí en Defcon XX


Y la versión final de la que impartí en DEFCON XXI.


Y claro, ya que vamos... habrá que volver a ganar la HackCUP, ¿no? ¿Quién se viene a la Defcon este año? ¿Quién quiere jugar en el FOCA Team? Amigos argentinos: Nico, Fran, Fede, Mariano, Eze, Hernán, Claudio, y compañía ... Fear the FOCA!

Saludos Malignos!

DUST: Manual de Usuario (IV de IV)

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************

Pidiendo clave pública

¿Por qué se pide la clave pública PGP si para firmar sólo hace falta la clave privada? La respuesta es que para poder calcular el hash SHA-1 de la misma y darle nombre al fichero del feed RSS firmado que se genera es necesaria. Aunque esta clave pública se puede sacar del keyring asociado a la clave privada, en una primera implementación con la API de java.security esto no era posible. Actualmente está siendo utilizada la API de The Bouncy Castle Legion y podría omitirse este paso, pero aún no está implementada esa parte del código.

El proceso de publicación completo se puede seguir desde la ventana de log que tiene la aplicación, en la que se puede observar cómo se dusterizan tanto el feed RSS como las imágenes asociadas.

Figura 18: Log después de la publicación de un feed RSS con Dust

Detalles a tener en cuenta para la publicación por P2P

Como ejemplo y ayuda para realizar la publicación del blog, para extraer la clave secreta (contenedor de la clave privada y pública) con gpg sería de la siguiente manera:

$ gpg -a -o secret.pem –export-secret-keys

En la lista de blogs que mantiene Dust se puede ver que los posts pueden tener al lado dos tipos de iconos, uno de canal RSS y otro de un disco duro. Además cuando se selecciona un post, en la parte superior del contenido se puede ver la propiedad State que estará con valor “RSS” o “Saved”. Dust mantiene todos los posts que han existido en un blog, sin embargo sólo maneja el feed RSS más actual. Este feed RSS puede contener menos posts que todos los que ha habido alguna vez en el blog, normalmente los últimos 5, 25, 30, etc...

Cuando se publica un blog, lo que realmente se está publicando es el feed RSS actual, es decir el último feed que se obtuvo de dicho blog, y por lo tanto los posts contenidos en él, no todos los posts del blog.

También se puede observar que si un posts está en estado “Saved” se tiene la opción de borrarlo, mientras que un post en estado “RSS” la tiene deshabilitada.

Nodos GNUTella

Actualmente Dust está preparado solo para trabajar con la red P2P GNUTella, la cula, debido a su arquitectura totalmente descentralizada, hace que sea necesario conocer al menos un peer para conectarse a ella.

En la carpeta de configuración de Dust - carpeta conf/ - se encuentra un fichero peers.txt, el cual contiene o contendrá la lista de peers en la red que conocemos. En los paquetes con los que viene este manual el fichero contiene comentado el peer de Informatica64. Tendríamos que añadir a este fichero todos los peers que vayamos conociendo para hacer con Dust una red lo más robusta y grande posible.

Dust utiliza el puerto 6346 para el agente de GNUTella que incorpora. También utiliza el puerto 31337 para un pequeño servidor de ficheros para la compartición de los archivos necesarios en la publicación de los feeds RSS. Es por eso necesario tener en cuenta que estos puertos están permitidos y habilitados en el firewall para que funcione correctamente el proceso de comunicación de los feeds RSS.

Paquetes de DUST

Para que podáis probar Dust, he puesto disponibles los compilados para arquitecturas Linux X86 y Windows x86 que son los que utilizamos en la presentación de DUST en Defcon 19. Las descargas están disponibles en la sección downloads de la web del proyecto.

Figura 19: Paquetes de Dust para arquitecturas x86

Estado actual de DUST

Actualmente DUST no está siendo evolucionado debido a que hay poco tiempo y recursos para trabajar en él. En el futuro nos gustaría que algún grupo, con base en la Universidad o en alguna organización, pudieran continuar y evolucionar el proyecto, así que estaríamos encantados de entregar el testigo de este proyecto a gente que crea que puede invertir tiempo en su evolución y mantenimiento.

Figura 20: Proyecto DUST busca cuidadores

Si quieres trabajar con DUST, ponte en contacto conmigo y vemos cómo hacerlo.

Saludos Malignos!

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************

DUST: Manual de Usuario (III de IV)

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************

Añadir clave púbilca PGP a un blog (continuación)

Así, una vez creada, basta con seleccionar el fichero donde se ha guardado la clave pública que hemos visto cómo se generaba en el apartado anterior

Figura 11: Selección del fichero de la clave pública PGP

Ahora, si se mira la información del blog al que estamos suscritos, no solo habrá fuentes redundante Http, sino que también habrá una fuente redundante P2P con una clave Pública PGP.

Figura 12: Fuentes de datos para el blog al que estamos suscritos

A partir de este punto, cuando Dust actualice el blog buscará feeds tanto en las URLs especificadas cómo ficheros en la red P2P que contengan en el nombre el hash SHA-1 de la clave pública asociada. Se descargará esos ficheros y comprobará si están firmados por la clave privada asociada a esa clave pública. En tal caso actualizará el blog con los nuevos posts y buscará también las imágenes referenciadas por los posts. En la opción de Log podemos seguir una traza de todo lo que Dust va haciendo.

Figura 13: Log de actividad en Dust

En la Figura 13 se puede ver cómo se ha intentado una actualización después de añadir la clave pública PGP a las fuentes del blog y que encuentra contenido por ambas URLs y, de momento, nada por P2P. Podemos apreciar que se busca una cadena de caracteres hexadecimales, esta cadena es el hash SHA-1 de la clave pública PGP.

Publicar un blog por P2P con Dust

Para que los usuarios que tienen asociada una clave pública a un blog reciban contenido de ese blog por la red P2P, es necesario que el dueño de la clave privada PGP asociada a esa clave pública de suscripción (éste puede ser el blogger original o terceras partes) publique el blog desde Dust. Este proceso realiza los siguientes pasos:

1.- Descarga las imágenes asociadas al feed actual.
2.- Firma cada imagen con la clave privada.
3.- Cambia el nombre de la imagen por el del SHA-1 de la URL de la imagen, que se obtiene del atributo src de cada img tag del contenido del post que la referencia.
4.- Guarda el fichero con la imagen generada en el directorio shared/ con nombre {hash}.{extension original}.asc
5.- Modifica el feed. Borra los atributos src de todas las imágenes y añade/modifica el atributo alt a los img tags de cada post para que contengan una referencia a la red donde buscar y la cadena a buscar.
6.-Firma el feed con la clave privada.
7.-Guarda el fichero feed firmado en shared/ bajo el nombre {canal}-{timestamp de la creación}-{hash de clave pública}.xml.asc

¿Por qué se le dan nombres tan raros a las imágenes? Era un método cómodo para evitar colisiones en el nombre del fichero, salvo que sea la misma imagen.

¿Por qué se le pone al feed el hash de la clave pública, no bastaba con el nombre del canal?. Es una forma de discriminar ficheros del mismo canal pero firmados por distintos autores. Quizás a alguien le interesa suscribirse a un blog que tiene canales de publicación X, Y y Z, cada uno con su clave pública, pero a otro solo interesa sólo suscribirte a lo que se dice en el blog por Y. En este caso sólo asocias a tu suscripción la clave pública de Y, de forma que las búsquedas por P2P sólo devolverían lo que firma Y y no lo que firman X y Z.

¿Por qué se modifica el feed a la hora de publicar? Se añade o modifica a las imágenes el atributo alt para que cuando alguien descargue ese feed pueda también buscar y descargar las imágenes relacionadas. El atributo src se borra debido a que a la hora de (re)publicar no se tiene en cuenta si el feed que se (re)publica se obtuvo a través de HTTP o de P2P. En el caso de un feed que viene por P2P, una vez descargado, se modifica el valor src de las imágenes para que apunten a la ruta local donde estarán esas imágenes cuando se descarguen. Es por ello que hace falta eliminar el valor de src al publicar, para evitar publicar en Internet el espacio de nombres de tu sistema de ficheros, ya que podría contener algo como “C:\Users\{tu usuario}\...” o “/home/{tu usuario}/...”.

Para publicar un blog tenemos que darle a la opción Publicate blog del menú emergente de un blog. A continuación irán apareciendo tres cuadros de diálogo. En el primero se especifica el archivo donde se encuentra contenida la clave privada PGP que se usará para firmar. En el segundo se introduce la contraseña para acceder a la clave privada. En el tercero se pide la clave pública PGP asociada a esa clave privada.

Figura 14: Opción de publicar el blog

Figura 15: Selección de clave privada PGP

Figura 16: Contraseña de acceso a la clave privada PGP

Figura 17: Selección de fichero que contiene la clave pública

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************

DUST: Manual de Usuario (II de IV)

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************

Añadir fuente HTTP

Como ya se ha comentado, la idea de Dust es tener fuentes redundantes para intentar evitar la censura y el corte de la conexión entre publicador y audiencia - a la par que se consigue un mayor grado de disponibilidad de la fuente de información RSS. Si tenemos un blog que tiene varias fuentes RSS en servidores HTTP donde se publican de forma redundante sus feeds, podemos añadírselos a Dust haciendo clic con el botón derecho sobre un blog al que ya estemos suscrito y pulsando en la opción de Add a new HTTP source. En el cuadro de dialogo se introduce la URL en la que está ubicado el fichero XML de la fuente y listo.

En este caso vamos a añadir como ubicación alternativa de los feeds RSS la fuente “http://feeds.feedburner.com/ElLadoDelMal” al canal que ya habíamos creado con una fuente local.

Figura 7: Añadiendo fuente redundante Http al canal del blog

Esto lo que provoca es que, cuando se intenta actualizar un blog, Dust descargará los feeds de todas las fuentes asociadas a un blog. Si encuentra posts nuevos en cualquiera de esas fuentes que no tenía antes entonces añade los nuevos post. Esto da más libertad de la que parece, ya que podemos incluso “unir” varios blogs en uno o seguir al día un canal aunque alguna de las fuentes esté caída o boqueada.

Por ejemplo si añadimos al blog de “El lado del mal” que usamos antes de ejemplo, la fuente “http://feeds2.feedburner.com/SecurityByDefault”, lo que vamos a acabar teniendo es la mezcla de “El lado del mal” y “Security by default”. Se puede también tener una misma fuente para más de un blog, con lo que tendríamos post repetidos por distintos blogs. A partir de aquí lo que a uno se le ocurra.

Actualizar un blog

Dust intenta actualizar los blogs a los que está suscrito cada hora y nada más arrancar, pero si queremos forzar a una actualización inmediata podemos hacer clic con el botón derecho sobre el blog y darle a la opción de Update this blog. Dust se conectará a todas las URLs fuentes de ese blog y también tratará de buscar a través de la red P2P si tiene asociado para ese blog alguna clave pública, como veremos más adelante en este manual.

Figura 8: Actualizando el blog de manera manual

Figura 9: Nuevos posts después de actualizar con todas las fuentes redundantes

Añadir clave pública PGP a un blog

Las claves públicas PGP asociadas a un blog se utilizan para realizar la búsqueda de nuevos feeds a través de redes P2P. La idea es que los bloggers deben poner disponibles sus claves públicas de los blogs, que deberán ser obtenidas por los lectores de los blogs, con las que van a firmar la distribución de sus feeds RSS por redes P2P.

La distribución de las claves públicas PGP de los blogs no es algo que realice Dust, por lo que deberá hacerse por canales tradicionales de "confianza", es decir, que deberá ser compartida desde el publicador al lector siguiendo una cadena de confianza.

En el mejor de los casos, cuando hablamos de un blog, éste podrá compartir sus claves públicas en sus primeros posts, asumiendo que en ese momento no está bajo censura, con lo que comienza el germen de la cadena para que otros lectores las compartan. También se podría hacer uso de servicios de publicación de claves públicas de blogs, como listas en la web, o ficheros compartidos por redes P2P en los que circulen las claves públicas  PGP de publicación de los blogs que hacen uso de este servicio, etc...

La idea es que el feed RSS de un blog será firmado por una clave PGP por el autor - o cualquier publicador - y será puesto en una red P2P. Dust buscará, como fuente alternativa redundante, un feed RSS firmado con una determinada clave pública PGP para actualizar su canal del blog.

Para ello es necesario asociar la clave pública PGP de un blog a Dust haciendo clic con el botón derecho sobre el blog y seleccionar la opción Add a new public key source. Con esto, cuando se realicen actualizaciones del blog, se buscarán no sólo los feeds RSS en las URLs HTTP que se tienen como fuentes del blog, sino también se hará una búsqueda por las redes P2P buscado feeds RSS firmados con esa clave pública PGP.

Figura 10: Añadir una clave PGP de lectura de un blog

Generación de claves para ser usadas en Dust

Las claves públicas PGP que se asocian a Dust pueden estar en formato binario o con armadura (PEM), para profundizar en ello debes consultar la documentación del programa de generación de pares de claves PGP que estés utilizando.

Como ejemplo, los pasos que se han seguido para obtener la clave que se va a utilizar en los ejemplos  de la siguiente parte se ha generado mediante el uso de la utilidad gpg haciendo uso de los comandos:

$ gpg --gen-keys

Seguir los pasos del asistente rellenando la información apropiada.

$ gpg -a -o ole-public.pem --export

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************

DUST: Manual de Usuario (I de IV)

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************

Tras los recientes acontecimientos de la famosa ley SOPA y el cierre de Megaupload creo que es momento de empujar un poco más el Proyecto DUST. La idea del porqué del nacimiento de DUST RSS ya los dejé publicada en el artículo DUST: Tú feed RSS es tuyo, y tenéis el vídeo de presentación de DUST en la RootedCON 2011 y en inglés también DUST en Defcon 19.

El proyecto se programó en Java, y por eso muchos no habéis encontrado la "Release" del mismo en la web del proyecto DUST en CodePlex, pero está disponible desde Agosto de este año allí. Solo tenéis que ir a la parte de Source y descargar el código - el proyecto es totalmente Software Libre con licencia Apache 2.0 - y correrlo en vuestra máquina.

Figura 1: Código fuente de DUST en CodePlex

No lo había empujado más por que se tienen que limar muchos flecos, y no es más que un prototipo que puede dar problemas con algunos formatos de feed o codificación no testeadas, pero el código ya está disponible y si alguien se anima a colaborar con él, empujarlo o transformarlo en algo que tenga el mismo espíritu que se ponga en contacto conmigo.

Ole (David Luengo López), estuvo realizando la codificación de DUST en Java en el SOCtano de Informática64, y éste es un manual de usuario de la versión que tenéis disponible, para que podáis empezar a probarlo y utilizarlo desde ya.

Qué es Dust y qué no es

Dust es un lector de RSS. Su objetivo es que lo usemos para ver los posts de nuestros feeds favoritos de forma centralizada. Lo novedoso es la capacidad que añade para darle redundancia a estos feeds. Dust puede mantener un blog que tiene múltiples fuentes HTTP, esto es que el feed de dicho blog está replicado en varias URLs. De esta forma se dificulta la posibilidad de que una entidad (empresa, gobierno, etc...) pueda cerrar de manera directa un blog mediante el bloqueo de la URL del feed, ya que se deberían cerrar todas las URLs que contienen el feed del blog (bastante más complejo si el hosting está en distintos países). Aunque algunos de estos feeds se encuentren desactualizados Dust es capaz de manejar de manera inteligente esta casuística.

Pero la parte más novedosa (y a la vez compleja) de Dust es que permite a los usuarios publicar y republicar los feeds a través de redes P2P (actualmente a través de GNUTella, en el futuro esperamos añadirle soporte para más redes). Esta publicación se hace firmando tanto el feed como las imágenes con claves PGP, de forma que cuando algún usuario encuentre un feed actualizado por la red P2P y se descargue el archivo pueda confirmar que dicho feed (o imagen) ha sido publicado por una persona de confianza, bien uno de los autores del blog que ha publicado el feed con Dust, bien un mediador de confianza para ese cliente y que ha republicado el feed.


Demo de Dust funcionando

Dust en ningún caso pretende ser una herramienta de criptografía, sino que se apoya en ellas para su cometido (firma y verificación de feeds e imágenes). Las claves PGP que Dust requerirá deberán generarse con terceras herramientas destinadas a ello (por ejemplo gpg).

Dust no es un editor de feeds. No se pretende que un blogger pueda escribir sus posts desde Dust, darles formato, etc... Sino que una vez creado su feed, lo importe con Dust y lo publique. Dust es Software Libre publicado bajo licencia Apache 2.0, es por ello que cualquiera puede contribuir a su ampliación, corrección y mejora, la cuál es muy bienvenida y agradecida.

Arrancando Dust

Una vez nos hayamos descargado el paquete correspondiente a nuestra arquitectura lo descomprimimos y accedemos al directorio, dependiendo de si estamos en GNU/Linux o Windows tendremos un fichero dust.sh o dust.bat respectivamente, que al ejecutarlo abrirá Dust. Este no contendrá ninguna suscripción a ningún blog.

Figura 2: Paquetes de DUST

Figura 3: DUST arrancado

Suscribirse a un blog

Una de las opciones de la parte superior es la de Subscription. Aquí es donde podremos leer los blogs a los que nos hemos suscrito y añadir nuevas suscripciones.

Para suscribirse a un nuevo blog hay que hacer clic en Add subscription y en el diálogo que aparece, en Feed URL introducimos la URL del blog al que nos vamos a suscribir (una de ellas). Por ejemplo aquí nos suscribimos al blog que hay en http://localhost/feed1.xml y le damos de nombre de canal “el lado del mal”. El canal es un nombre necesario para la publicación por P2P. Debido a que una misma persona puede publicar diferentes blogs es necesario algún mecanismo para poder diferenciar feeds de distintos blogs pero de una misma persona por P2P.

Figura 4: Añadiendo una subscripción

Suscribiéndonos a un blog

Con esto Dust recuperará la información de la URL especificada y tendremos en la parte de la izquierda un árbol con todas las suscripciones y dentro de cada suscripción (cada blog) los post del mismo (los que había en el feed recuperado). A partir de ahí ya podremos empezar a leer los post del blog. Suscripción a blog realizada.

Figura 5: El lado del mal en DUST

Figura 6: Leyendo el blog desde DUST

**************************************************************************************************
- DUST: Manual de Usuario (I de IV)
- DUST: Manual de Usuario (II de IV)
- DUST: Manual de Usuario (III de IV)
- DUST: Manual de Usuario (IV de IV)
**************************************************************************************************