Medición pasiva de seguridad en dominios .it: CSP, cookies, TLS y email authentication

Problema

En entornos de investigación y auditoría de seguridad es frecuente necesitar una visión amplia de la postura de seguridad de miles de dominios sin tocar sus servidores. La medición pasiva —realizar solo peticiones HTTP, TLS handshakes y consultas DNS— permite recolectar datos de encabezados, configuraciones TLS y registros de email (SPF, DMARC, DKIM) sin generar tráfico que pueda ser considerado hostil. El reto surge cuando:

• Se quiere estimar la adopción de DKIM sin lanzar consultas activas a cada selector posible.
• Se necesita publicar un dataset grande manteniendo la reproducibilidad del proceso, pero sin exponer información sensible como sector o ubicación de los dominios.
• Se debe diseñar una arquitectura de pipeline que sea reutilizable para cualquier ccTLD (por ejemplo .it, .de, .br) y que escale a decenas de miles de hosts.

Causa

1. DKIM sin enumeración activa – DKIM funciona mediante registros DNS TXT bajo el nombre <selector>._domainkey.<domain>. La lista de selectores es arbitraria; los investigadores que usan una lista fija pueden subestimar la cobertura. La causa principal del sesgo es confiar en selectores comunes (default, mail, google, etc.) y omitir los personalizados.

2. Exposición de metadatos – Publicar una tabla con dominio → sector → puntuación de seguridad permite a atacantes focalizar objetivos. La presión de reproducir resultados lleva a incluir más contexto del necesario, lo que aumenta el riesgo de filtración.

3. Pipeline monolítico – Cuando el proceso de recolección, parsing y análisis está codificado en un solo script, cualquier cambio (p.ej. una nueva versión de OpenSSL) rompe la reproducibilidad. Además, la falta de modularidad dificulta la adaptación a otro ccTLD o a un nuevo encabezado de seguridad.

Solución

1. Arquitectura modular de medición pasiva

Dividir el flujo en tres micro‑servicios independientes:

Cada módulo escribe su salida en un bucket S3 o en una carpeta compartida, permitiendo re‑ejecución parcial. Los contenedores Docker garantizan versiones fijas de las herramientas; el Dockerfile se versiona junto al código.

2. Estimación de DKIM sin selector enumeration activa

Una estrategia híbrida que mantiene la pasividad:

1. Lista de selectores “probables” – Compila un conjunto basado en:

   • Selectores de proveedores de correo populares (google, outlook, yahoo).
   • Prefijos comunes (default, mail, smtp, dkim).
   • Estadísticas de proyectos de código abierto que exponen su selector en archivos de configuración.

2. Consulta DNS de tipo TXT con wildcard – Usa dig o dnsx con la opción -wildcard para intentar resolver <selector>._domainkey.<domain> y detectar respuestas NXDOMAIN rápidamente. La ausencia de respuesta no implica ausencia de DKIM, pero la presencia sí confirma su existencia.

3. Heurística de “probable presencia” – Si al menos uno de los selectores de la lista devuelve un registro válido, marca el dominio como “DKIM observado”. Complementa con:

   • DMARC policy “reject” o “quarantine” – Los dominios que usan políticas estrictas suelen tener DKIM configurado, aunque no se haya detectado.
   • SPF con include:_spf.google.com – Indica uso de Google Workspace, que por defecto crea el selector google.

4. Reporte de cobertura – Presenta dos métricas: DKIM detectado (consulta directa) y DKIM probable (heurística). Deja claro que la segunda es un límite inferior.

3. Balancear reproducibilidad y privacidad de metadatos

1. Pseudonimización de dominios – Genera un hash SHA‑256 de cada FQDN con una sal única por publicación. Guarda la tabla de mapeo solo en el repositorio privado; el dataset público contiene solo los hashes.

2. Separación de capas – Publica dos artefactos:

   • Dataset crudo (solo hashes y métricas) bajo una licencia de datos abiertos.
   • Metadatos opcionales (sector, país, tamaño) en un repositorio restringido con acceso bajo solicitud.

3. Documentación de versiones – Cada ejecución del pipeline incluye:

   • Versión del código (git commit).
   • Versión de cada herramienta (extraído con --version).
   • Timestamp ISO 8601. Esto permite a terceros reproducir los resultados sin necesidad de conocer los dominios reales.

4. Licenciamiento y aviso – Añade un archivo README.md que explique la razón de la pseudonimización y ofrezca un canal de contacto para solicitar acceso a los metadatos completos bajo acuerdos de confidencialidad.

4. Implementación práctica (ejemplo de script de recolección)

#!/usr/bin/env bash
set -euo pipefail

# 1. Leer lista de dominios (CSV, columna "domain")
domains=$(awk -F, 'NR>1 {print $1}' domains.csv)

# 2. Ejecutar httpx para obtener encabezados y TLS info
echo "$domains" | httpx -silent -json -threads 200 -status-code -title -server -tls-grab -header > httpx_output.json

# 3. Ejecutar dnsx para SPF, DMARC y selectores DKIM probables
selectors=("default" "mail" "smtp" "dkim" "google")
for sel in "${selectors[@]}"; do
  echo "$domains" | dnsx -silent -a -type TXT -retry 2 -mx -cname -ptr -resp -json -wildcard -query "${sel}._domainkey." >> dkim_partial.json
done

# 4. Consolidar resultados (pandas script later)

5. Verificación de la solución

1. Consistencia de hashes – Ejecuta sha256sum sobre la lista original y compara con los hashes publicados. Diferencias indican pérdida de dominios.

2. Cobertura DKIM – Selecciona 20 dominios al azar, consulta sus selectores reales con dig manual y verifica que al menos uno coincida con la heurística reportada.

3. Re‑ejecución parcial – Modifica solo el módulo Collector (por ejemplo, actualiza httpx a una versión nueva) y lanza de nuevo. Los resultados de Parser deben mantenerse idénticos si la entrada JSON no cambió.

Cuándo aplicar esta solución

• Auditorías de gran escala – Cuando el objetivo es medir la postura de seguridad de miles de dominios sin generar tráfico sospechoso.
• Estudios comparativos entre ccTLDs – La arquitectura modular permite cambiar la lista de dominios y reutilizar los mismos módulos.
• Publicación de datasets abiertos – Si necesitas compartir métricas sin revelar la identidad de los dominios, la pseudonimización y la separación de capas son obligatorias.
• Entornos donde la enumeración activa de DKIM es prohibida – La heurística basada en selectores comunes y políticas DMARC ofrece una estimación aceptable.

No es adecuada cuando:

• Se requiere una auditoría de cumplimiento legal que exija la verificación de cada selector DKIM.
• El objetivo es identificar vulnerabilidades específicas (p.ej. CSP bypass) que solo se descubren mediante pruebas activas.

Notas adicionales

• Actualiza la lista de selectores cada 6‑12 meses. Los proveedores de correo añaden nuevos prefijos y los administradores a menudo crean selectores personalizados.
• Monitorea cambios en herramientas. Una nueva versión de httpx puede añadir encabezados que antes no se capturaban, lo que altera métricas de “security headers”.
• Considera usar zgrab2 para capturar versiones exactas de TLS y certificados cuando la precisión de la información de cifrado sea crítica.
• Documenta siempre la sal usada para hash; sin ella, los hashes no son reproducibles por terceros.

Con esta arquitectura y metodología, cualquier equipo de seguridad puede lanzar mediciones pasivas consistentes, estimar la adopción de DKIM sin romper la pasividad y publicar resultados útiles sin comprometer la privacidad de los dominios analizados.