Una de las claves de la CDN de nueva generación de Transparent Edge es lo en serio que quienes estamos detrás nos tomamos la seguridad de las aplicaciones web. En esta nueva entrada que firmamos los invisibles de la CDN, es decir, quienes integramos el equipo de soporte de la única CDN española, queremos contarte cómo recientemente descubrimos que alguien estaba tratando de ver cómo atacar a uno de nuestros clientes. No podemos decirte a cuál, pero sí te aseguramos que conoces de sobra su página web.
Todo comenzó en la revisión matutina de nuestros sistemas de monitorización. vimos que la noche anterior se había registrado un aumento muy significativo en el tráfico MISS asociado al cliente. Este tráfico MISS era el resultado de un número de peticiones a recursos que, en aquel momento, no se encontraban cacheados en nuestra plataforma. ¿A qué podía deberse?
El principio de la navaja de Ockham afirma que, en igualdad de condiciones, la explicación más sencilla a un determinado fenómeno suele ser la correcta. Nuestra primera hipótesis, apoyada en gran medida por experiencias pasadas, fue que se había ejecutado una invalidación de contenido por medio de expresiones regulares; lo que, coloquialmente y con permiso de la RAE, llamamos baneo.
Nuestra plataforma permite forzar la invalidación manual de contenido por parte de nuestros clientes cuando este se vuelve obsoleto; por ejemplo, si un medio digital necesita mostrar una nueva página de portada. Así, tanto interactuando a través de nuestro panel como atacando a nuestra API, es posible invalidar el contenido que el cliente precise en cada momento.
Grosso modo, distinguimos dos tipos de invalidación: el purgado, que afecta a recursos únicos, y el baneo, que actúa a través de expresiones regulares y expulsa de la caché todo objeto que encaje con dichas expresiones.
Como podrás deducir, un baneo puede llegar a ser muy peligroso y, si se nos va la mano, nos podemos pegar un tiro en el pie, desalojando de golpe de la caché una gran cantidad de objetos.
Obviamente, las peticiones subsiguientes a estos objetos serán MISS y, necesariamente, deberán ser recuperadas nuevamente de los backends asociados, es decir, de la plataforma del cliente.
Esta primera hipótesis comenzó a hacer aguas en cuanto acudimos a consultar los datos objetivos. En nuestras bases de datos registramos pormenorizadamente las actuaciones llevadas a cabo por parte de nuestros clientes, así que bastaba con consultar el historial de las invalidaciones realizadas por el cliente en cuestión. Allí vimos que las invalidaciones que se habían ejecutado en el intervalo de tiempo en el que se observó el aumento de tráfico MISS eran perfectamente normales. A ello se unía la tendencia de ese tráfico MISS: además de haber aumentado con una velocidad pasmosa, había caído igual de rápido. De hecho, analizando las gráficas de nuestros sistemas de monitorización comprobamos cómo este comportamiento anómalo había durado tan solo 4 minutos: desde las 22:22h hasta las 22:26h. Entonces, si el aumento de tráfico MISS no había sido causado por una invalidación, ¿de dónde venía?
Llegados a este punto y con la seguridad web en mente, el paso a dar era bajar al barro y analizar directamente los datos en crudo extraídos de los ficheros de log donde tenemos el registro exacto de todo el tráfico procesado por todos y cada uno de los nodos que constituyen nuestra plataforma de entrega de contenido (CDN).
Y aquí nos encontramos con la sorpresa: desde las 22:22h hasta las 22:26h se registraron, aproximadamente, 860.000 peticiones a la portada del site, pero cada una levemente modificada para cambiar la clave de caché, y así conseguir forzar un MISS e ir directamente contra el backend del cliente.
Analizando con detenimiento estas 860.000 peticiones observamos que se habían realizado desde un total de 2.400 direcciones IP diferentes y desde países tan dispares como Indonesia, Rusia, Brasil, EEUU, China, Colombia, India, Argentina, México o Ucrania, por citar nuestro particular top #10.
Lo más curioso del caso vino cuando analizamos minuciosamente estas peticiones. Y es que, a pesar del elevado cómputo global, no se habían distribuido de manera uniforme; por el contrario, nos encontrábamos con direcciones IP que habían realizado una única petición o dos o tres… Lo alarmante vino cuando apreciamos la tendencia: este número de peticiones iba subiendo progresivamente en una sucesión matemática hasta llegar a 10.000.
Fuera quien fuese el responsable, está claro que no estaba realizando ningún ataque: el número de peticiones nunca llegó a comprometer de modo alguno nuestra plataforma y, honestamente, nadie haría un ataque de únicamente 4 minutos de duración. De hecho, el indicativo en nuestra monitorización que levantó las sospechas fue el incremento del tráfico MISS, mientras que el resto de indicadores (uso de CPU, carga, consumo de memoria, consumo de ancho de banda, etcétera) jamás se vio perturbado de modo alguno.
Que no se estuviera ejecutando un ataque no significa que no se estuviera haciendo algo peligroso: se estaba tanteando el terreno. Fuera quien fuese el responsable, lo que presumiblemente pretendía era averiguar hasta dónde podía llegar antes de que las direcciones IP atacantes fueran bloqueadas. Por eso tan solo actuó durante 4 minutos y por eso fue escalando las peticiones de manera lineal: no quería hacer ruido, quería que su paso por nuestra plataforma pasara desapercibido… pero no lo hizo. Porque una de nuestras misiones tras la CDN es la seguridad web y tenemos configurada nuestra monitorización para evitarlo.
No sabemos quién fue y probablemente nunca lo llegaremos a averiguar. Lo que sí sabemos es que si decide hacer una nueva visita, esta vez con toda la artillería, nosotros lo estaremos esperando.A veces, Ockham se equivoca, pero son estas equivocaciones las que hacen que nuestro trabajo merezca la pena.
Alberto Suárez López es administrador de sistemas en Transparent Edge.
Más asturiano que la sidra, Alberto estudió Ingeniería Técnica en Informática de Gestión y un Posgrado en Ingeniería Web en la Universidad de Oviedo. Desde entonces, se ha enfrentado con todos los tipos de infraestructura UNIX posibles y ha doblegado a todos gracias a sus vastos conocimientos que hacen de él un todoterreno ante cualquier problema técnico.
Compartir:
