DEV Community: Javi AS

Scraping de Open Data utilizando GitHub

Javi AS — Sat, 01 Jun 2024 10:48:01 +0000

El dato se ha convertido en un elemento fundamental para parametrizar el mundo que nos rodea. En esta era de la información surge también el concepto de Datos Abiertos u Open Data, una filosofía que busca de forma libre y para todo el mundo que se pueda consumir distintos tipos de datos sin restricciones de derechos de autor, patentes u otros mecanismos de control.

Diversos portales orientados a esta práctica, tanto de entidades públicas como privadas, publican y actualizan información de diversa índole con cierta periodicidad. Esto permite a ciudadanos, investigadores y organizaciones desarrollar aplicaciones o nuevas soluciones. A fin de cuentas, el dato se puede considerar un punto de partida sobre el que envolver ciertas capas de abstracción para que le den sentido en un contexto específico.

En ocasiones, estos datos no están historificados, es decir, se obtienen al momento y cuando se actualizan la información anterior no puede volver a ser consultada. Este post nace de la curiosidad y necesidad de poder visualizar la información en varios puntos temporales para ver su evolución.

Simon Willison define el git scraping[1] como la técnica para versionar en un repositorio las variaciones de un recurso, como pueda ser la respuesta de un endpoint. Su motivación principal para desarrollar este tipo de sistema fue tener un registro histórico y actualizado sobre incendios en California, proporcionado por Mozilla.

A raíz de esta idea nace Flat Data[2], de GitHub Next. Este proyecto permite automatizar la captura de datos de un recurso aprovechando la infraestructura que otorga **GitHub **para ejecutar **tareas programadas **y actualizar un repositorio con dicha información.

Para hacer un análogo del proyecto de Simon Willison, con apoyo del catálogo abierto de incendios activos de la NASA[3] se puede diseñar fácilmente un **scraper para obtener los datos **relativos a incendios en Europa de los últimos 7 días, con una frecuencia de refresco diaria.

name: Flat

on:
  push:
    branches:
      - main
  workflow_dispatch:
  schedule:
    - cron: '0 0 * * *'

jobs:
  scheduled:
    runs-on: ubuntu-latest
    steps:
      - name: Setup deno
        uses: denoland/setup-deno@main
        with:
          deno-version: v1.10.x
      - name: Check out repo
        uses: actions/checkout@v2
      - name: Fetch data
        uses: githubocto/flat@v3
        with:
          http_url: "https://firms.modaps.eosdis.nasa.gov/data/active_fire/modis-c6.1/csv/MODIS_C6_1_Europe_7d.csv"
          downloaded_filename: "europe_fire_7d.csv"

Antes de que se ejecute, conviene revisar que en las GitHub Actions del repositorio se den permisos de escritura para evitar un error 403 a la hora de hacer commit del contenido. Desde una URL https://github.com/{USERNAME}/{REPOSITORY}/settings/actions podemos configurar estos permisos haciendo scroll hasta el final, como se indica en la siguiente imagen.

Una vez ejecutada la GitHub Action, en el repositorio aparecerá esta información y de manera automática se irá refrescando, manteniendo versiones anteriores para su consulta por cualquier usuario en cualquier momento.

El código de referencia se encuentra disponible en este enlace: https://github.com/javi-aranda/flat-data-example/

Referencias:

[1] Git Scraping: https://simonwillison.net/2020/Oct/9/git-scraping/
[2] Flat Data: https://githubnext.com/projects/flat-data
[3] Catálogo de incendios de la NASA: https://firms.modaps.eosdis.nasa.gov/active_fire/#firms-txt

PELUSA: Detectando phishing mediante Machine Learning

Javi AS — Wed, 11 Oct 2023 18:26:07 +0000

El phishing es una técnica utilizada para suplantar sitios legítimos incitando a usuarios finales a introducir credenciales, tarjetas de pago u otros datos sensibles. A día de hoy sigue siendo una de las amenazas principales en materia de seguridad informática. Muchos usuarios no son expertos en su detección, y es comprensible dado que cada vez son más sofisticados.

Los mecanismos más comunes a través de los cuáles se propaga un phishing suelen ser los SMS (indicando cancelaciones de tarjetas de pago o extractos bancarios que requieren revisiones con urgencia, o un pago para desbloquear un paquete retenido en aduanas...) y el correo electrónico (cargos pendientes a Hacienda, etc.).

