El mes de julio no está siendo bonito para los internautas, sobre todo aquellos que están de vacaciones y sólo quieren usar sus apps favoritas. Por una razón o por otra, algunos de los principales servicios de la Web han sufrido problemas en los últimos días; lo más interesante de todo es que estos problemas no parecen estar relacionados entre sí, y en muchas ocasiones son fruto de los propios errores de las compañías. Hoy mismo hemos hablado de cómo un posible error en la configuración interna de Facebook provocó un error que provocó que, durante varias horas, no pudieses descargar archivos ni ver imágenes en Facebook, Instagram y Whatsapp.

Lo chocante es que esa no es la primera vez esta semana que ocurrió algo semejante. Puede que os acordéis que el pasado 2 de julio publicamos un artículo sobre unos supuestos ataques DDOS contra Cloudflare; apps como Discord, Feedly y muchas más se vieron afectadas y dejaron de funcionar. En aquel momento, esa era la información más verídica que teníamos en base a los datos de tráfico, y la teoría apoyada por muchos expertos de seguridad; de hecho, no es la primera vez este año que Cloudflare recibe ataques semejantes. Sin embargo, cuando Cloudflare finalmente explicó lo que había pasado, lo hizo sintiendo algo de vergüenza.

Qué pasó con las apps que dependen de Cloudflare

Porque resulta que no era un ataque: en realidad, Cloudflare se había provocado estos problemas ella misma. Si fuese un Pokémon podríamos decir que estaba sufriendo los efectos de la confusión. Nadie tenía la culpa, y desde luego no era por un ataque DDOS. Era, simplemente, que Cloudflare se había “saboteado a si misma”.

Todo empezó cuando los administradores de Cloudflare implementaron nuevas reglas en su cortafuegos WAF (Web Application Firewall), con el objetivo de bloquear nuevos tipos de ataque que estaban sufriendo sus clientes. En concreto, con los cambios el cortafuegos de Cloudflare sería capaz de bloquear el código en Javascript usado en ataques a servicios web. Ahora bien, cuando una compañía como Cloudflare implementa este tipo de cambios, estos no se aplican directamente; en vez de eso, primero se prueban y en base a los resultados, se realizan modificaciones y se implementan en la versión final. A efectos prácticos, eso significa que la nueva regla realmente no bloqueaba el tráfico si detectaba el código en Javascript malicioso, sólo lo registraba.

El fallo de Cloudflare que puso los procesadores a 100

Pero una de estas reglas estaba mal; una expresión regular, usada para comprobar si el código malicioso estaba presente no había sido escrita correctamente, por lo que al ejecutarla, se entraba en un bucle. El resultado es que, en cuanto los administradores de Cloudflare introdujeron las nuevas reglas, los procesadores se pusieron inmediatamente al 100% de uso. El código había entrado en bucle y no podía hacer nada más que ejecutar una y otra vez estas reglas.

Este problema afectó a toda la red de Cloudflare, provocando errores en el 82% de las conexiones realizadas a su nube. Simplemente los procesadores estaban a tope y no podían dedicarse a responder a las peticiones de los clientes. Algo que duró aproximadamente media hora, durante la cual imaginamos que los ingenieros y administradores tuvieron que mantener la calma al ver lo que habían hecho. Es por eso que Cloudflare ha prometido que va a mejorar la manera en la que prueba los cambios, y no es para menos, teniendo en cuenta la cantidad de servicios que dependen de su nube.