Cloudflare Radar: Open (Security & Network) Data para CERTs & CSIRTs

La empresa Cloudflare tiene disponible para todos los equipos de seguridad, especialmente para los CERTs y los CSIRTs, el servicio Cloudflare RADAR de datos abiertos sobre lo que está pasando en su red y en sus servicios de seguridad, y te permite tener una visión de lo que está pasando en la seguridad de Internet desde sus servicios, lo que complementa la información que tengas desde otras fuentes de datos. Al final, la colaboración y la compartición de datos entre los equipos de ciberseguridad es fundamental para protegernos entre todos.

Figura 1: Cloudflare Radar - Open (Security & Network)

Data para CERTs & CSIRTs

Los servicios de ciberseguridad de Cloudflare ofrecen protección para los activos que las empresas tienen en Internet, que van desde proteger los sitios web o sus plataformas de e-commerce expuestos en la red frente a ataques de DDOS, hasta proteger el e-mail, pasando por WAFs, protección contra interceptación de conexiones de red, protección de servicios de DNS, protección contra técnicas de WebScrapping como vimos con AI Labirynth, o los más modernos servicios de monitorización y protección de servicios digitales basados en arquitecturas de Inteligencia Artificial.

Figura 2: Servicios de Seguridad de Cloudflare

Si te interesa este mundo del las fuentes abiertas de datos, o quieres tener información de seguridad desde un punto de vista privilegiado, Cloudflare Radar te puede ayudar a completar tus dashboards de OSINT para tus servicios de CERT o para tus investigaciones en un CSIRT.

Figura 3: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

Toda esta información puede ser consumida vía API, mediante un Dashboard web/mobile, o mediante el uso de un Asistente AI al que se le puede preguntar por datos concretos, informes, e información en las bases de datos de Cloudflare Radar.

Figura 4: Consola de Cloudflare Radar

En este panel tienes datos de todos esos servicios, procesados, filtrados, destilados y disponibilizados para que puedas interactuar con ellos y sacar detalles que puedan ayudarte en tu trabajo en ciberseguridad, o entender mejor qué está pasando o qué va a pasar.

Figura 5: GPTBot lidera los escaneos recientes como USER-Agent

Como los datos de Cloudflare están centrados en Ciberseguridad, y debido a que muchos de ellos proceden de sus servicios de protección, el curado de los datos está orientado a ello, por lo que se pueden obtener datos de ataques, informes de incidentes recientes, estadísticas de dominios atacadas, bots maliciosos, etcétera.

Figura 6: Informe de un Phishing de ayer mismo

(aún activo a día de hoy)

Todos los datos están procesados, pero están los detalles disponibles, por lo que si ves este informe de Phishing de ayer mismo, puedes ver incluso los ficheros de la web que se han descargado, y absolutamente todos los datos disponibles.

Figura 7: Detalles del incidente de Phishing

La información completa y detallada de la API la tienes en la web para Devevelopers de Cloudflare, donde por ejemplo tienes APIs para tener datos de anuncios de BGP - uno de los ataques Nation State que hemos visto en el pasado - que pueden alterar la seguridad de las redes a nivel de conexión. 

Figura 8: Descripción de las APIs de BGP en

el portal de developers de Cloudflare

Esa información, también la puedes analizar directamente desde la consola de Cloud Radar, y ver si todo está como debe, si hay una actividad maliciosa o si se ha producido un Hijacking de una determinada ruta de interconexión de redes que pueda ser un riesgo, o que explique cómo se ha producido un ataque.

Figura 9: Información de las rutas BGP las últimas 48 horas

Los datos también dan información sobre el DNS, o los incidentes detectados por los productos de seguridad de e-mail security (recordad que sigue siendo el principal vector de ataque en las empresas), teniendo datos en tiempo real de cuando una campaña de ataque ha comenzado.

Figura 10: Información de E-mail Security en Cloudflare Radar

Y datos de dominos más peligrosos, cabeceras de seguridad de cada mensaje, y datos de las protecciones SPF, DKIM y DMARC de estos mensajes, para detectar las debilidades que los atacantes están explotando en sus campañas.

Figura 11: Los TLDs más vistos en los sistemas que originan más ataques

Y si además del Dashboard de Cloudflare Radar o de las APIs de Cloudflare Radar quieres encontrar algo usando lenguaje natural, puedes usar el Asistente AI que tienes disponibles, donde puedes interactuar con él para aprender todo lo que necesites de los datos disponibles.

Figura 12: Asistente AI de Cloudflare Radar

Al final, es una fuente de información que tienes disponible para utilizar en cualquier momento, y si te gusta este mundo, merece la pena que entres en Cloudflare Radar y mires todos datos que tienes disponibles, listos para utilizar en tus sistemas.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

¿Cuánto acierta tu dirección IP dónde vives o dónde estás? #GPS #Privacidad #GeoIP

En los últimos artículos de "Cómo saber dónde está un contacto de WhatsApp con los Estados" y "Cómo saber dónde vive un contacto de WhatsApp" compartiendo una canción, hablamos de utilizar la dirección IP como forma de localizar una ubicación GPS. Pero, la pregunta, es... ¿mi dirección IP da una ubicación GPS real o no? Pues bien, descúbrelo tú mismo.

Figura 1: ¿Cuánto acierta tu dirección IP dónde vives o dónde estás?

En primer lugar, averiguar tu dirección IP es tan fácil como preguntarle a Google "What is my IP" y te dice rápidamente desde qué dirección IP estás navegando en Internet. Fácil y rápido. 

Figura 2: ¿Saber la dirección IP? Pregúntale a Google

En segundo lugar, comprueba varias bases de datos de GeoIP que, no son todas igual de ajustadas. Hay que tener en cuenta que estas bases de datos se basan en un trabajo de actualización constante de la información de dónde se encuentran las direcciones IP y estas cambian constantemente, así que depende del trabajo que haya detrás de ellas, tendrán más o menos actualizada la información.

Figura 3: Artículo con diferentes GeoIPs.

Maxmind ha llegado muy cerca de mí con mi dirección IP

También, estas bases de datos se alimentan de información de actualización que dan los usuarios, así que cuanta más comunidad tiene detrás, más ajustada y acertada es la información. En dos pruebas hechas yo en diferentes bases de datos, el resultado ha sido totalmente distinto. 

Figura 4: Ejemplo de IP en una base de GeoIP

MaxMind ha acertado con la ciudad en la que estoy, con mi Código Postal,  y se ha quedado bastante cerca cumpliendo su radio de "accuracy" de 10 Km en mi caso (a bastante menos se ha quedado), y otra ha dado como resultado una ciudad cercana, lo que quiere decir que una de las dos tiene información sin actualizar.

Figura 5: Mismo ejemplo de búsqueda de IP en MaxMind.

Cambia el resultado un poco.

Estas bases de datos dan, por último, información de GPS, que puedes utilizar para buscar la coordenada en Google y saber cuánto de cerca de dónde estas es esa información GPS. Ten en cuenta que ese es el lugar en le que puede estar el concentrador de comunicación por el que estás saliendo.

Figura 6: En Google Maps pones las coordenadas GPS y te busca la

ubicación y las fotos de Street View. ¿Es tu zona?

¿No ha acertado? No pasa nada, eso quiere decir que esa base de datos no es lo suficientemente fina con los datos, pero puede existir otra que sí que lo sea o que acierte más adelante. ¿Ha quedado cerca? Pues ya sabes, cuando navegas desde esa dirección IP das información que puede indicar dónde estas.

Figura 7: Libro de "Cómo protegerse de los peligros en Internet"
de José Carlos Gallego en  0xWord

Y si es un enlace que te envía alguien por un chat de WhatsApp o de Telegram pues... ya sabes, es un riesgo más que debes evitar, que puede ser peligroso si quieres salvaguardar tu privacidad cuando estás conectado a Internet.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

RINA: Breve introducción a su arquitectura y sus principios de arquitectura

En el anterior artículo hablamos sobre los defectos que tiene la arquitectura de red TCP/IP actual. Antes de empezar a desarrollar cómo RINA mejora los defectos que tiene la arquitectura actual, me gustaría matizar algo que considero importante. RINA no se plantea como un reemplazo del TCP/IP. RINA nace con la motivación de proponer una arquitectura nueva donde TCP/IP no puede llegar. 

Figura 1: RINA: Breve introducción a su arquitectura y sus principios de arquitectura

RINA se puede desplegar de manera incremental interoperando con las tecnologías actuales. No necesita un despliegue limpio como por ejemplo si necesita IPv6. Es decir, puede funcionar en varios casos de uso distintos (por encima de una red Ethernet, por encima de una red IP, etcétera).

Principios de la arquitectura

RINA de manera general, se basa en el principio de maximizar los invariantes en la arquitectura, de modo que se pueda minimizar el número de protocolos. La siguiente figura ejemplifica esta afirmación de manera gráfica.

Figura 2: Representación abstracta de la arquitectura y los protocolos de red

actuales frente al objetivo deseado. Fuente: RINA ETSI Report

Lo que se pretende en RINA es solucionar la mayoría de problemas complejos dentro de la arquitectura, es decir, todas las cuestiones que no dependan de los requisitos de cada red, solucionarlos dentro de la arquitectura de manera que tendremos menos protocolos y estos se parecerán más entre ellos.

¿Qué es la red?

Como hemos explicado en el artículo anterior, la red no es más que el canal que permite comunicación entre aplicaciones (por ejemplo, Skype, e-Mail, WhatsApp, etcétera). Por tanto, la red es en sí misma, una aplicación distribuida especializada en proveer este canal de comunicación entre aplicaciones (es decir, procesos).

En RINA, a este canal se le llama DIF (Distributed IPC Facility), que viene a significar exactamente lo que veníamos diciendo, una aplicación que provee servicios de comunicación entre procesos. Como primer modelo podríamos tener un solo DIF que proporcione a dos aplicaciones capacidad para comunicarse.

Figura 3: Representación de un DIF para proporcionar IPC entre dos endpoints.

Fuente: Eduard Grasa, diapositivas Introducción a RINA

Pero no nos podemos quedar tranquilos así. Si solo tenemos un DIF para dar comunicación a todas las aplicaciones del mundo, no funcionaria, ergo no es escalable. Pero esto es algo que podemos solucionar de manera relativamente sencilla. Necesitamos aislar los diferentes scopes en las redes.

Figura 4: Representación de varios DIFs para proporcionar IPC entre 2

endpoints. Fuente: Eduard Grasa, diapositivas Introducción a RINA

Lo que tenemos en RINA entonces, son múltiples DIFs que proveen IPC entre ellos. Al fin y al cabo, un DIF simplemente es una aplicación distribuida. ¿Y cuántos DIFs se tienen que usar en una red? Pues tantos como el diseñador de la red considere oportunos para el caso de uso que se quiere proveer IPC. Por ejemplo, habrá un DIF (rojo) que estará por encima del nivel físico, que se adaptará a la tecnología que modula la información por debajo (aire, fibra, cable, etcétera); o bien puede interesar tener un segmento de red metropolitano (azul) más lejos de los usuarios, que agregue más cantidad de tráfico al flujo.

Al final, lo que tenemos es una arquitectura más abstracta y más sencilla, ya que en una red solo se tiene el mismo elemento repetido N veces. Con lo cual, gestionar la red se hace más fácil, ya que solo sabiendo cómo se comporta un DIF y cómo se relaciona con otro DIF (o aplicación, porque interactúan de la misma manera), se puede generalizar a cómo interactúa toda la red con todos los elementos que la componen. De aquí viene lo de Recursive en RINA, ya que (abusando del término) lo que se tiene es un mismo tipo de capa que se va repitiendo y se usan los servicios de una capa a otra de la misma manera que las aplicaciones usan los servicios de ella.

