Cómo comprobar la seguridad pública de un dominio

Qué es la postura pública de un dominio

La postura pública es la huella de seguridad observable desde fuera de la organización, sin credenciales y sin acceso interno. Es lo que un atacante ve cuando elige un objetivo: si los registros de correo permiten suplantación, si las cabeceras HTTP protegen al usuario en el navegador, si quedan subdominios olvidados apuntando a servicios externos, si hay credenciales filtradas en pastes públicos, qué proveedores tecnológicos hay detrás de tu dominio y si alguno ha sufrido una brecha reciente.

Importa por tres razones prácticas. Primero, una mala postura pública es la entrada típica del 70-80% de los incidentes que llegan a ser noticia, según los informes de tendencias publicados por ENISA y por el sector. Segundo, es lo único que un cliente o auditor puede comprobar sin firmar un NDA, así que define la primera impresión técnica de tu organización. Tercero, es lo que más fácil resulta arreglar: la mayoría son cambios de configuración, no proyectos de meses.

Lo bueno es que toda esta superficie se mide de forma pasiva, en segundos, y sin tocar tus sistemas internos.

Correo electrónico: SPF, DKIM, DMARC y MTA-STS

El correo es el punto donde la mayoría de incidentes empiezan, y casi todos los controles importantes son registros DNS públicos. Si están mal, cualquiera puede comprobarlo y abusar de ello.

SPF — Sender Policy Framework

Es un registro TXT en el DNS que declara qué servidores tienen permiso para enviar correo en nombre de tu dominio. Si falta o está mal escrito, los receptores no pueden distinguir tu correo legítimo del suplantado. Si está demasiado permisivo (por ejemplo, autoriza rangos amplios sin justificación), el atacante encuentra un vector cómodo.

Cómo se detecta el fallo. El registro no existe, supera los 10 lookups DNS permitidos por la RFC, incluye `+all` (autorización universal) o autoriza redes que ya no envías correo.

DKIM — DomainKeys Identified Mail

Firma criptográfica del correo con clave privada cuya clave pública está publicada en un registro DNS. Permite al receptor verificar que el mensaje no se ha alterado y que viene del dominio que dice venir. La firma DKIM es lo que da peso real a DMARC.

Cómo se detecta el fallo. No hay selector DKIM publicado, la clave es de menos de 1024 bits (criptografía obsoleta), o tu proveedor de correo lo firma pero el registro DNS no está, así que la firma no se puede verificar.

DMARC — Domain-based Message Authentication, Reporting and Conformance

Es el registro que une SPF y DKIM y le dice al receptor qué hacer cuando uno o ambos fallan: nada (`p=none`, modo monitoreo), poner en cuarentena (`p=quarantine`) o rechazar (`p=reject`). Sin DMARC con política activa, SPF y DKIM no protegen del phishing que suplanta tu marca.

Cómo se detecta el fallo. No hay registro DMARC, está en `p=none` permanentemente (sin avanzar nunca a quarantine o reject), o no tiene dirección `rua` para recibir informes agregados — con lo cual no sabes si te están suplantando.

MTA-STS — SMTP MTA Strict Transport Security

Política publicada que obliga a los servidores que te envían correo a usar TLS y verificar el certificado. Sin MTA-STS, un atacante en la red puede degradar la conexión a texto plano e interceptar el correo.

Cómo se detecta el fallo. No hay registro TXT `_mta-sts`, la política HTTP no está publicada o tiene modo `none`. Es un control rápido de implementar y muy poco frecuente en dominios pequeños, lo que lo convierte en una diferenciación operativa real.

Diagnóstico rápido: en Hard2bit Scanner el bloque "Seguridad del correo" valida los cuatro registros sobre tu dominio y muestra los fallos concretos con texto explicativo, no solo un OK/KO. Es gratis para empezar.

DNS: DNSSEC, registros sensibles y Certificate Transparency

El DNS es el sistema nervioso de la postura pública. Si está bien gobernado, todo lo demás se sostiene. Si está mal, da igual lo que hagas en otros frentes.

DNSSEC

Firma criptográfica de las respuestas DNS, que impide que un atacante en la cadena de resolución te redirija a un servidor falso. Pocos dominios lo tienen activo, pero su ausencia es un punto fuerte en cualquier informe de auditoría externa.

Salud DNS general

Redundancia de servidores autoritativos, consistencia entre proveedores, ausencia de wildcards mal puestos, registros sensibles innecesariamente expuestos (`_admin`, `_dev`, `_staging`, `_internal`) que revelan estructura interna. Cada uno es una pista para un atacante.

Certificate Transparency (CT)

Logs públicos donde se publican todos los certificados TLS emitidos para cualquier dominio. Cualquiera puede consultar qué certificados se han emitido para tu marca — incluyendo los emitidos por error o por un atacante que haya comprometido tu DNS. No monitorizar CT es un punto ciego habitual.

