--- title: "Empresa de servicios B2B, Europa: endurecer la web · Polargate" description: "El filtro DNS corporativo de uno de sus clientes rechazaba el dominio de nuestro cliente, y eso le impedía operar como proveedor de esa empresa." url: https://polargate.ai/es/work/security-hardening locale: es publisher: POLARGATE S.L. --- - [Polargate](https://polargate.ai/es) - [Proyectos](https://polargate.ai/es/work) - Empresa de servicios B2B, Europa Servicios B2B # Endurecer una web corporativa que un filtro DNS bloqueaba El filtro DNS corporativo de uno de sus clientes rechazaba el dominio de nuestro cliente, y eso le impedía operar como proveedor de esa empresa. La web no estaba comprometida ni en listas negras: estaba sin endurecer. Polargate la diagnosticó en una semana, migró el gestor de contenidos a un hosting bajo control del cliente y la endureció allí, porque el panel de administración era el único acceso disponible. En corto Polargate endureció la web corporativa de una empresa B2B después de que el filtro DNS corporativo de uno de sus clientes empezara a rechazar el dominio. Un diagnóstico de una semana con herramientas públicas de referencia descartó infección y listas negras. El TLS ya estaba bien, pero faltaban las seis cabeceras de seguridad habituales (nota de cabeceras: F), el hosting compartido exponía un certificado de respaldo caducado y no coincidente, y el servidor anunciaba sus versiones. Con solo acceso al panel del gestor de contenidos, migrar a un hosting del cliente era la única vía para endurecer. Después, las cabeceras dieron A+ en el host de migración, en 2026 y antes del cambio de DNS. Es una foto fechada de un host, no una propiedad permanente de la web. 6 cabeceras de seguridad habituales que faltaban antes del trabajo 24 páginas auditadas enlace a enlace tras el cambio de DNS, 12 por idioma 4 días desde la adjudicación hasta el cierre técnico ## El problema El disparador no fue un incidente de seguridad, fue un bloqueo comercial. El filtro DNS corporativo de uno de sus clientes rechazaba el dominio de nuestro cliente, y eso le impedía trabajar como proveedor de esa empresa. No había nada infectado: el diagnóstico no encontró compromiso ni presencia en listas negras. Lo que disparaba la clasificación automática de postura de seguridad baja era la configuración. El proveedor original recibió el listado de correcciones y respondió formalmente que quedaban fuera de su alcance. En esa negociación se perdieron unos tres meses antes de que el cliente cambiara de proveedor. Y el único acceso disponible para nosotros era el panel de administración del gestor de contenidos. ## Qué construimos Una semana de diagnóstico con herramientas públicas de referencia: análisis SSL, escaneo de cabeceras HTTP, reputación de dominio, navegación segura y antivirus multi motor. Después, tres fases. Migración del gestor de contenidos a un hosting bajo control del cliente, con verificación funcional y repaso de URLs y enlaces permanentes. Endurecimiento: las seis cabeceras que faltaban, más una Referrer-Policy estricta, una Permissions-Policy con las APIs sensibles deshabilitadas y una cabecera de servidor sin versión, junto al trabajo en la capa del gestor (login movido, rutas y ficheros comunes ocultos, protección de fuerza bruta, firewall de aplicación con bloqueo automático de IPs, XML-RPC y endpoints de descubrimiento apagados). Y limpieza de reputación. El cambio de DNS bajó el TTL con 24 a 48 horas de antelación y dejó intactos los registros de correo. ## El resultado Las cabeceras pasaron de F en el diagnóstico inicial a A+ tras el endurecimiento, en un escaneo forzado sin caché y sin avisos. Esa lectura se hizo sobre el host de migración en 2026, antes de cambiar el dominio en vivo, y no consta un re-escaneo posterior del dominio real, así que no la presentamos como nota de producción. Tras el cambio auditamos 24 páginas, 12 por idioma, enlace a enlace, y apareció que el reemplazo masivo de URLs inicial había sido incompleto. Cierre en cuatro días desde la adjudicación, con informe de entrega y garantía técnica de 30 días. ## Qué lo disparó de verdad No fue un incidente. Fue un bloqueo comercial. El filtro DNS corporativo de uno de sus clientes rechazaba el dominio de nuestro cliente, y un proveedor cuya web no resuelve dentro de la red de su cliente tiene un problema de negocio, no de informática. El encargo llegó como "les parece que estamos hackeados". No lo estaban. ## El diagnóstico, en una semana Entregamos un informe técnico de seguridad, SSL y reputación apoyado en herramientas públicas de referencia: análisis SSL, escaneo de cabeceras HTTP, reputación de dominio, navegación segura y antivirus multi motor. Cualquiera puede repetirlas todas, y esa es justo la gracia. La conclusión fue clara: la web no estaba comprometida ni figuraba en ninguna lista negra. Era un problema de endurecimiento y configuración, no de infección. El TLS ya estaba bien antes de empezar: certificado válido, TLS 1.3 activo, sin cifrados débiles, cadena válida y forward secrecy. La calificación SSL del diagnóstico inicial era A, antes de tocar nada. Lo que disparaba la clasificación automática de "postura de seguridad baja" con la que trabajan los filtros corporativos eran otras tres cosas: - Ninguna cabecera HTTP de seguridad. Nota de cabeceras: F. - Un certificado de respaldo caducado y no coincidente, expuesto por el hosting compartido. - Huellas del servidor a la vista: versión del intérprete, firma del panel de control y cabecera de tecnología. ## La restricción que decidió la arquitectura El único acceso disponible era el panel de administración del gestor de contenidos. Sin acceso al hosting, endurecer a nivel de servidor no es aplicable sobre la infraestructura original, así que migrar no fue una preferencia estética. Era la única vía. La alternativa era rehacer la web en código: una estimación de tres a seis semanas, con el dominio bloqueado durante todas ellas. La migración era reversible y desbloqueaba antes. La reconstrucción en estático se quedó en el cajón, como fase diferida. ## Qué se cambió, exactamente El trabajo fue en tres fases: migración con verificación funcional y repaso de URLs y enlaces permanentes, endurecimiento de seguridad y configuración, y limpieza de reputación. ### Cabeceras realmente servidas tras el endurecimiento HSTS con includeSubdomains, una Content-Security-Policy, la protección legacy contra XSS, nosniff, X-Frame-Options en SAMEORIGIN, una Referrer-Policy estricta, una Permissions-Policy con la lista completa de APIs sensibles deshabilitadas, y una cabecera de servidor sin versión. ### La capa del gestor de contenidos Remapeo de rutas internas, ocultación de rutas y ficheros comunes, login movido con URL de emergencia custodiada, protección de fuerza bruta, firewall de aplicación con bloqueo automático de IPs, XML-RPC desactivado, endpoints de descubrimiento apagados y detectores de tema bloqueados. Los rastreadores de IA se dejaron permitidos a propósito, porque la visibilidad en buscadores formaba parte del encargo. ### Lo que no hicimos, y no vamos a decir que hicimos En este proyecto no hubo WAF de red ni CDN. El único firewall fue el del plugin de endurecimiento del gestor. En cookies, la web mantuvo su plugin de consentimiento heredado y no nos consta trabajo sobre los flags de cookie, así que no lo reclamamos. En dependencias, el inventario final rondaba la veintena de plugins, tres de ellos añadidos por nosotros; no quedó registrada ninguna lista de CVE ni recuento de vulnerabilidades, así que no publicamos ninguna cifra de vulnerabilidades cerradas. ### El cambio de DNS TTL bajado con 24 a 48 horas de antelación, cambio del registro A y registros de correo (MX, SPF, DKIM y DMARC) intactos, para que el correo corporativo del dominio no se parase ni un minuto. ## Cómo se midió, y cuánto vale esa medición Antes: cabeceras F, SSL A. Después del endurecimiento: A+ en cabeceras, con escaneo forzado sin caché y sin avisos. Ese A+ se leyó sobre el host de migración, en 2026, antes de cambiar el dominio en vivo. No nos consta un re-escaneo del dominio real después del cambio, así que no presentamos el A+ como resultado de producción. Esto importa más allá de un proyecto. Una nota de cabeceras es una foto fechada de un host, no una propiedad que la web adquiere para siempre. Un embebido nuevo, un plugin nuevo o el valor por defecto de un proveedor y la nota se mueve. Si quieres saber qué puntúa una web hoy, escanéala hoy. ## La auditoría de enlaces, y por qué existe Tras el cambio de DNS auditamos 24 páginas, 12 en cada idioma, enlace a enlace. Ahí apareció que el reemplazo masivo de URLs inicial había sido incompleto. Quedaban referencias al entorno de preparación en el pie global, en los CTA del maquetador, en los enlaces de consentimiento de los formularios, en varios PDF, en textos legales y en una fuente de iconos del tema que devolvía error. La lección reutilizable: un reemplazo masivo puede ejecutarse en simulación y darse por hecho. Un cambio no está hecho hasta que se valida con una petición real contra el sitio en vivo. ## Cierre, y lo que no afirmamos El proyecto cerró con informe de entrega en PDF, trabajo técnico completo, auditoría de enlaces limpia y garantía técnica de 30 días. Cuatro días desde la adjudicación hasta el cierre técnico. Cuatro meses desde el incidente original, de los cuales unos tres se perdieron negociando con el proveedor anterior. Dos cosas que no afirmamos a propósito. No nos consta que ese cliente levantara el bloqueo DNS. Y las solicitudes de revisión de reputación presentadas al final seguían pendientes al cerrar, sin ningún desenlace registrado. ## El método, en orden El orden es el método, y el orden es la parte que sirve para la siguiente web. Medir con herramientas públicas que cualquiera puede repetir. Arreglar la configuración, no el relato. Volver a medir, diciendo sobre qué host y en qué fecha. Y auditar contra el sitio en vivo en lugar de contra el plan. [Build →](https://polargate.ai/es/services/build) · [Care →](https://polargate.ai/es/services/care) · [Grupos corporativos →](https://polargate.ai/es/for/corporate) FAQ ## Preguntas sobre este proyecto ¿Se puede arreglar una web que bloquea el filtro DNS de una empresa? Casi siempre el bloqueo va de postura de seguridad, no de infección. Aquí las herramientas públicas no encontraron compromiso ni lista negra: el TLS ya estaba bien, pero la web no servía ninguna cabecera de seguridad, el hosting compartido exponía un certificado de respaldo caducado y el servidor anunciaba sus versiones. Eso es configuración, y es justo lo que lee un clasificador automático. El límite honesto: podemos arreglar y evidenciar la postura, no podemos prometer que un tercero levante su bloqueo, y no nos consta que en este caso lo levantara. ¿Un A+ en cabeceras de seguridad es para siempre? No. Una nota es una lectura fechada de un host en un momento concreto, y así la publicamos. El A+ de este caso se midió sobre el host de migración en 2026, en un escaneo forzado sin caché, antes de cambiar el dominio en vivo. No nos consta un re-escaneo posterior del dominio real, así que no lo presentamos como resultado de producción. Además las notas se mueven solas: un embebido nuevo, un plugin nuevo o el valor por defecto de un proveedor cambian lo que sirve la web. Si la nota le importa a tus clientes, hay que volver a medirla periódicamente. ¿Hace falta acceso a nuestro hosting para endurecer la web? Para endurecerla donde vive, sí. Las cabeceras, el comportamiento de TLS y las huellas del servidor se configuran en el servidor, no en el gestor de contenidos. En este proyecto el único acceso disponible era el panel de administración, y el proveedor de entonces respondió formalmente que las correcciones quedaban fuera de su alcance, así que migrar a un hosting bajo control del cliente era la única vía que quedaba. Elegimos migrar en vez de rehacer porque era reversible y desbloqueaba antes: rehacer eran, según nuestra estimación, de tres a seis semanas con la web todavía bloqueada. ## Proyectos relacionados Globalia ### La plataforma web corporativa de Globalia Globalia, el grupo turístico español, tenía los datos de su gente en Microsoft 365 y su web pública por otro lado. Polargate construyó una sola plataforma web sobre un único repositorio: el directorio de empleados sincronizado desde Microsoft 365, una tarjeta de visita digital con pases de Apple Wallet y Google Wallet, y la web pública del grupo, hecha legible para los rastreadores de IA sin rehacerla. Pedro Ciordia trabaja en Globalia, así que esto es facturación con una parte vinculada y no un cliente ganado en el mercado abierto. 2026 Ver el caso [La plataforma web corporativa de Globalia](https://polargate.ai/es/work/corporate-web-platform) Global Dynamic Security Group ### Marca y web bilingüe para Global Dynamic Security Group Identidad de marca, manual de identidad de 15 páginas y web corporativa bilingüe (español e inglés) para Global Dynamic Security Group (GDS), un grupo de seguridad privada en República Dominicana, entregado como proyecto cerrado a precio fijo. 2026 Ver el caso [Marca y web bilingüe para Global Dynamic Security Group](https://polargate.ai/es/work/security-group-brand-and-site) NationwideLegal ### El CRM de NationwideLegal, sobre Odoo 18 NationwideLegal lleva su operación comercial en un CRM que Polargate construyó sobre Odoo 18 Enterprise y del que sigue llevando la dirección técnica: un único módulo propio, cinco modelos nuevos, los permisos rehechos alrededor de cómo vende el equipo de verdad y una verificación contra producción después de cada despliegue. 2026 Ver el caso [El CRM de NationwideLegal, sobre Odoo 18](https://polargate.ai/es/work/legal-services-crm-and-technology-direction) INITIATE ## Arranca el motor Cuéntanos qué estás construyendo en unas pocas preguntas cortas. Un ingeniero senior responde por escrito en 48 horas laborables con una primera lectura de alcance, plazos y precio. [Empieza tu proyecto](https://polargate.ai/es/start) · [Habla con nosotros](https://polargate.ai/es/start#static-brief-heading)