Importante hacer énfasis en que las distintas capas (distintos DIFs) no tienen funcionalidades distintas, solo se ocupan de proveer servicios de comunicación entre procesos en un scope. Entonces, un DIF provee servicios para que dos aplicaciones se comuniquen, pero… ¿Puede haber varias aplicaciones usando los servicios de un mismo DIF? Por supuesto, de hecho, de manera más concreta, un DIF proporciona los servicios de comunicación asignando recursos (memoria en buffers, capacidad de ancho de banda, etcétera) para las distintas aplicaciones. Luego, las aplicaciones piden un flujo de comunicación al DIF con unos requisitos concretos y compiten unas aplicaciones con otras para poder obtener ese flujo. 

Dentro del DIF

¿Y qué hay dentro de un DIF exactamente? Dentro de los DIFs, siguiendo la filosofía de RINA, también se pretende simplificar al máximo su estructura interna (siguiendo el principio de maximizar las invariancias). Las funciones que hace un DIF se clasifican en tres tipos:

• Funciones de transferencia de datos

• Funciones de control de transferencia de datos

• Funciones de gestión de capa

Para poder realizar estas funciones, se necesitan de protocolos, tal y como nos pasa en la arquitectura actual. Pero recordamos que queremos tener los mínimos protocolos y lo más simple posible. Para minimizar la variabilidad entre protocolos dentro del DIF al mínimo, lo que se hace es separar entre mecanismo y policy.

• Los mecanismos son las partes fijas en un protocolo. Por ejemplo, el acknowledgement (ACK); que es un tipo de mensaje que se utiliza para saber si un paquete ha llegado correctamente a su destino.

• Policy es la parte del protocolo que cambia. Por ejemplo, cuando y cómo enviar un ACK es una policy.

Y con esta premisa de separar entre mecanismo y policy, nos sale que solamente con dos protocolos es suficiente para cubrir las tres funcionalidades del DIF: EFCP para transferencia y control de transferencia de datos, y CDAP para gestión de capa.

Nombres y direccionamiento

Sin entrar mucho en detalle, ya que de esto ya hemos hablado en el otro artículo, RINA plantea un esquema de nombres que facilita la movilidad, simplifica el enrutamiento de tráfico y proporciona multi-homing de manera nativa.

Figura 5: Estructura de nombres y direccionamento en RINA.

Fuente: Eduard Grasa, diapositivas Introducción a RINA

Como ya hemos discutido anteriormente, necesitamos que las aplicaciones tengan un nombre, y que lo conserven independientemente de donde se encuentren. Luego tenemos direcciones de nodo, que nos dan pistas sobre dónde viven las aplicaciones. A continuación mostramos una tabla comparativa con el sistema de nombres actual

Figura 6: Tabla comparativa.

Por último, tenemos las direcciones de punto de anclaje (point of attachment), que estas direcciones sí que nos dicen cómo llegar a donde viven las aplicaciones.

Conclusión

Si has llegado hasta al final, te habrás dado cuenta de que RINA proporciona una arquitectura bastante abstracta, y en consecuencia, el objetivo final de RINA es poder tener un framework que permita desarrollar protocolos y así poder simplificar las redes en general. Como he dicho en el principio del artículo, se puede aplicar RINA en ábmbitos concretos, como por ejemplo dentro de los centros de datos. 

Figura 7: Future Internet and RIMA

Al ser una tecnología relativamente nueva, la idea es ir empezando con casos de usos muy sencillos y poco a poco irse moviendo a casos de usos más grandes y complejos. Os dejamos algunos enlaces que podrían ser interesantes.

• Future Internet and RINA Architecture | EduTec&Cria: Charla de Eduard Grasa, la cual se ha usado de guía y referencia para escribir estos dos artículos. De hecho, estos dos artículos se podrían considerar como una síntesis/introducción de esta charla. Esta charla explica de manera muy entendedora y sencilla qué problemas tiene la arquitectura actual y cómo RINA puede solucionarlos.

• IRATI: Es una implementación Open Source de RINA que tiene una Wiki bastante completa y documentación sobre RINA.

• ETSI RINA Report: Este es el documento de estandarización de RINA en el que se explica de manera más técnica todos los detalles técnicos de RINA.

Saludos,

Autor: Bruno Ibáñez, Investigador de Ciberseguridad e IA en Ideas Locas y Sergio Giménez investigador de i2cat.

Contactar con Bruno Ibáñez

Contactar con Sergio Giménez

¿Está roto Internet? Qué es RINA y por qué puede solucionar los problemas de la arquitectura TCP/IP actual

Empezamos fuerte: Internet está roto. Bueno, quizás no completamente, pero sí que tiene varios defectos. De hecho, siendo un poco más rigurosos y menos alarmistas con la anterior afirmación, podríamos decir que la arquitectura de red en la cual está diseñado internet tal y lo conocemos hoy en día, es mejorable. Puede parecer inocente afirmar esto, pero espero que al final de este artículo se entienda las debilidades que tiene la arquitectura actual y cómo podríamos mejorarla.

Figura 1: ¿Está roto Internet? Qué es RINA y por qué puede

solucionar los problemas de la arquitectura TCP/IP actual

Pero empecemos por el principio. ¿Qué es una arquitectura? Podríamos definir una arquitectura como un conjunto de patrones y metodologías que permiten diseñar elementos con requisitos distintos. Ejemplifiquémoslo. Si tenemos en mente una iglesia/catedral, podemos decir con relativa facilidad, viendo el edificio, que tiene una arquitectura gótica, románica, clásica, etcétera. A pesar de que todos los elementos son edificios, cada uno tiene unas características distintas. Por tanto, una arquitectura captura patrones invariantes y comunes entre distintas construcciones independientes de los requisitos de cada una.

