DEV Community: Rafael Adiosdado Caballero Diéguez

Cómo protegí mi correo y mi web: SPF, DKIM y DMARC en la práctica.

Rafael Adiosdado Caballero Diéguez — Mon, 17 Aug 2026 11:15:34 +0000

Un día me hice la pregunta incómoda: ¿puede alguien enviar correos haciéndose pasar por mí? Sin la protección adecuada, la respuesta es sí — y colaría. Así que me puse a cerrar esa puerta en mi propio dominio. Comparto cómo funciona, por si te sirve.

El problema: suplantar un correo es más fácil de lo que crees

El protocolo del correo (SMTP) nació sin autenticación: por diseño, cualquiera puede escribir en el campo "De:" lo que quiera. Es la base del phishing y del fraude del CEO (BEC), el que más dinero mueve. Si tu dominio no está protegido, alguien puede escribir a tus clientes o a tu propio entorno como si fueras tú, y el correo llegará con tu nombre.

La defensa no es un producto que se compra: son tres estándares abiertos que se configuran una vez en el DNS del dominio y trabajan juntos.

Capa 1 · SPF — quién puede enviar en mi nombre

SPF (Sender Policy Framework) es una lista blanca de los servidores autorizados a enviar correo con tu dominio. Si un mensaje sale de un servidor que no está en la lista, el receptor sabe que algo huele mal. Es un registro TXT. En mi caso, el correo va por Zoho, así que:

v=spf1 include:zohomail.eu ~all

El ~all indica "lo que no esté autorizado, trátalo como sospechoso". Solo puede existir un registro SPF por dominio.

Capa 2 · DKIM — una firma que prueba que es auténtico

DKIM (DomainKeys Identified Mail) añade a cada correo una firma criptográfica. El servidor de envío firma con una clave privada y el receptor verifica con la clave pública publicada en tu DNS. Demuestra dos cosas: que el correo salió de verdad de ti y que nadie lo manipuló por el camino. La clave pública se publica en un registro TXT bajo un "selector" (en mi proveedor, zmail._domainkey).

Capa 3 · DMARC — qué hacer con quien falla (y visibilidad)

DMARC (Domain-based Message Authentication) es el que ata todo: le dice al receptor qué hacer con los correos que no pasan SPF/DKIM, y —clave— te envía informes de quién está intentando enviar en tu nombre. Su política es progresiva:

p=none — solo observa e informa (no afecta a la entrega).
p=quarantine — lo que falla va a spam.
p=reject — lo que falla se rechaza directamente.

Lo mío está en quarantine con alineamiento estricto y con informes activados:

v=DMARC1; p=quarantine; adkim=s; aspf=s; rua=mailto:...@adeodato.es; fo=1

La forma correcta de avanzar es empezar en none, revisar los informes unas semanas para asegurarte de que no bloqueas nada legítimo, y subir después a quarantine y reject.

Sin esto: el doble castigo

Un dominio sin autenticación sufre lo peor de dos mundos: por un lado, cualquiera puede suplantarte; por otro, tus correos legítimos acaban en spam, porque los proveedores desconfían de lo que no está autenticado. Pierdes seguridad y entregabilidad a la vez.

La web también: empieza por los cimientos

La misma lógica aplica al sitio web: adeodato.es va por HTTPS y con el dominio bien configurado. La seguridad no es una capa que se añade al final, es el cimiento sobre el que se construye lo demás.

Crear, no comprar

Nada de esto es un producto ni una licencia: son estándares abiertos y públicos que cualquiera puede implementar y auditar. Prefiero soluciones que entiendo y poseo, sin ataduras de proveedor.

La lección

Autenticar el correo es de las medidas de mayor impacto y menor coste que existen: se configura una vez y protege para siempre contra un vector de ataque que sigue siendo el número uno. Lo apliqué primero en mi propia casa — predico con el ejemplo — porque la mejor forma de recomendar algo es haberlo hecho tú antes.

Escrito por Rafael Adiosdado Caballero Diéguez — **Adeodato, ciberseguridad IT/OT y desarrollo seguro. Más en adeodato.es.

Control parental en Android sin root: DNS-over-HTTPS, bloqueo de ajustes y de apps (así construí AdeoShield)

Rafael Adiosdado Caballero Diéguez — Sun, 16 Aug 2026 16:51:39 +0000

title: "Control parental en Android sin root: DNS-over-HTTPS, bloqueo de ajustes y de apps (así construí AdeoShield)"
published: false
description: "Control parental para Android sin root: filtrado DNS-over-HTTPS (AdGuard Family), bloqueo de ajustes sensibles, bloqueo de apps por PIN y protección PBKDF2. Defensa en 3 capas y modelo de amenaza honesto."
tags: android, kotlin, security, privacy
canonical_url: https://adeodato.es/articulo-adeoshield.html