Contexto

Por lo general, los ciberdelincuentes utilizan técnicas como typosquatting para intentar engañar al ojo humano, al que le puede costar diferenciar https://google.com de https://gooogle.com. Algunos se aprovechan de subdominios muy largos para parecer reales, al estilo http://tramites.mi-area-de-gestion-privada.nombredebanco.<nombre-de-web>.com, si se da el caso de que los atacantes infectan un sitio existente y aprovechan para plantar ahí su página falsa. Otros pueden emplear acortadores de enlace, muy comunes en la propagación por SMS, y los más espabilados pueden intentar usar punycode [1] para que al mostrar el enlace en la barra de navegación no se diferencie a simple vista del original, aunque sean realmente distintos.

En el ejemplo de arriba, la página web que se está mostrando realmente es https://www.xn--80ak6aa92e.com/, pero en la barra de navegación parece https://apple.com/, incluyendo certificado SSL. Este dominio está registrado con caracteres cirílicos correspondientes al alfabeto ruso, y los navegadores los muestran de forma similar a los caracteres del alfabeto latín al que estamos acostumbrados.

Entender cómo funciona este tipo de ataques desde "el lado oscuro" puede ayudar a crear mecanismos para facilitar su detección. Con este propósito en mente, he dedicado varias semanas a desarrollar un proyecto relacionado con esto.

Presentando PELUSA

PELUSA, acrónimo para Predictive Engine for Legitimate & Unverified Site Assessment, es una aplicación que utiliza Machine Learning para clasificar un enlace como malicioso o legítimo.

Para el entrenamiento del modelo, he utilizado un conjunto de datos de elaboración propia. Gracias a un fichero de sitios activos catalogados de PhishTank y a una serie de muestras seleccionadas de forma aleatoria de varias colecciones de Kaggle he obtenido 30.000 webs, la mitad clasificadas como maliciosas y la mitad seguras para navegar. Sobre dicho conjunto he aplicado un analizador estático, escrito en Python, para extraer características como pueda ser la longitud del dominio, si utiliza algún acortador de enlace, la presencia de palabras sospechosas en la URL, etc.

Tras obtener las características más relevantes y dividir el conjunto de datos en entrenamiento y test, probé con varios modelos, entre los que despuntaban Random Forest [2] y XGBoost con un 94% de precisión frente a un modelo de Regresión Logística con el que solo tenía un 84% de precisión. Finalmente decidí utilizar Random Forest porque su tiempo de entrenamiento era algo más corto y ofrecía resultados similares. Este clasificador, a diferencia de otros que dependen de un solo modelo para tomar decisiones, se basa en una estrategia de "sabiduría colectiva", combinando las predicciones de múltiples modelos individuales para producir una predicción general más sólida y precisa.

Una vez finalizado el entrenamiento del modelo, al pasarle las características extraídas de varios enlaces, tanto legítimos como maliciosos, devolvió unas predicciones correctas. Sin embargo, hay casos en los que cualquier URL que tenga un número largo de caracteres puede ser detectado como malicioso. Este tipo de comportamientos es normal dado el tamaño de entrenamiento y las características disponibles, y quiero mejorarlo en el futuro.

Próximos planes

En la parte de mi tiempo libre que dedico a trabajar en PELUSA, pienso en nuevas características que incorporar al analizador para elaborar un conjunto de datos aún más completo, y que ya detallaré en próximas iteraciones. Algunas de estas ideas incluyen:

Fecha de creación y expiración del dominio.
Validar si el dominio de una URL se encuentra indexado en motores de búsqueda.
Qué registros DNS hay asociados al dominio.
Si la web dispone de SSL, así como la confianza de la Entidad Certificadora (CA) que emita el certificado.

Cómo usar PELUSA

En este momento, PELUSA funciona únicamente de forma local. Mediante Docker se pueden desplegar fácilmente tanto un Frontend [3] escrito en React como el Backend [4], que utiliza FastAPI y PostgreSQL para almacenar las predicciones realizadas. De esta forma, el Backend queda desacoplado para que se pueda integrar con otras herramientas y así tener un apoyo extra en la detección de phishing.

Conclusiones