Pues ya tenemos el concepto de arquitectura definido, ahora nos falta el segundo: red. ¿Qué es una red? Al fin y al cabo, una red nos proporciona comunicación entre dos extremos, que de ahora en adelante llamaremos endpoints. ¿Pero estos endpoints que son? Pues en última instancia, son aplicaciones (siendo rigurosos, instancias de proceso del sistema operativo). Por lo tanto, una red no es más que una manera de copiar datos de manera distribuida (e imperfecta) entre dos aplicaciones. Esta definición de red, estaba muy presente en los inicios de las redes de comunicaciones, y en conclusión, viene a decir que, las redes de computadores, presentan servicios de comunicación entre procesos (IPC services en inglés).

Figura 2: Modelo de arquitectura de la OSI (izquierda, centro) y modelo de conjunto de protocolos de Internet (izquierda) Fuente: RINA ETSI Report

Bien, ya tenemos una idea más o menos clara de lo que es una arquitectura de red. Ahora la pregunta que nos podríamos hacer sería la siguiente: ¿Cuál es la arquitectura de red actual? Pues no está formalmente definida. Según nuestra definición de arquitectura, el modelo actual no se corresponde a una arquitectura definida de manera formal y precisa. Lo que sí existe, son una serie de reglas que se cumplen (más o menos) y que funcionan (más o menos) y que hay problemas que no contemplan, y entonces cada caso de uso debe ser resuelto de manera independiente. Veamos más en detalle cuáles son los problemas que tenemos con la “arquitectura” actual.

Problemas de la arquitectura actual

1.- Layering

La arquitectura actual no deja espacio para nuevos protocolos de red. Hay una capa llamada “de red” común en todo Internet por encima del nivel de enlace. Esto implica que, por ejemplo, si una red quiere hacer routing que no sea IP, o esconder routers internos de redes privadas del Internet público, se deben usar soluciones ad-hoc.

El hecho de que se tengan que usar soluciones específicas para cada caso de uso es un problema, porque como es algo no está contemplado en la arquitectura común, cada diseñador de red arregla “sus problemas a su manera”. El caso de uso expuesto antes donde se quiere hacer routing de distinta manera, se puede resolver con MPLS (Layer 2.5), pero también se puede resolver de otras formas, por ejemplo en redes celulares está GTP, o protocolos de IP-tunneling (paquetes IP dentro de paquetes IP), etcétera.

Figura 3: El modelo de arquitectura de Internet se amplía constantemente

para contemplar nuevos casos de uso. Fuente: RINA ETSI Report

Al fin y al cabo, en esta sección se pretende ilustrar que, como la arquitectura no contempla una solución común independiente del tipo de red, existen una miríada de soluciones dispares. Y al fin y al cabo, esto se resuelve de la manera en que se ilustra en la figura inferior. Algo que a priori debería ser sencillo, con unas capas fijas, se acaba convirtiendo en realidad en lo que se muestra en la figura siguiente, donde aparecen distintos protocolos que se meten entre las distintas capas para poder solucionar casos de uso que ocurren en la actualidad y que la arquitectura no contempla. Si tuviéramos una arquitectura bien definida y concreta, no acabaríamos teniendo una macedonia de protocolos y soluciones puntuales.

2.- Nombre y direccionamiento

Otro problema que existe en la arquitectura actual es cómo identificar distintas entidades dentro de una red. Tenemos las aplicaciones, que son los endpoints de un servicio de comunicación de red. Veamos un ejemplo en la figura a continuación.

Figura 4: Nombres y direccionamiento en la arquitectura actual

Fuente: Eduard Grasa, diapositivas Introducción a RINA

Las aplicaciones no tienen un nombre independiente. Para establecer un flujo de conexión TCP, necesitamos la dirección donde se encuentra la aplicación, además de un puerto, que indica el endpoint del flujo. Paremos aquí un momento.

Si nos fijamos en la dirección de la aplicación de Alice es www.elladodelmal.com:80, vemos que esto no se parece a una dirección IP, y en efecto, se necesita la traducción del DNS para convertirlo a dirección IP. El DNS resuelve la dirección antes de establecer el flujo de conexión, y el DNS es un sistema externo, ajeno a la red. La red no entiende de direcciones de aplicaciones, la red solo entiende que está conectando una interfaz de red (y un puerto) a otra interfaz de red (y otro puerto).

Por ejemplo, si la red se mueve, la red no tiene ni idea que la misma aplicación se está instanciando en otra parte, entonces cualquier gestión que haya que hacer (como por ejemplo volver a enrutar el tráfico), no se puede hacer sin un elemento externo a la red (como es el caso del DNS). En conclusión: que la red no sepa los nombres de las aplicaciones es un problema.

3.-Movilidad

Como hemos visto, el nombre de la aplicación no es estable y depende del sitio donde te encuentres. Una ejemplificación muy simple de la problemática que causa este hecho, sería que yo en mi casa me llamara Sergio, pero que en mi trabajo me llamaran de otra manera, solo por el simple hecho de haberme movido. 

Con las redes pasa exactamente esto. Si te mueves, tu dirección cambia. ¡Y debe ser así! Porque la dirección debe identificar dónde te encuentras exactamente; pero el nombre de la aplicación debería ser estable, ya que solo indica quién eres y no debe variar en función de donde te encuentres.

Pero en el modelo actual no ocurre esto. En la capa de red (que se ocupa del enrutamiento) solo existe un único identificador: la dirección IP. Los routers no entienden de nombres de aplicaciones, solo direcciones IP. Así que si se quiere tener movilidad en una red, se deben usar más protocolos.

4.- Multi-homing

Se puede dar el caso de que Alice tenga más de dos interfaces de red en su máquina, es decir, Alice se puede conectar a una red o a más de una red. El problema aquí, es que cada interfaz debe tener una dirección IP distinta. Con lo cual, la aplicación de Alice tiene 2 direcciones, ya que tenemos una dirección para cada interfaz.

Pongamos un ejemplo, si la aplicación de Bob envía tráfico a la aplicación de Alice, la red enrutará dicho tráfico desde 12.12.12.12 a 10.0.0.1. Lo que pasa es que si 10.0.0.1 se rompe, la aplicación de Bob no tiene ninguna manera de enviar ese tráfico a la aplicación de Alice. El tema aquí es que la aplicación de Bob no quiere ir a 10.0.0.1, ni a 10.11.0.1, sino que quiere ir a la aplicación de Alice.

Figura 5: Problema del multi-homing.

Fuente: Eduard Grasa, diapositivas Introducción a RINA

Por supuesto, esto es algo que se puede solucionar parcialmente en el modelo actual (solucionar parcialmente, porque los endpoints deben ser partícipes en esta solución, no es la red quien brinda soluciones). Igual a este punto el lector ya se imagina cómo… más protocolos (SHIM6, Multipath TCP, BGP…).

Sin embargo, si esto hubiera estado pensado desde un principio e incluido en la arquitectura, se le podría haber encontrado una solución proporcionada de forma nativa en la arquitectura. De todas formas, la solución a este problema es trivial tal y como se muestra en la siguiente figura.

Figura 6: Solución del problema de multi-homing dando direcciones a los nodos

Fuente: Eduard Grasa, diapositivas Introducción a RINA

Bastaría con que la arquitectura estuviera diseñada con direcciones en los nodos, no a las interfaces. Y luego enrutar tráfico en base a estas direcciones de nodos. Concluyendo…

La arquitectura actual, como hemos ido viendo tiene defectos:

• En su estructura
• Cómo se diseñan protocolos: no se rehúsa cosas en común entre protocolos, todos ellos se diseñan desde cero (aunque hagan funciones muy parecidas).
• Nombres y direcciones. Como hemos ido viendo, tiene todos los problemas de multi-homing y movilidad que hemos comentado.

Y no hemos hablado de cosas que también dan para rato, como por ejemplo la API de los sockets para programar aplicaciones, seguridad - que de eso tenéis muchos ejemplos en el libro de Ataques en redes de datos IPv4 & IPv6 -, gestión de la red, ya que a más protocolos, más complicación a la hora de gestionar una red.

Figura 7: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

Quizás llegado a este punto, podrías estar pensando sobre lo inocente que puede ser hablar sobre “lo mal que funciona Internet”, pero en realidad paradójicamente esta información te está llegando gracias a la arquitectura actual. Y millones de cosas que funcionan sobre esta arquitectura y que nadie hace 20 años pensaba que pudieran llegar a suceder. Pero realmente, las cosas que se han ido mencionando son defectos reales que tiene la arquitectura y que sí se pueden mejorar. Y de la voluntad de intentar mejorar todo esto, aparece RINA. Pero esto, lo hablaremos en detalle en la siguiente parte de este artículo.

Saludos,

Autor: Bruno Ibáñez, Investigador de Ciberseguridad e IA en Ideas Locas y Sergio Giménez investigador de i2cat.

Contactar con Bruno Ibáñez

Contactar con Sergio Giménez

Cinco mujeres hacker que posiblemente no conoces y su gran aportación al mundo de la Ciencia y la Tecnología (Parte 5 de 5): Elizabeth J. Feinler

Hoy llegamos al final de este artículo donde hemos hablado de cinco mujeres hacker que probablemente mucha gente no conoce. Hemos hablado de su impacto en el mundo de la inteligencia artificial, de la seguridad de protocolos de comunicaciones remotos, de su trabajo como criptoanalistas o como creadoras de la protocolos de comunicaciones que permitieran crear la red de redes. Hoy terminamos con una de ellas que hizo trabajo de fondo, creando el sistema de comunicación y gestión de las redes. A ella se le atribuye haber sido la creadora del primer buscado de Internet, aunque fuera un buscador técnico para profesionales y expertos.

Figura 30: Cinco mujeres hacker que posiblemente no conoces y su gran aportación al mundo de la Ciencia y la Tecnología (Parte 5 de 5): Elizabeth J. Feinler 

Elizabeth J. Feinler Mientras estudiaba para sacarse el doctorado en bioquímica, Elizabeth decidió irse a trabajar para ganar algo de dinero antes de empezar con tu tesis (de acuerdo con la propia Elizabeth tenía tan poco dinero que comía ardillas o que compraba los restos de los pollos que se usaban para experimentos en la universidad en la que estaba estudiando, Perdue), y acabó trabajando para Chemical Abtract Services, una empresa situada en Columbus, Ohio. 

Figura 31: Elizabeth J. Feinler 

Allí fue asistente en un proyecto bastante importante (uno de los más grandes del mundo por la época sobre el manejo de datos) el cual trataba de indexar los componentes químicos del mundo. Fue aquí donde Elizabeth se interesó por la creación y manejo de grandes cantidades de datos. De hecho, fue tan grande su interés, que dejó la bioquímica (nunca hizo su tesis) y después de dos años, en 1960, se fue a California para trabajar en el Instituto de Investigación de la Información de Stanford (Stanford Research Institute - SRI).

En SRI, Elizabeth trabajaba en un equipo el cual se encargaba de buscar información sobre proyectos de investigación académica que se estaban haciendo, para asegurarse que dicho tipo de investigación no había sido hecha ya, o que no hubiera patentes registradas sobre las funcionalidades que se estaban implementando. 

Figura 32: Una joven Elizabeth en el SRI

Una de las personas que más acudía a este equipo era Doug Engelbart (inventor entre otras cosas, del ratón) con el que acabó teniendo una buena relación profesional.  Fue más tarde, cuando Doug empezó a trabajar en un proyecto para DARPA, este proyecto no era nada más y nada menos que ARPANET, la primera versión de lo que hoy conocemos como Internet.

En 1972, Doug le dijo a Elizabeth que estaba buscando a alguien para crear una Guía de Recursos (Resource Handbook) de Internet y si estaba interesada en hacer dicho trabajo. Elizabeth sin saber muy bien lo que eso significaba, aceptó y se unió al equipo de Doug, al que ellos mismos llamaban: Augmentation Research Center Group. Este grupo aún seguía perteneciendo al Instituto de Investigación de la Información de Stanford. 

Figura 33: Arpanet Resource Handbook y Protocol Handbook 

El trabajo de Elizabeth consistió en dirigir el Centro de Información de Redes (Network Information Center – NIC). El objetivo de este centro era recolectar y organizar la información que existía en ARPANET. Por aquel entonces había unas 30 redes interconectadas y dichas redes debían de proveer información de los proyectos que se encontraban en las mismas, aunque no todas lo hacían.

Figura 34: Mapa Lógico de ARPANET en 1977

Cada una de esas redes tenían dos personas de contacto, el agente de la estación (Station Agent) y un coordinador técnico (Technical Liaison). Una de las tareas del agente de estación era el archivar la copia de los documentos que el NIC le enviaba, muchas veces en papel porque algunas de esas redes no disponían de servicios del tipo FTP (el cual aún no existía), aunque existían otras formas de transferencia de datos, aunque no muy fiables.

El NIC no sólo recopilaba lo que cada red almacenaba, sino que redistribuía dicha información entre las mismas, para que cualquiera que necesitara buscar a través de dicha información pudiera hacerlo. Como se puede ver esto una forma muy primitiva de lo que hoy se conoce como un buscador. Por ello es que, a Elizabeth Feinler, se le atribuye la creación del primer buscador de Internet.

Figura 35: Elizabeth Jake Feinler en el Internet Hall of Fame

En 1989 Elizabeth dejó SRI y se fue a trabajar a la NASA, allí entre otras cosas trabajó en la creación de las guías del NASA Science Internet (NSI), el “NIC” de la NASA hasta 1996 cuando acabo jubilándose. Hoy en día, está por mérito propio en el Internet Hall of Fame.

Reflexión final

Estas cinco mujeres hackers no son más que una pequeña muestra de la gran aportación de la mujer al mundo de la Ciencia y de la Tecnología. y esperamos que las niñas puedan tener muchos ejemplos de que esta profesión es un lugar perfecto para ellas a la hora de desarrollar su carrera profesional. 

Figura 36: Mujeres Hacker

Nuestras niñas de hoy pueden ser nuestras mujeres hacker del futuro y como esas cinco grandes mujeres lo han sido en el pasado. Estamos seguros que volveremos con más historias de estas heroínas que merecen ser reconocidas y puestas en el lugar que se merecen en la historia juntos a los/las grandes fundadores/as del mundo (no sólo tecnológico) que hoy conocemos.

*************************************************************************************

- Cinco Mujeres Hacker que posiblemente no conoces: Arianna Wright Rosenbluth 

- Cinco Mujeres Hacker que posiblemente no conoces: Hedy Lamarr

- Cinco Mujeres Hacker que posiblemente no conoces: Elizebeth S. Friedman

- Cinco Mujeres Hacker que posiblemente no conoces: Radia Perlman

- Cinco Mujeres Hacker que posiblemente no conoces: Elizabeth Jake Feinler 

*************************************************************************************

Happy Hacking Hackers!!!

Autores:

Fran Ramírez, (@cyberhadesblog) es investigador de seguridad y miembro del equipo de Ideas Locas en CDO en Telefónica, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps", también de "Machine Learning aplicado a la Ciberseguridad” además del blog CyberHades. Puedes contactar con Fran Ramirez en MyPublicInbox.

 Contactar con Fran Ramírez en MyPublicInbox

Rafael Troncoso (@tuxotron) es Senior Software Engineer en SAP Concur, co-autor del libro "Microhistorias: Anécdotas y Curiosidades de la historia de la informática (y los hackers)", del libro "Docker: SecDevOps" además del blog CyberHades. Puedes contactar con Rafael Troncoso en MyPublicInbox.

Contactar con Rafael Troncoso en MyPublicInbox

Descarga el libro gratuito de "Seguridad en Redes"

Se acaba de publicar este nuevo libro gratuito denominado “Seguridad en Redes”. Esta obra presenta un enfoque eminentemente técnico de la experiencia de varios años de trabajo en grandes redes en las áreas de “Planificación y Operación de red”, “Seguridad de redes y TI” y “Auditoría de seguridad”, que podríamos afirmar, son los pilares fundamentales de toda red. Los prólogos de este libro están escritos por Chema Alonso y Antonio Castro Lechtaler, que como todos conocemos, son dos referentes internacionales en Redes y Seguridad.

Figura 1: Descarga el libro gratuito de "Seguridad en Redes"

El autor soy yo, Alejandro Corletti Estrada, que después de la publicación del libro “Seguridad por Niveles” en el año 2011  que alcanzó las 100.000 descargas, nuevamente me animé a crear esta obra para difusión y descarga gratuita para cualquier uso docente, quedando prohibida toda acción y/o actividad comercial o lucrativa, como así también su derivación y/o modificación sin autorización expresa del autor. Aquí tienes el prólogo que Chema Alonso escribió para este libro.

Ser un hacker y no un profesional 

