El 18 de noviembre de 2025, a las 11:20 UTC, usuarios de todo el mundo comenzaron a ver errores HTTP 5xx al intentar acceder a sitios web protegidos por Cloudflare. Lo que inicialmente parecía un ataque masivo resultó ser un error interno complejo. La compañía ha publicado un análisis post-mortem detallado explicando el incidente.
Cuando se produce una crisis en una empresa la comunicación tiene que convertirse en esencial para informar a todos los actores que tienen que ver con ella. En empresas de tecnología es fundamental un análisis pormenorizado de lo que ocurrió para de ese modo resolver cualquier tipo de duda que pueda haber ocurrido. La actuación de Cloudflare ha sido un ejemplo de como se tiene que informar de un incidente de seguridad.
¿Qué causó la caída?
La informática está basada en límites. Existe un valor permitido para todo. Por ejemplo, se tiene un móvil con x GB de memoria en disco o x GB de memoria RAM. Las compañías de telefonía tienen límites para navegar al cabo de un mes, tienes una conexión a internet de 300 Mb etc.. Estos límites permiten restringir, acotar, los que un usuario tiene permitido hacer pero en otras circunstancias previene que ocurra en incidente aún más grave, o permite cerrar un sistema en un ataque.
A pesar de las especulaciones iniciales, Cloudflare ha confirmado que no se trató de un ciberataque ni de actividad maliciosa. La causa raíz fue técnica y se originó en una actualización de permisos en su sistema de bases de datos:
- El detonante: Un cambio en los permisos de un sistema de base de datos (ClickHouse) provocó que se generaran registros duplicados en un «archivo de características» (features file).
- El efecto dominó: Este archivo es vital para el sistema de gestión de bots de Cloudflare. Debido a los duplicados, el tamaño del archivo se duplicó, superando el límite de tamaño que el software de la red podía manejar.
- El fallo: Al recibir un archivo más grande de lo previsto, el software encargado de dirigir el tráfico en las máquinas de la red falló, provocando la interrupción del servicio.
Curiosamente, el sistema intentaba recuperarse periódicamente cuando se generaba un archivo correcto, lo que causó fluctuaciones que confundieron a los ingenieros, llevándoles a pensar inicialmente que estaban bajo un ataque DDoS.
Servicios Afectados
La interrupción no fue total, pero sí generalizada, afectando a componentes críticos:
- CDN y Seguridad: Errores 5xx visibles para los usuarios finales.
- Turnstile: No cargaba.
- Workers KV: Aumento considerable de fallos.
- Panel de Control (Dashboard): Inaccesible debido a la dependencia de Turnstile.
- Cloudflare Access: Fallos generalizados de autenticación.
Cronología de la Resolución
Según el RFC 3227 establece explícitamente que se debe «anotar la diferencia entre el reloj del sistema y UTC» y «para cada timestamp, indicar si se usa UTC o hora local».
Razones Críticas:
•Correlación de Eventos Globales: En un incidente de seguridad que involucra múltiples sistemas en diferentes zonas horarias, UTC permite correlacionar eventos con precisión absoluta.
•Admisibilidad Legal: Los tribunales requieren timestamps precisos y verificables. UTC es el estándar reconocido internacionalmente, lo que hace que la evidencia sea más admisible.
•Evita Ambigüedades: Los cambios de horario de verano, diferencias de zonas horarias y configuraciones locales pueden crear confusión. UTC elimina estas variables.
•Reconstrucción de Ataques: Para entender la secuencia exacta de un ataque (especialmente ataques coordinados o distribuidos), necesitas una línea temporal precisa y unificada.
•Deriva del Reloj: El RFC 3227 menciona específicamente «registrar la deriva del reloj del sistema» – esto es crucial porque los sistemas comprometidos pueden tener relojes manipulados o desincronizados.
La cronología del incidente utilizando la hora universal del planeta fue el siguiente:
- 11:20 UTC: Comienzan los fallos en la red.
- Diagnóstico: Tras descartar un ataque, se identificó el archivo corrupto.
- Solución: Se detuvo la propagación del archivo erróneo, se insertó manualmente una versión válida anterior y se forzó el reinicio del proxy central.
- 14:30 UTC: El tráfico principal comenzó a fluir con normalidad.
- 17:06 UTC: Todos los sistemas volvieron a funcionar al 100%.
Plan de respuesta a incidentes
El NIST (National Institute of Standards and Technology) proporciona directrices para gestionar incidentes de ciberseguridad. Estas directrices están documentadas en la publicación especial NIST SP 800-61 Rev. 2. El objetivo es minimizar el impacto de los incidentes y restaurar las operaciones lo antes posible.
Se pueden enumerar una serie de fases principales del ciclo de vida de un incidente:
1.Preparación: Implementar políticas y herramientas para estar preparados.
2.Detección y Análisis: Identificar y analizar el incidente.
3.Contención, Erradicación y Recuperación: Limitar el daño, eliminar la amenaza y restaurar los sistemas.
4.Lecciones Aprendidas: Revisar el incidente y mejorar los procesos.
La actuación de Cloudflare ha seguido este ciclo de vida y es un ejemplo de cómo actuar.
Conclusión
Cloudflare ha pedido disculpas por la interrupción, reconociendo que la caída de su red es inaceptable dada su importancia en el ecosistema de Internet. Han asegurado que están implementando medidas para evitar que un error de validación de archivos de este tipo vuelva a tumbar sus servicios en el futuro.
Fuente: Blog oficial de Cloudflare