Las brechas de seguridad que múltiples compañías sufren día a día terminan exponiendo muchos datos que los ciberdelincuentes pueden aprovechar para dirigir ataques personalizados, por eso hay que tener especial cuidado cuando introducimos datos, ya sea a través del móvil, ordenador, tablet o cualquier dispositivo. Internet es un ente que crece por momentos. No hay consenso real en cuántos sitios nuevos aparecen cada día, ya que las estimaciones varían entre 200.000 [5] a 500.000. Las probabilidades de que ninguno termine siendo utilizado por ciberdelincuentes son remotas, por lo que disponer de herramientas que ayuden de forma automática a realizar esta labor puede aportar un grado extra de seguridad.

Referencias

[1] https://fraudwatch.com/what-is-punycode-phishing-part-1/
[2] https://es.wikipedia.org/wiki/Random_forest
[3] https://github.com/javi-aranda/pelusa-react
[4] https://github.com/javi-aranda/pelusa-server
[5] https://www.statsfind.com/how-many-websites-are-there-in-the-world-a-daily-calculator/

HyperLogLog | Un algoritmo para contarlos (aproximadamente) a todos

Javi AS — Wed, 04 Oct 2023 21:08:19 +0000

Imagina que trabajas en el equipo de ingeniería de una aplicación con un gran volumen de usuarios y tienes que obtener métricas de forma rápida sobre cuántos usuarios únicos tienes en un día. Veamos cómo resolver este caso de uso.

La potencia que proporciona un marco matemático y el análisis y diseño de algoritmos a la programación permite resolver problemas de todo tipo, como pudiera ser la estimación de la cardinalidad.

El problema de estimación de la cardinalidad trata de averiguar el número de elementos distintos en un conjunto o flujo de datos donde puedan existir elementos repetidos.

El problema, desde la base

Podemos ejemplificar este problema considerando que tenemos un listado con todas las palabras de un libro, y queremos saber cuántas palabras distintas hay en él.

Una solución, intuitiva a primera vista, sería inicializar una estructura de datos vacía, iterar sobre el conjunto de palabras que tenemos e ir añadiendo a nuestra estructura nueva las palabras si no se encuentran ya en dicha estructura. Finalmente, la longitud de este nuevo conjunto será el número de elementos únicos del primer listado.

Esta solución tiene un problema, que radica en la escalabilidad. Si en lugar de disponer un solo libro tuviéramos que realizar esta operación sobre la totalidad de libros de la Biblioteca Británica (más de 170 millones de ejemplares), este algoritmo requeriría una gran cantidad de memoria para almacenar la nueva estructura. En términos de complejidad de memoria, necesitamos O(n), ya que incrementaría de forma lineal mientras más datos de entrada tenemos.

Una primera aproximación: Flajolet-Martin

En 1984, Philippe Flajolet y G. Nigel Martin proponen una alternativa en su artículo “Probabilistic Counting Algorithms for Data Base Applications [1]”. Esta solución, conocida como el algoritmo Flajolet-Martin, funciona, en resumidas cuentas, de la siguiente forma:

Creamos un vector de bits de longitud L, de forma que 2^L > n, donde n es la longitud del conjunto de datos.
Una función hash transforma cada elemento del flujo de datos en un número binario uniforme. La función de hash es (ax + b) mod L; donde a y b son números enteros, x el elemento de entrada del flujo de datos, y L es el límite de rango de la función hash que definido en el punto anterior.
Se cuenta el número de ceros consecutivos, al que llamaremos k, al final del número binario producido. En nuestro vector de bits establecemos el bit k-ésimo a 1.
Repetimos el proceso con cada elemento del flujo de datos.
Obtenemos el índice del primer 0 en el vector de bits, al que llamaremos R.
Estimamos la cardinalidad con la fórmula 2^R / Φ. El símbolo Φ representa un factor de corrección con valor Φ = 0.77351…

El algoritmo Flajolet-Martin se ejecuta con varias funciones hash diferentes y se calcula la media de los resultados aproximados, ya que una sola ejecución podría inducir errores si los datos no están compensados al ser hasheados.

La mejora de rendimiento de esta solución es evidente, ya que su complejidad en memoria es de O(log(n)), en lugar de O(n) como la primera sugerencia.

LogLog entra en escena

Casi 20 años después, en el Simposio Europeo de Algoritmos de 2003, Flajolet y Marianne Durand presentan “Loglog Counting of Large Cardinalities [2]” como mejora a este algoritmo.