Quiere el destino que escriba este prólogo solo un par de días después de que tuviera lugar el, hasta ahora, ataque de denegación de servicio distribuida más grande que se recuerda. Con una potencia de hasta 1.2 Terabits por segundo la botnet Mirai ha conseguido marcar el record en tráfico generado para hacer un ataque contra un objetivo concreto.

Corremos tiempos beligerantes en las redes de comunicaciones en los que los cibercriminales han encontrado en ellas un medio para perpetrar sus ataques con cierta percepción de impunidad al ocultarse en la distancia de países remotos con leyes no adaptadas que dejan que se escapen como polvo en los dedos.

Proteger este activo tan preciado que la tecnología nos ha dado es responsabilidad de todos. Desde el dueño de una impresora en su casa hasta el administrador de una pequeña red de equipos en una empresa pasando, lógico está, por los grandes proveedores de servicios en Internet. Cada fallo de seguridad en esta vasta y creciente red de redes puede ser utilizado por un adversario para conseguir una ventaja en un ataque y así, como hemos visto en el ataque que citaba al principio, la botnet Mirai se ha aprovechado de dispositivos como impresoras, routers, switches o cámaras de vigilancia mal configuradas, con bugs conocidos o contraseñas por defecto, para conseguir un número tal de equipos infectados que una empresa como DYN, que da soporte a una parte importante de los servicios DNS de Internet, no pueda contenerla.

Conocer nuestras redes, los rincones más pequeños y escorados de las mismas, para evitar que el eslabón más débil de esta cadena sea un dispositivo que forma parte del Shadow IT o el Shadow IoT de nuestra organización es fundamental. Pero más lo es conocer cómo funcionan y mantener la seguridad del mismo a lo largo del tiempo.

Decía la definición que hace el Internet Engineering Task Force en su RFC 1983 titulado Internet User’ Glossary que un Hacker es:

A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular. The term is often misused in a pejorative context, where "cracker" would be the correct term. 

Y es así lo que necesitamos todos que seas en tu red. Un auténtico hacker que tenga un conocimiento íntimo de cómo funciona tu red. Cuáles son los protocolos que están circulando por ellas, cómo están configurados, cómo se pueden mejorar y cuáles son los rastros que deben levantar una alerta en tus mecanismos de detección para saber que algo está pasando por ellas que no debiera.

Debes conocer todo lo que puedas tu red de comunicaciones. Saber cómo siente, piensa y respira cada poro de ella. Cada router, cada switch, cada firewall, cada equipo que envía o recibe tráfico por el medio que sea, por el protocolo que sea, por la aplicación que sea. Es tu red y debes conocerla como si la hubieras construido tú, debes ser el hacker de tu red y aprender de ella día a día.

En mi vida profesional, ya más larga de lo que me gustaría para poder disfrutar más de los muchos momentos que me toquen por venir aún, me he topado con una gran cantidad de informáticos que realmente no adoraban esta profesión. Profesionales que lo eran porque trabajaban de esto, pero que por falta de pasión y dedicación a conocer lo que tenían entre manos no deberían tener ese título.

Los que de verdad amamos este trabajo no escatimamos esfuerzos en aprender más día a día de lo que tenemos entre manos, en conocer aquello que desconocemos, en disfrutar del trabajo que nos llevó a meternos en esta afición que se convirtió en profesión.

Llegados a este punto debes hacerte a ti mismo esta pregunta. Debes preguntarte qué tipo de profesional quieres ser. Uno de esos que lo es por la tarjeta y la posición laboral o uno de esos que aprende todo lo que puede porque es un hacker que adora la tecnología. Decide tú. Tú manejas tu tiempo, tu vida, tus esfuerzos y tu carrera profesional. Hoy, y ahora, es el momento de que aprendas un poco más para que mañana puedas aprender un poco más sobre lo ya aprendido. Sé un hacker y no un trabajador de la informática.

Aprende todo lo que puedas y haz que tu trabajo sea tu pasión y que tu pasión sea tu trabajo. Solo así podrás ocuparte correctamente de la seguridad de tus redes.

Chema Alonso

El objetivo de esta obra es poder compartir conocimientos para que el nivel de seguridad de nuestras arquitecturas de red pueda mejorarse. El libro comienza con una detallada descripción de la historia y evolución de las redes, como punto de partida y pilar básico para ir abordando las diferentes estrategias y procesos. El texto presenta al detalle los dispositivos que forman el verdadero corazón mundial de la red fija y móvil.

Figura 2: Arquitecturas de redes para mitigar ataques DDoS 

Poco a poco sigue abordando los niveles de Switching y Routing desde un enfoque práctico y con ejemplos vigentes en las diferentes configuraciones y el empleo de los protocolos de red. Uno de los aspectos que más destacan de la obra, es la experiencia que intento transmitir por medio del uso de herramientas, comandos y programas que no pueden ser dejados de lado en el día a día de la seguridad de estas infraestructuras.

Figura 3: WireShark para analizar tráfico de red

Trata con suficiente grado de detalle los aspectos de seguridad que deben reunir los CPDs o centrales dónde se aloja el equipamiento de red. Y, como no podía ser de otra forma, el autor otra vez nos propone una importante cantidad de ejemplos prácticos en el empleo de comandos y herramientas, que tal cual menciona Chema Alonso en su prólogo, son la forma en la que operará todo hacker sobre nuestras redes y sistemas. Por lo tanto desde el punto de vista de los responsables de las mismas, deben conocerlas, saber emplearlas y sacarles provecho, previamente a que lo haga un intruso. Por supuesto, si quieres conocer más de tu adversario debes conocer cuáles son los ataques que hacen en redes IPv4 &IPv6.

Figura 4:  Libro gratuito de Seguridad en Redes

Las versiones impresas de esta obra - estas sí son de pago - se distribuyen únicamente en España y se pueden solicitar a través de la cuenta  de correo info@darFe.es.  Si quieres descargar una copia, puedes hacerlo en esta URL "Libro Seguridad en Redes" y aquí lo tienes subido a SlideShare.