Publicado originalmente en adeodato.es.

Filtrar lo que ve un Android sin rootearlo y sin ADB parece imposible: el sistema aísla las apps entre sí. La clave no es pelearse con Android, sino usar sus propias piezas —VpnService y servicio de Accesibilidad— para montar una defensa en capas. Así construí AdeoShield: nació para proteger a una familia de verdad, y es también un ejercicio de ingeniería de seguridad.

Qué hace, en resumen

AdeoShield (nativo en Kotlin + Jetpack Compose) no es solo un filtro de webs. Combina cuatro capacidades:

Filtrado de red por DNS-over-HTTPS contra AdGuard Family DNS (bloquea contenido adulto y malicioso a nivel de resolución de nombres).
Bloqueo de los ajustes sensibles del sistema que permitirían desactivar la protección.
Bloqueo de aplicaciones por PIN: el adulto elige qué apps proteger y AdeoShield exige el PIN para abrirlas.
Protección por PIN de toda la configuración, con criptografía seria.

Cómo funciona: defensa en tres capas

1. Capa de resolución. Un VpnService local captura las consultas DNS del dispositivo y las reenvía cifradas (DoH) a AdGuard Family DNS. No hay servidor propio ni túnel a terceros: el contenido no deseado ni siquiera llega a resolverse. El esqueleto del túnel es el patrón estándar de Android:

val builder = Builder()
    .setSession("AdeoShield")
    .addAddress("10.0.0.2", 32)
    .addDnsServer("10.0.0.1")   // el DNS lo atiende la propia app
val vpnInterface = builder.establish()
// Leer las consultas DNS del descriptor, resolverlas por DoH y filtrar.

2. Capa de persistencia. Un AccessibilityService vigila las pantallas que apagarían la protección —Accesibilidad, VPN, DNS privado, administradores de dispositivo, opciones de desarrollador— y las bloquea o las protege con PIN. Sin esta capa, el filtro se desactivaría en dos toques.

3. Capa de autenticación. El PIN protege toda la configuración: derivado con PBKDF2WithHmacSHA256, 120.000 iteraciones y salt aleatorio por instalación. Nunca se guarda en claro, y hay bloqueo temporal tras varios intentos fallidos.

Más que webs: bloqueo de aplicaciones por PIN

La parte que más suele sorprender: además de filtrar dominios, AdeoShield deja al adulto seleccionar apps concretas de la lista de instaladas. Cuando alguien intenta abrir una app bloqueada, el servicio de Accesibilidad intercepta la apertura y pide el PIN antes de dejar entrar. El control no es solo de red, también de acceso a aplicaciones — todo bajo la misma autenticación.

Protecciones configurables y el punto ciego del DNS privado

Granularidad: cinco protecciones activas por defecto; el bloqueo de "Ajustes del sistema" se ofrece como opción avanzada desactivada por defecto, por su impacto en la usabilidad.
Detección de DNS privado (DoT): si el usuario configura un DNS privado a nivel de sistema, este podría resolver consultas antes de que entren en el túnel. AdeoShield detecta esa situación y avisa — un vector de elusión que muchas soluciones ignoran.

El modelo de amenaza (y sus límites honestos)

Parte de la ingeniería seria es decir hasta dónde NO llega la defensa:

Restricted Settings (Android 13+): el sistema bloquea conceder Accesibilidad a apps instaladas por sideload (APK), lo que afecta a la capa de bloqueo de ajustes en dispositivos modernos. En Android 10 no ocurre. Documentado en el modelo de amenazas.
DNS privado del sistema (DoT): puede resolver antes del túnel; la app avisa, pero la mitigación total depende de proteger esa pantalla.
Acceso físico: modo seguro o restablecimiento de fábrica sortean cualquier control parental de app.

La premisa es honesta: en un dispositivo que el usuario controla físicamente, ninguna protección a nivel de app es absoluta. El objetivo es elevar mucho el coste y la dificultad de eludirla, no prometer lo imposible. Probado en dispositivos reales (Galaxy J6 con Android 10 y A54 con Android 13+), con APK de release firmado.

Por qué open source (GPL-3.0)

AdeoShield es libre bajo GPL-3.0: cualquier derivado debe seguir siendo libre. En una herramienta de protección familiar, que el código sea auditable importa — nadie tiene que fiarse de mi palabra, puede leerlo.

La lección