LogLog añade el concepto de “bucketing”, por el que se divide el número binario producido por la función de hash en varios grupos de bits. De cada grupo, se toma el número de ceros consecutivos al final y se calcula la mediana. Para obtener la cardinalidad estimada de todo el conjunto de datos, se realiza la media de todas las medianas. Esto mejora la complejidad en memoria a O(log log n), de ahí el nombre del algoritmo.

Esta revisión presenta mejoras al evitar tener que ser ejecutada con distintas funciones de hash para reducir márgenes de error. En el artículo donde se presenta LogLog, una ejecución del algoritmo estimó que, teniendo como datos de entrada todas las palabras de todas las obras de Shakespeare, se estimaban alrededor de 30.897 palabras únicas. El dato real es de 28.239 palabras distintas, dando un error relativo del 9.4%.

En el mismo artículo se detalla la implementación de SuperLogLog como una optimización sobre LogLog, que además de contar los ceros consecutivos, tiene en cuenta los siguientes bits. Mediante esta estimación mejorada, obtiene resultados más precisos en conjuntos pequeños, donde más flojea LogLog.

Un algoritmo casi óptimo: HyperLogLog

No es hasta pocos años después, ya en 2007, cuando Flajolet y otros investigadores evolucionan el concepto y describen “HyperLogLog: the analysis of a near-optimal cardinality estimation algorithm [3]”.

HyperLogLog (HLL) mejora a todo lo anterior, aplicando complejos mecanismos matemáticos y estadísticos que le permiten contar con un error relativo del 2% para cardinalidades superiores a 10⁹. Es considerado casi óptimo, y fue una auténtica revolución cuando se presentó.

Casos de uso

A día de hoy, ¿hay empresas y servicios que utilicen HLL? Veamos varios ejemplos:

Trino (anteriormente conocido como Presto), un motor de consulta SQL orientado a Big Data desarrollado originalmente por Facebook [4].
Redis, el popular motor de base de datos en memoria, implementa HLL con un error estándar de 0.81% [5].
Amazon Redshift, el servicio de Data Warehouse en de Amazon Web Services [6].

Otros algoritmos de cardinalidad y conclusiones

LogLog ha servido como inspiración para otros algoritmos de estimaciones de cardinalidad. En 2006 se presenta B-LogLog-EC [7], orientado al conteo de tráfico IP. Una revisión de HLL llamada HyperLogLog++ (HLL++) fue presentada por Google en 2013 [8], supliendo algunos de los puntos flacos que tenía HLL, y que en la actualidad es utilizado por Google Analytics 4 [9]. No es hasta 2016 que LogLog-Beta [10] aparece en un artículo en arXiv, cuya implementación optimizaría aún más los resultados producidos por HLL y HLL++.

En un entorno en el que se generan grandes cantidades de datos por segundo, este tipo de algoritmos son muy útiles para obtener métricas actualizadas en tiempo real como puedan ser los visitantes diarios a una página web, para estimar cuántas palabras únicas hay en la literatura mundial o para detectar anomalías en un dispositivo IoT que emita señales constantemente.

Referencias:

[1] Probabilistic Counting Algorithms for Data Base Applications: https://algo.inria.fr/flajolet/Publications/FlMa85.pdf
[2] LogLog Counting of Large Cardinalities: https://algo.inria.fr/flajolet/Publications/DuFl03-LNCS.pdf
[3] HyperLogLog: the analysis of a near-optimal cardinality estimation algorithm: https://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf
[4] HyperLogLog in Presto: A significantly faster way to handle cardinality estimation: https://engineering.fb.com/2018/12/13/data-infrastructure/hyperloglog/
[5] HyperLogLog | Redis: https://redis.io/docs/data-types/probabilistic/hyperloglogs/
[6] Using HyperLogLog sketches in Amazon Redshift: https://docs.aws.amazon.com/en_gb/redshift/latest/dg/hyperloglog-overview.html
[7] LOGLOG counting for the estimation of IP traffic: https://dmtcs.episciences.org/3503/pdf
[8] HyperLogLog in Practice: Algorithmic Engineering of a State of The Art Cardinality Estimation Algorithm: https://static.googleusercontent.com/media/research.google.com/es//pubs/archive/40671.pdf
[9] Unique count approximation in Google Analytics: https://developers.google.com/analytics/blog/2022/hll?hl=en
[10] LogLog-Beta and More: A New Algorithm for Cardinality Estimation Based on LogLog Counting: https://arxiv.org/ftp/arxiv/papers/1612/1612.02284.pdf

Este post fue publicado antes en Medium