Autor: Alejandro Corletti Estrada
Doctor en Ingeniería y ex-jefe de redes del Ejército argentino

Esteganografía en TCP/IP: Una Proof of Concept en Ruby

Hace tiempo que decidí echar un ojo al concepto de ocultar información dentro de los protocolos TCP, UDP o IP. Mi idea era generar una pequeña prueba de concepto dónde pudiera utilizar un protocolo común, el cual será utilizado como Covert Channel, y transmitir información de manera oculta, como una prueba de esteganografía. Tras estudiar diferentes opciones y revisar algún paper que habla de ello - que la idea no es nueva ni mucho menos y en el libro de Esteganografía & Estegoanálisis se le dedica un capítulo a esta parte -, opté por utilizar los flags de TCP y el número de secuencia de los paquetes TCP.

Figura 1: Esteganografía en TCP/IP: Una PoC en Ruby

En esta prueba de concepto, los paquetes TCP son reales, pero no tienen ningún sentido. Es cierto que se podría lograr un ejemplo de esteganografía más real que permitiese transmitir información sobre tráfico coherente TCP que se genere en el equipo. Es cierto, que si un administrador de red lee el tráfico que generaremos no me encontrará coherencia, y pensará que es tráfico erróneo, pero el mensaje se encuentra ahí, oculto.

Planteamiento

El primer planteamiento es ocultar información dentro de las estructuras que proporciona el protocolo TCP. Si nos fijamos en los flags más famosos de este protocolo, se tienen 6 “huecos” para almacenar bits. Los flags son: SYN, ACK, PSH, URG, RST y FIN. Aquí tenemos 6 bits y utilizando el número de secuencia o Sequence Number del protocolo se puede aumentar el ratio de bits. Para la prueba de concepto se ha decidido utilizar, solo 2 bits más con el número de secuencia.

En otras palabras, si queremos enviar el mensaje “esto es un secreto”, cada carácter se enviará oculto en los flags y en el número de secuencia de cada paquete TCP. A continuación desglosamos los bits de, por ejemplo, la letra "e", que se traduce en “01100101”, por lo que los 2 bits más significativos serán introducidos como número de secuencia, siendo éste el valor “1”. En el caso de ser “10” sería un “2”, y en el caso de ser “11” sería un “3”. El resto de bits menos significativos se corresponden con los 6 flags comentados anteriormente. Los flags RST, ACK y URG irían a 1. En la captura de Wireshark se puede visualizar.

Figura 2: Visualización de transmisión de letra "e"

En la máquina destino tendremos un programa que es capaz de leer el tráfico TCP y decodificar el tráfico oculto en TCP. ¿Cómo sabemos que el tráfico es especial? Para esta PoC hemos utilizado un puerto destino concreto como clave. Es decir, cuando recibamos un TCP destino 3030 entendemos que es un paquete con esteganografía.

El proceso de decodificación es el proceso inverso al de ocultación. El programa remoto leerá el número de secuencia y esos 2 bits (del 0 al 3) serán los bits más significativos. Después concatenaremos los flags, y obtendremos de nuevo un valor de 8 bits. Este valor se identifica con un carácter. Una vez entendido el mecanismo sencillo que se utilizará para ocultar los caracteres en los paquetes TCP vamos a hablar de la implementación.

Implementación

Para llevar a cabo la prueba de concepto se utilizó Ruby. La librería PacketFu, la cual es parecida a Scapy en Python, permite “jugar” y crear paquetes TCP y datagramas IP a nuestro antojo. Ya fue utilizado para el Port-Knocking con Latch y el modo paranoia. En la siguiente imagen se puede ver el código de la función main. El coder recibe 2 parámetros: Dirección IP destino y mensaje a ocultar en el protocolo TCP.

Figura 3: Coder. Implementación de la función main

El coder invoca un método denominado send_message, el cual proporciona la funcionalidad de ocultar el mensaje en el protocolo TCP, tal y como se explicó anteriormente. La función send_message inyecta el tráfico en la red a través de la función inject y prepara mediante unpack los caracteres que forman el mensaje en formato bytes.

Figura 4: Implementación de la función send_message

Hay una función importante como es write_byte_into_packet que permite ocultar la información en el paquete TCP gracias a PacketFu, tal y como puede verse en la siguiente imagen. En esta imagen se puede ver la explicación de dónde se oculta dentro de un paquete TCP los bits.

Figura 5: Función writ_byte_into_packet

Y, ¿El orden?

El orden de los paquetes TCP importa, ya que no es lo mismo que la “e” de “esto es un secreto” llegue antes o después que la “s”. El mecanismo válido en un ámbito real sería utilizar el Sequence Number para lo que es, y utilizar el ACK Number cómo lo estamos utilizando nosotros en esta prueba de concepto. En este caso, para evitar problemas se ha decidido enviar los paquetes con 1 segundo de diferencia, aunque en entornos LAN no habría problema.

En la siguiente imagen se puede visualizar como el emisor lanza el mensaje a una dirección IP concreta y al puerto 3030. El mensaje es “esto es un secreto”.

Figura 6: Envío del mensaje secreto con esteganografía en TCP/IP

El receptor recibe el tráfico y puede obtener el mensaje oculto uniendo los bits del Sequence Number y los flags TCP, tal y como se puede ver en la imagen. El resultado es el mensaje original. Si viéramos con Wireshark el tráfico veríamos paquetes TCP que podrían ser considerados incoherentes, pero que esconden el mensaje.

Figura 7: Lectura del mensaje por el covert channel en Kali Linux

Quiero agradecer a mi compañero Daniel Ruiz su apoyo y colaboración en llevar la prueba de concepto hacia adelante.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”