Cómo se detecta el fallo. El equipo no recibe alertas cuando se emite un nuevo certificado para el dominio, o aparecen subdominios en los logs CT que ya no están en uso pero siguen apuntando a servicios externos vivos. Esos son candidatos a takeover.

Diagnóstico rápido: el bloque "Salud DNS" y "Certificate Transparency" del scanner muestra qué subdominios aparecen en logs CT con clasificación por patrón (dev/staging/admin) — esos son los que más rápido hay que revisar.

Web: cabeceras HTTP, cookies y contenido mixto

Cuando un usuario abre tu web, el navegador recibe respuesta del servidor con un conjunto de cabeceras que regulan qué puede hacer la página y qué no. Si faltan o están mal, la web sigue funcionando, pero el usuario queda expuesto a riesgos perfectamente prevenibles.

Las cabeceras HTTP que importan

• Strict-Transport-Security (HSTS): obliga al navegador a usar HTTPS siempre, incluso si el usuario escribe `http://`. Sin HSTS, un atacante en la red puede interceptar la primera conexión.
• Content-Security-Policy (CSP): declara qué orígenes de scripts, imágenes y estilos puede cargar la página. Sin CSP, un fallo de inyección se convierte fácilmente en robo de sesión.
• X-Frame-Options o `frame-ancestors`: evita que tu web sea cargada en un iframe de otro dominio. Sin ello, tu sitio puede ser víctima de secuestro visual (clickjacking).
• X-Content-Type-Options: nosniff: impide que el navegador interprete archivos como un tipo distinto al declarado, técnica habitual en algunos ataques.
• Referrer-Policy: controla qué información de origen se filtra al navegar a otros sitios.
• Permissions-Policy: limita qué APIs del navegador puede usar la página (cámara, micrófono, geolocalización).

Configuración de cookies

Los atributos `Secure`, `HttpOnly` y `SameSite` impiden que las cookies de sesión se filtren por canales inseguros o se utilicen en peticiones forzadas desde otros dominios. Una cookie sin estos atributos en una sesión autenticada es un riesgo serio.

Contenido mixto

Páginas servidas por HTTPS que cargan recursos por HTTP. Los navegadores actuales bloquean lo crítico, pero los warnings y las imágenes mixtas siguen siendo señal de mantenimiento descuidado y, en algunos casos, de fuga de información del usuario.

TLS / SSL: cifrado, certificados y protocolos seguros

El certificado TLS es lo primero que valida un navegador o un cliente al conectar contigo. Hay tres frentes que importan.

Certificado

Vigente, emitido por una CA confiable, con el nombre correcto del dominio (incluyendo wildcards si aplica), y con clave de tamaño suficiente. La caducidad inesperada de un certificado sigue siendo una de las causas más frecuentes de incidentes operativos en producción.

Protocolos y suites de cifrado

TLS 1.2 como mínimo, TLS 1.3 idealmente, y deshabilitar SSLv2/SSLv3, TLS 1.0 y TLS 1.1, que tienen vulnerabilidades documentadas y públicas. Suites de cifrado modernas, sin RC4, sin 3DES y sin algoritmos basados en MD5.

Configuración avanzada

OCSP stapling para revocación rápida, Perfect Forward Secrecy para que una clave comprometida en el futuro no descifre tráfico pasado, y certificados con SCT (Signed Certificate Timestamps) para integración con Certificate Transparency.

Exposición externa: subdominios, ports y cloud storage

Aquí es donde aparecen los hallazgos que más asustan a dirección y más fácil son de explotar.

Subdominios olvidados (shadow IT)

Cada subdominio que existió alguna vez deja huella en logs CT y en feeds DNS. Si apuntan a servicios externos abandonados (un Heroku que ya no usas, un GitHub Pages que perteneció a una campaña vieja, un bucket S3 de hace dos años), un atacante puede reclamarlo como propio y servir contenido desde tu marca. Eso es lo que se llama subdomain takeover, y aparece sistemáticamente como vulnerabilidad crítica en bug bounty.

Puertos expuestos

Paneles de administración accesibles desde Internet, bases de datos sin firewall, servicios de gestión expuestos. La regla operativa es: si no necesitas que esté en Internet, no debe estar en Internet.

Cloud storage expuesto

Buckets S3, contenedores Azure Blob, espacios Google Cloud Storage con configuración pública por error. Suelen contener backups, exports de bases de datos, documentos internos. Una mala configuración aquí es una de las brechas más rápidas que se pueden producir.

Diagnóstico rápido: los bloques "Riesgo de subdomain takeover", "Puertos expuestos" y "Almacenamiento cloud expuesto" del scanner detectan estos tres tipos de hallazgos sin tocar tus sistemas. Son chequeos Premium, accesibles en plan Starter (19 €/mes) en adelante.

Fugas en pastes, repositorios y datasets de IA

Una parte importante de la exposición ya no está en tu dominio sino fuera de él: en sitios donde se publica código y texto que alguien dentro de tu organización ha podido compartir por error.

Pastes y repositorios públicos