Incluso un "simple" control parental es un ejercicio de ingeniería de seguridad: entender el modelo de la plataforma, usar sus piezas a tu favor, cifrar por defecto, defender en profundidad, proteger la propia app y ser transparente sobre sus límites. Pensar como atacante para construir mejor como desarrollador.

Escrito por Rafael Adiosdado Caballero Diéguez — **Adeodato, ciberseguridad IT/OT y desarrollo Android seguro. Más en adeodato.es · AdeoShield en GitHub.

Slowloris: cómo una sola máquina tumba un servidor web (y cómo defenderte)

Rafael Adiosdado Caballero Diéguez — Sun, 16 Aug 2026 16:23:49 +0000

Publicado originalmente en adeodato.es.

Una sola máquina, sin botnets y sin saturar la red, puede dejar un servidor web sin responder en segundos. No es un ataque volumétrico: es Slowloris, un ataque de Denegación de Servicio de Capa 7 que no ahoga tu ancho de banda, sino tus conexiones. Lo reproduje en laboratorio para entenderlo por dentro y, sobre todo, para saber pararlo.

Qué es Slowloris y por qué es peligroso

Un ataque volumétrico clásico busca saturar la red con tráfico masivo: es ruidoso y fácil de detectar. Slowloris hace lo contrario. Abre cientos de conexiones y envía las cabeceras HTTP a cámara lenta, de forma incompleta, manteniendo los sockets ocupados esperando datos que nunca llegan. Cuando se agota el límite de conexiones del servidor, deja de atender a usuarios legítimos.

No consume ancho de banda: el consumo de red es mínimo.
Le basta una sola máquina: no necesita botnet.
Parece tráfico legítimo: peticiones HTTP válidas desde una IP normal, así que evade los firewalls de red.

La demostración: del reconocimiento al colapso

En un laboratorio controlado, con slowhttptest, el ataque adopta la forma de un Slow Headers contra la página de login del servidor objetivo:

slowhttptest -c 1000 -H -i 10 -r 200 -u http://servidor-victima/login.php -t GET

Cada parámetro cuenta parte de la historia que un defensor debe reconocer: -c 1000 mantiene 1000 conexiones abiertas; -H activa cabeceras lentas; -i 10 envía un fragmento cada 10 s para mantener viva la conexión; -r 200 abre 200 conexiones nuevas por segundo.

En el segundo 10: 623 conexiones ocupadas, 0 cerradas y service available: NO. El servidor está caído — sigue esperando cabeceras que nunca llegarán.

Por qué funcionó: la vulnerabilidad no es el hardware

El servidor no cayó por falta de potencia, sino por configuración:

Timeouts laxos: tolera esperas larguísimas por cabeceras que no llegan.
Sin límite por IP: ningún tope de conexiones por origen.
Capa 7 = tráfico legítimo: las peticiones parecen válidas y evaden los firewalls de red.
Sin WAF ni IDS: nadie alertó del volumen anómalo de conexiones abiertas.

Cómo detectarlo (perspectiva Blue Team)

Pico de conexiones concurrentes desde muy pocas IPs.
Muchas conexiones ESTABLISHED que no envían datos: esperan cabecera.
Workers agotados con la CPU y el ancho de banda bajos — la pista clave frente a un ataque volumétrico.
Peticiones cuya cabecera se recibe a goteo y nunca se completa.

Regla de oro: si las conexiones abiertas suben pero el tráfico real no, sospecha.

Cómo defenderte: el playbook

Timeouts agresivos — RequestReadTimeout (Apache) / client_header_timeout (Nginx). La medida de mayor impacto.
mod_reqtimeout — corta automáticamente las conexiones lentas.
Límites por IP — LimitRequestFields, MaxKeepAliveRequests.
Control de tasa — limit_req_zone en Nginx.
fail2ban — bloqueo dinámico ante comportamiento anómalo.
WAF / CDN (Cloudflare, Akamai) — absorben y filtran el tráfico.

La clave: los timeouts estrictos impiden que las conexiones incompletas ocupen sockets indefinidamente, que es el mecanismo del ataque.

La lección

La robustez de un sistema no se mide por lo rápido que procesa peticiones, sino por su capacidad de gestionar conexiones anómalas. Slowloris opera bajo el radar, simulando tráfico legítimo y agotando recursos de forma silenciosa pero letal. Entender el ataque es el primer paso para diseñar la defensa.

Escrito por Rafael Adiosdado Caballero Diéguez — **Adeodato, ciberseguridad IT/OT. Ayudo a PYME e industria a detectar, contener y responder ataques reales, también en entornos OT. Más en adeodato.es · SOC Adeodato en GitHub.