# Cómo Transparent Edge aseguró el sitio de una institución pública > Con la aparición de Transparent Edge se logró la estabilidad operativa y el control sobre el tráfico de sitios web de una institución pública. La estabilidad y disponibilidad de un sitio web son pilares fundamentales para cualquier entidad que ofrezca servicios críticos en línea. Para las instituciones públicas con alta visibilidad, esta exigencia se multiplica, especialmente en un contexto de ciberataques persistentes por parte de grupos *hacktivistas*. Este caso de estudio aborda la implementación de la plataforma de ciberseguridad web de **Transparent Edge** en una importante institución pública española sometida a constantes intentos de denegación de servicio. El objetivo principal era solucionar la caída recurrente de sus portales generada por ataques de denegación de servicio (DDoS) y estabilizar la disponibilidad de sus sitios web. ## Los desafíos La institución gestiona servicios de consulta críticos que profesionales y ciudadanos requieren para la toma de decisiones. La caída de sus sitios web, por breve que fuera, implicaba una interrupción directa en operaciones esenciales. El *stack* tecnológico subyacente presentaba desafíos inherentes al CMS de publicación que utilizan cuya arquitectura no está diseñada  para escenarios de concurrencia elevada, por lo que generaba un consumo excesivo de recursos en el origen y presentaba cierta fragilidad ante patrones que fuerzan el acceso al *backend*.  El origen procesaba cada petición, aun cuando el contenido era estático, lo que hacía que volúmenes relativamente modestos de tráfico degradaran el servicio. Esto se traducía rápidamente en *timeouts* y caídas del servicio, ampliando el impacto de cualquier ataque. ## Respuesta rápida Al inicio del proceso de *onboarding*, la institución experimentó una intensificación de ataques, tanto de volumetría como de *bots* dirigidos a capa de aplicación, atribuidos a la actividad del grupo [NoName057(16)](https://www.transparentedge.eu/blog/noname057-vuelve-a-la-carga/). Los sistemas devolvían respuestas muy lentas como síntoma de la saturación del origen y la caída de los sitios era recurrente. El reto era lograr que sus sitios web estuvieran disponibles, que la concurrencia de usuarios no tumbara sus portales, rechazar los ciberataques y estabilizar la experiencia de los usuarios legítimos. ## Despliegue de la estrategia de protección El equipo de Transparent Edge abordó el problema con un despliegue de arquitectura defensiva progresiva.  ### Under Attack Mode y Anti DDoS El primer paso fue activar el modo **[Under Attack Mode (UAM)](https://www.transparentedge.eu/blog/under-attack-mode/)**. Esta funcionalidad combina la mitigación del **Anti DDoS** de **[Perimetrical](https://www.transparentedge.eu/perimetrical/)** con desafíos a nivel de navegador para filtrar rápidamente el tráfico no deseado.  El anti DDoS analiza una gran variedad de señales (*fingerprints*, patrones comportamentales y reputación de red) para detectar y bloquear tráfico sofisticado en tiempo real.  El sistema se adapta de forma instantánea ante nuevas amenazas. Si el atacante cambia la firma, el origen geográfico o la velocidad, la detección reacciona igualmente mediante otros indicadores de comportamiento. ### Configuración en el edge La necesidad de reducir las peticiones al origen se resolvió a través de un ***set-up* de *caching* optimizado**. Se configuró el *[caching](https://www.transparentedge.eu/blog/tres-mejoras-de-caching-para-optimizar-tu-presupuesto/)* para activos estáticos (imágenes, hojas de estilo) y contenido HTML, logrando una mejora sustancial en *hit ratio* y rendimiento.  Esta acción redujo de forma inmediata el consumo de recursos del origen mientras que al disminuir la presión sobre la infraestructura, desaparecieron los *time-outs* recurrentes. Para prevenir vectores de ataque que tienen como base la composición de los propios *permalinks* amigables (sobre todo en los sitios multiidioma) y mejorar el rendimiento del origen, se efectuaron redirecciones mediante expresiones regulares en código VCL, llevando así esa parte de la lógica al edge. ### WAF y detección de anomalías El **WAF** se activó inicialmente en modo detección y, sobre los datos reales de tráfico, se parametrizaron **[reacciones automáticas](https://www.transparentedge.eu/sistema-de-deteccion-de-anomalias/)** para diferentes anomalías.  La estrategia supone elevar desafíos o bloqueos solo cuando un evento sobrepasa un umbral plausible para un usuario humano.  Este *set-up* incluyó la creación de una ***auto-blacklist***para catalogar y agrupar automáticamente las IP identificadas como causantes de ataques DDoS. Ejemplos: - Más de xx req/s → envía alerta por correo. - Más de xx req/s → levanta un Captcha (acción manual obligatoria). - JS Challenge por IP sospechosa para garantizar que existiese navegador real. - Peticiones fuera de España durante incidentes → UAM temporal. - JS Challenge durante un periodo de tiempo si una IP realiza más de cierta cantidad de peticiones en un rango de tiempo al mismo host. - Bloqueos temporales ante ráfagas superiores de peticiones. - Limitaciones dinámicas a navegadores automatizados como Selenium. - Reglas específicas para POST/PUT ligados a formularios o consultas AJAX. ## La solución de Transparent Edge en acción Tras la puesta en marcha, rápidamente se vieron los resultados. Los ataques volumétricos dejaron de tumbar los sitios y el tráfico automatizado se filtró antes de llegar al *backend* sin repercutir ningún impacto en los usuarios.  La analítica del panel de control puso de manifiesto gran cantidad de *scrapers*, secuencias de URL que forzaban peticiones directas al *backend*, intentos de *cross-site scripting* (XSS) y *JSON based SQL injection*  dirigidos a formularios y funcionalidades de búsqueda que antes no habían sido detectadas en tiempo real.  ### Personalización de casuísticas y listas blancas Un incidente operativo temprano se produjo al detectar que un servicio de accesibilidad de terceros embebido mediante \ no funcionaba adecuadamente. Al provenir de fuera de España y ejecutar código, era inicialmente bloqueado por las políticas geográficas y el UAM. Esto se resolvió mediante la inclusión del proveedor externo en la **lista blanca de IP**. En operación normal, cualquier IP no incluida en la lista blanca que se comportara como *bot* recibe un desafío JS. Fue necesario realizar ajustes específicos para agencias de noticias y organizaciones asociadas que realizan *scraping* legítimo (a menudo usando User-Agents como Selenium). Se establecieron listas blancas y parámetros límites controlados para garantizar que su actividad no afecte a la disponibilidad. A partir de estas iteraciones, el cliente pudo visualizar con claridad cuál es tráfico legítimo, qué es ruido y cuándo se trata de una anomalía que requiere mitigación.  El *dashboard* dejó de ser un panel reactivo y se convirtió en una herramienta de control y observabilidad. El equipo técnico opera con datos fiables y en tiempo real de forma preventiva en lugar de apagar incendios. ## Nuestras acciones producen resultados La integración no requirió reestructurar procesos existentes. El impacto operativo de mitigar ataques DDoS y filtrar tráfico inválido redujo presión en el *backend* y la adopción de una caché permitió recortar las peticiones al origen.  Con la plataforma activa, la institución pública trabaja con un alto *hit ratio* (cercano al 86 %), considerando que existen excepciones definidas a petición del cliente para permitir que ciertos flujos pasen al origen. Aun así, el volumen de tráfico que llega a la infraestructura se ha reducido y sus sitios web ya no aparecen entre las listas de webs caídas en campañas de ciberataques. ![hit ratio](https://www.transparentedge.eu/wp-content/uploads/2025/11/TC-hit-ratio-300x196.png) ## Valor estratégico La plataforma de **Transparent Edge** filtra el ruido y lleva a cabo la mitigación de forma continua ofreciendo métricas fiables de tráfico, rendimiento web estable y protección de contenido. El equipo IT del cliente utiliza el *dashboard* para configurar reglas personalizadas y ajustes necesarios de forma autónoma. La plataforma [se integra en sus tareas cotidianas con lógica de servicio](https://www.transparentedge.eu/blog/protegiendo-la-web-mediante-edge-computing/) y el núcleo de su actividad se centra ahora en definir criterios en lugar de resolver incidentes. La implementación que comenzó en un contexto de presión operativa hoy resulta una herramienta de control y resiliencia. El tráfico válido fluye y el inválido se neutraliza antes de llegar al origen. Los equipos de tecnología pueden centrarse en mantener recursos críticos disponibles y estables para la variedad de usuarios que los necesitan. [Sonia Arévalo](https://www.linkedin.com/in/soniaarevalo/) es Product Marketing Manager en Transparent Edge. > *Cómo acabó una Analista de Sistemas estudiando Tecnología de los Alimentos es complicado de explicar. Si le añades que luego decidió dedicarse al Marketing Digital, ya es un enigma completo que esta chica haga tantas cosas bien. Más argentina que el asado, Sonia mantiene nuestra web y redes sociales traduciendo el* *élfico* *lenguaje técnico a algo asimilable para la gente normal. “Exselente” es su interjección favorita, que hace juego con su trabajo.* --- Fuente: https://www.transparentedge.eu/blog/como-transparent-edge-aseguro-el-sitio-de-una-institucion-publica/ Actualizado: 2026-07-29