Pastebin, GitHub, GitLab público, foros técnicos. Búsquedas automáticas de tu dominio, tus correos, tus nombres internos o tus claves API en estos sitios revelan filtraciones que el equipo de seguridad puede no haber detectado.

Datasets de IA y archivos abiertos

Common Crawl, datasets públicos de entrenamiento, archive.org. Tu contenido público puede estar incluido en datasets que alimentan a modelos generativos, y eso tiene dos lecturas: comercial (control sobre cómo te citan los LLMs) y de seguridad (información sensible que se filtró públicamente y ahora forma parte de un dataset).

Información expuesta por error

Archivos `.env` accesibles, `.git` expuesto, documentos PDF con metadatos internos (autor, ruta de archivo, software), backups con extensión predecible. Cada uno es una llave que puede no parecer importante hasta que alguien la usa.

Supply chain y NIS2: el riesgo de tus proveedores

La directiva europea NIS2 hace responsable a la organización del riesgo de su cadena de suministro tecnológica. Eso significa que si un proveedor tuyo (CRM, marketing, analítica, CDN, sistema de pago) sufre una brecha, debes haberlo detectado, evaluado el impacto sobre tu organización y dejado evidencia documentada de la respuesta.

Qué cubre exactamente

El control no es solo "saber qué proveedores tienes". Es saber qué proveedores tienen acceso a tus datos o sirven contenido desde tu dominio, qué brechas públicas han tenido y cuándo, qué impacto puede haber tenido sobre tu organización, y qué medidas tomaste como respuesta.

Cómo se detecta automáticamente

Hard2bit Scanner cruza los terceros tecnológicos detectados en tu dominio (vía HTTP headers, scripts cargados, registros DNS) contra una base de datos de brechas públicas documentadas. Si tu proveedor de email marketing tuvo una brecha hace 14 meses, aparece en el informe — y eso es exactamente lo que un auditor NIS2 querrá ver gestionado.

Diagnóstico rápido: el bloque "Brechas de proveedores" del scanner es uno de los pocos controles automáticos en castellano que aporta trazabilidad supply-chain alineada con NIS2.

Era IA: bots, llms.txt y Agent Readiness

Entre 2025 y 2026 ha aparecido una capa nueva en la postura pública de un dominio: cómo te ven los agentes de inteligencia artificial. La gente ya no solo busca tu marca en Google; le pregunta a ChatGPT, Claude, Perplexity o Gemini, y esos asistentes leen tu sitio de forma muy distinta a como lo lee un usuario.

Bloqueo selectivo de bots IA

Si quieres impedir que tu contenido alimente modelos generativos sin tu permiso, puedes bloquear GPTBot (OpenAI), ClaudeBot (Anthropic), Google-Extended (Google) y otros scrapers IA en `robots.txt`, en cabeceras HTTP y en `meta` tags. Si no lo haces, todo lo que publicas es susceptible de acabar en datos de entrenamiento.

llms.txt y el archivo de instrucciones para LLMs

Estándar emergente (no oficial todavía, pero ampliamente adoptado por sitios técnicos) que publica un archivo `llms.txt` en la raíz del dominio describiendo qué secciones del sitio son interesantes para un modelo, en qué formato, y bajo qué condiciones. Es a los agentes IA lo que `sitemap.xml` es a los buscadores.

Content-Signal, ai.txt y políticas de scraping

Señalización del tipo de contenido (informativo, comercial, transaccional), políticas explícitas sobre uso por modelos generativos (training sí, inferencia comercial no, citación con atribución sí) y marcado estructurado pensado para que un agente pueda interpretar entidades, productos, FAQs y precios. Todos son emergentes; quien los implemente pronto va a tener ventaja en cómo aparece en respuestas generativas.

Diagnóstico rápido: Hard2bit Scanner es de los pocos escáneres comerciales que evalúa hasta 11 estándares emergentes de AI Agent Readiness (4 básicos en plan Starter, 11 totales en Pro). Es un terreno en el que la mayoría de la competencia aún no entra.

Qué hacer si tu dominio falla en alguno de estos puntos

La regla general es que los hallazgos se reparten en dos cubos.

Hallazgos de configuración (mayoría)

SPF/DKIM/DMARC ausentes o mal escritos, cabeceras HTTP que faltan, cookies sin atributos, certificados próximos a caducar, bots IA sin bloquear. El 70-80% de los hallazgos típicos son de este tipo. Se arreglan con un cambio en DNS o en la configuración del servidor web, en cuestión de horas o pocos días, y no requieren equipo especializado.

Hallazgos estructurales (los importantes)

Subdomain takeover activo, brechas de proveedores no gestionadas, cloud storage expuesto con datos sensibles, integración con un proveedor que tuvo una brecha pública el año pasado y no se evaluó el impacto. Estos son los que pueden requerir respuesta a incidentes, pentesting de validación o un proyecto de auditoría más profundo. La diferencia entre estos dos cubos es lo que separa "lo arreglo este viernes" de "necesito hablar con alguien serio".