¿Desactivó Cloudflare durante la caída? Compruebe ya los registros en busca de una posible intrusión.

Un fallo importante en la infraestructura de Cloudflare se convirtió para numerosas empresas en una prueba inesperada de la solidez de sus propios sistemas de defensa. 18 de noviembre las interrupciones en los servicios de la compañía dejaron fuera de servicio sitios web en varias ocasiones en todo el mundo, y parte de los clientes intentó abandonar temporalmente la plataforma para mantener la disponibilidad de sus recursos. Esta maniobra forzada resultó además en que las aplicaciones web perdieron durante varias horas el filtro habitual de tráfico malicioso que Cloudflare suele detener en el perímetro de la red.

Los problemas comenzaron alrededor de las 6:30 EST (11:30 UTC), cuando en la página de estado apareció una notificación de degradación de servicios internos. Varias horas después los recursos volvían a funcionar y de nuevo dejaban de estar disponibles. La situación se complicó porque el portal de Cloudflare con frecuencia no se abría, y muchos dominios dependían al mismo tiempo del servicio de DNS de la compañía, lo que dificultó técnicamente el cambio a soluciones alternativas. A pesar de ello, algunos propietarios de sitios modificaron la ruta de enrutamiento, y fue ese intento de mantener la disponibilidad sin apoyarse en el perímetro protector de Cloudflare lo que hizo su infraestructura más visible para los atacantes.

Expertos externos señalan que la plataforma logra mitigar eficazmente los tipos más comunes de ataques a nivel de aplicación, incluidos los ataques de fuerza bruta contra credenciales, la inyección SQL, los intentos de eludir controles en las API y numerosos escenarios de tráfico automatizado. Por ello la pérdida repentina de esa capa reveló debilidades no evidentes —desde reglas omitidas en las herramientas locales de protección hasta compromisos antiguos en las validaciones del lado de la aplicación. En un caso, el aumento del volumen de registros fue tan brusco que la empresa aún investiga qué eventos fueron intentos reales de intrusión y cuáles representaron ruido.

Los analistas subrayan que durante el período en que parte de los grandes sitios tuvo que operar sin Cloudflare, cualquier observador pudo notar cambios en los registros DNS y comprender que el perímetro protector había desaparecido. Para las bandas criminales esos periodos son una oportunidad para ejecutar ataques que antes eran bloqueados en el perímetro, sobre todo si el objetivo ya estaba bajo vigilancia. Por eso a las organizaciones que redirigieron tráfico a rutas alternativas les conviene revisar detenidamente los registros de eventos y asegurarse de que, tras la restauración del esquema habitual, no hayan quedado puntos ocultos de presencia de intrusos.

Posteriormente Cloudflare publicó un análisis del incidente. La compañía indicó que la interrupción no estuvo relacionada con ataques o acciones maliciosas. La causa fue un error en los permisos de una de las bases de datos internas, que provocó la aparición de un gran número de entradas en un archivo de configuración separado para el sistema de gestión de bots. El tamaño del archivo se duplicó y luego se propagó automáticamente por toda la red, provocando una cascada de fallos. Teniendo en cuenta que aproximadamente una quinta parte de internet utiliza los servicios de Cloudflare, incidentes como este demuestran hasta qué punto los servicios web modernos son vulnerables a errores puntuales de un proveedor.

Una atención adicional merece la dependencia de puntos únicos de fallo. Consultores en riesgos de TI consideran lo sucedido un recordatorio de la necesidad de distribuir las funciones de protección entre varias zonas y proveedores. Para ello proponen implantar sistemas de filtrado, protección contra DDoS y servicio de DNS en distintas plataformas, segmentar las aplicaciones para que el fallo en uno de los proveedores no provoque una reacción en cadena, y monitorizar regularmente las dependencias críticas para detectar a tiempo la influencia de proveedores únicos.