Un corte intermitente en Llamarada de nube el martes dejó brevemente fuera de línea a muchos de los principales destinos de Internet. Algunos clientes de Cloudflare afectados pudieron abandonar la plataforma temporalmente para que los visitantes aún pudieran acceder a sus sitios web. Pero los expertos en seguridad dicen que hacerlo también puede haber desencadenado una prueba de penetración de red improvisada para las organizaciones que han llegado a confiar en Cloudflare para bloquear muchos tipos de tráfico abusivo y malicioso.
Alrededor de las 6:30 EST/11:30 UTC del 18 de noviembre, la página de estado de Cloudflare reconoció que la empresa estaba experimentando «una degradación interna del servicio». Después de varias horas de que los servicios de Cloudflare volvieran a funcionar y fallaran nuevamente, muchos sitios web detrás de Cloudflare descubrieron que no podían dejar de usar los servicios de la compañía porque el portal de Cloudflare era inaccesible y/o porque también estaban obteniendo sus servicios de sistema de nombres de dominio (DNS) de Cloudflare.
Sin embargo, algunos clientes lograron sacar sus dominios de Cloudflare durante la interrupción. Y muchas de esas organizaciones probablemente necesiten observar más de cerca los registros de su firewall de aplicaciones web (WAF) durante ese tiempo, dijo Aarón Turnermiembro de la facultad de Investigación del IANS.
Turner dijo que el WAF de Cloudflare hace un buen trabajo filtrando el tráfico malicioso que coincide con cualquiera de Los diez tipos principales de ataques a la capa de aplicación.incluido el relleno de credenciales, secuencias de comandos entre sitios, inyección SQL, ataques de bots y abuso de API. Pero dijo que esta interrupción podría ser una buena oportunidad para que los clientes de Cloudflare comprendan mejor cómo las defensas de sus propias aplicaciones y sitios web pueden estar fallando sin la ayuda de Cloudflare.
«Sus desarrolladores podrían haber sido flojos en el pasado con respecto a la inyección SQL porque Cloudflare detuvo esas cosas en el borde», dijo Turner. «Tal vez no tenías el mejor control de calidad (QA) de seguridad para ciertas cosas porque Cloudflare era la capa de control para compensar eso».
Turner dijo que una empresa con la que trabaja vio un enorme aumento en el volumen de registros y todavía están tratando de descubrir qué era «legítimamente malicioso» versus simplemente ruido.
«Parece que hubo una ventana de aproximadamente ocho horas en la que varios sitios de alto perfil decidieron evitar Cloudflare en aras de la disponibilidad», dijo Turner. “Muchas empresas han confiado esencialmente en Cloudflare para Los diez mejores de OWASP (vulnerabilidades de aplicaciones web) y una amplia gama de bloqueo de bots. ¿Cuánta maldad pudo haber pasado en esa ventana? Cualquier organización que haya tomado esa decisión debe observar de cerca cualquier infraestructura expuesta para ver si hay alguien que persista después de haber vuelto a las protecciones de Cloudflare».
Turner dijo que algunos grupos de delitos cibernéticos probablemente se dieron cuenta cuando un comerciante en línea al que normalmente acechaban dejó de usar los servicios de Cloudflare durante la interrupción.
«Digamos que eres un atacante que intenta abrirse camino hacia un objetivo, pero sientes que Cloudflare estaba en el camino en el pasado», dijo. «Luego, a través de los cambios de DNS, ves que el objetivo ha eliminado Cloudflare de su pila web debido a la interrupción. Ahora vas a lanzar un montón de nuevos ataques porque la capa protectora ya no está en su lugar».
nicole scottgerente senior de marketing de productos en McLean, Virginia, Réplica cibernéticacalificó la interrupción de ayer como «un ejercicio de mesa gratuito, ya sea que quisiera ejecutar uno o no».
«Esa ventana de pocas horas fue una prueba de estrés en vivo de cómo su organización se desplaza alrededor de su propio plano de control y la TI en la sombra florece bajo la lámpara solar de la presión del tiempo», dijo Scott en una publicación en LinkedIn. «Sí, observe el tráfico que lo afectó mientras las protecciones estaban debilitadas. Pero también observe detenidamente el comportamiento dentro de su organización».
Scott dijo que las organizaciones que buscan información sobre seguridad tras la interrupción de Cloudflare deberían preguntarse:
1. ¿Qué se desactivó o se omitió (WAF, protecciones contra bots, bloqueos geográficos) y durante cuánto tiempo?
2. ¿Qué cambios de emergencia en el DNS o en el enrutamiento se realizaron y quién los aprobó?
3. ¿La gente cambió su trabajo a dispositivos personales, Wi-Fi doméstico o proveedores de software como servicio no autorizados para evitar la interrupción?
4. ¿Alguien defendió nuevos servicios, túneles o cuentas de proveedores “sólo por ahora”?
5. ¿Existe un plan para deshacer esos cambios o son ahora soluciones permanentes?
6. Para el próximo incidente, ¿cuál es el plan alternativo intencional, en lugar de una improvisación descentralizada?
En una autopsia Publicado el martes por la noche, Cloudflare dijo que la interrupción no fue causada, directa o indirectamente, por un ciberataque o actividad maliciosa de ningún tipo.
«En cambio, fue provocado por un cambio en los permisos de uno de nuestros sistemas de bases de datos, lo que provocó que la base de datos generara múltiples entradas en un ‘archivo de características’ utilizado por nuestro sistema de gestión de bots», dijo el CEO de Cloudflare. Príncipe Mateo escribió. «Ese archivo de características, a su vez, duplicó su tamaño. Luego, el archivo de características más grande de lo esperado se propagó a todas las máquinas que componen nuestra red».
Cloudflare estima que aproximadamente el 20 por ciento de los sitios web utilizan sus servicios, y gran parte de la web moderna depende en gran medida de un puñado de otros proveedores de nube, incluidos AWS y Azurincluso una breve interrupción en una de estas plataformas puede crear un único punto de falla para muchas organizaciones.
Martín Greenfielddirector ejecutivo de la consultora de TI Quod Orbisdijo que la interrupción del martes fue otro recordatorio de que muchas organizaciones pueden estar poniendo demasiados huevos en una sola canasta.
«Hay varias soluciones prácticas que deberían haberse hecho hace tiempo», advirtió Greenfield. «Divida su patrimonio. Distribuya la protección WAF y DDoS en múltiples zonas. Utilice DNS de múltiples proveedores. Segmente las aplicaciones para que una interrupción de un solo proveedor no se produzca en cascada. Y supervise continuamente los controles para detectar la dependencia de un solo proveedor».
On November 18, a significant outage at Cloudflare temporarily knocked many major internet destinations offline. While some clients successfully bypassed the platform to maintain access for visitors, security experts cautioned that this could have triggered an improvised penetration test as organizations relying on Cloudflare for protection from abusive and malicious traffic no longer had those defenses in place.
Around 6:30 EST/11:30 UTC, Cloudflare’s status page indicated an «internal service degradation.» After several hours of intermittent service, many websites discovered they could not stop using Cloudflare due to inaccessibility of the portal and reliance on Cloudflare for DNS services. However, some managed to remove their domains from Cloudflare during the outage. According to Aarón Turner from IANS Research, those organizations need to scrutinize their web application firewall (WAF) logs closely, as Cloudflare had been effective at filtering out various types of malicious traffic.
Turner remarked that the outage provided an opportunity for clients to reassess the security defenses of their applications and websites without Cloudflare’s protections, indicating that some development teams may have neglected security measures due to their reliance on Cloudflare.
Some clients noticed a spike in log activity during the outage and struggled to differentiate between legitimate threats and noise. Turner explained that cybercriminals likely recognized that certain targets had removed Cloudflare from their tech stack, prompting a surge in attacks. This situation reflects a gap in security for organizations that depend solely on third-party services for protection.
Nicole Scott, a senior product marketing manager at Cyber Replicator, referred to the outage as an unintentional stress test for organizations. She suggested that affected entities should investigate the interruptions in their security controls and internal behaviors during the outage. Scott recommended that organizations ask critical questions about what security measures were disabled, the approvals for emergency DNS or routing changes, and whether staff used personal devices or unauthorized services to skirt limitations.
In a post-mortem released shortly after the incident, Cloudflare stated that the outage was not the result of a cyberattack but rather due to changes in the permissions of one of their database systems. This caused the database to generate multiple entries in a feature file, which subsequently grew larger than expected and propagated throughout their network.
Cloudflare estimates that about 20% of websites depend on their services, and many modern web infrastructures are heavily reliant on a few cloud providers. Thus, even short disruptions in these services can create single points of failure for numerous organizations.
Martin Greenfield, CEO of IT consultancy Quod Orbis, emphasized that the outage highlighted the risks of over-reliance on a single provider. He advised organizations to take practical steps to diversify their digital infrastructure, including spreading their assets across multiple providers for WAF and DDoS protection, utilizing multiple DNS providers, segmenting applications, and maintaining oversight of their vendor dependencies.
Overall, the incident serves as a crucial reminder of the vulnerabilities inherent in relying on single points of failure in the technology stack, urging organizations to bolster their security frameworks and preparedness for future disruptions.