Así hemos vivido y repelido un ataque de DDoS contra Teknofilo.com

Esta mañana, al despertarme, he tardado algo más de lo habitual en revisar los nuevos mensajes de correo electrónico que habían llegado por la noche al buzón de Teknófilo.

Entre decenas de notas de prensa, invitaciones a «ganar mucho dinero» y algunos otros mensajes, me he encontrado con un par de mensajes del sistema de monitorización de la web.

El primer mensaje, anterior a las ocho de la mañana, me avisaba de que la web estaba caída. El segundo, una hora más tarde, confirmaba que la web seguía caída y me instaba a comprobar qué estaba pasando.

Con cierto escepticismo, me he dirigido a un navegador y he tecleado la URL principal, https://www.teknofilo.com. En efecto, algo estaba pasando, porque la web no cargaba. Empezamos mal el día — menos mal que ya he tomado café.

Los primeros minutos son de incertidumbre

El primer paso en estos casos es comprobar si el servidor está vivo. Al tratar de acceder al terminal del servidor vía SSH, he notado que algo no era normal: los tiempos de espera eran muy largos. Finalmente, tras varios minutos de espera, el servidor me ha dejado entrar.

Al consultar el estado del servidor, me he encontrado con que la carga de CPU era cientos de veces superior a la habitual y la memoria RAM estaba completamente agotada.

Carga de CPU del servidor en el momento del ataque

Rápidamente, me he puesto en contacto con el administrador de mi servidor, que también acababa de recibir algunos mensajes de nuestro proveedor de hosting, uno de los mayores de Europa, avisando de que se había detectado un ataque contra el dominio Teknofilo.com y, más tarde, otro diciendo que ya había terminado.

Tras matar todos los procesos del servidor web que se habían quedado colgados, la carga del servidor ha empezado a bajar y todo ha vuelto a funcionar. He respirado aliviado.

Sin embargo, la alegría ha durado poco. Al cabo de unos minutos, el ataque ha vuelto y el servidor se ha caído de nuevo. Al poco tiempo, el proveedor de hosting ha enviado un nuevo aviso indicando que estábamos recibiendo otro ataque.

Los dos ataques en el tiempo

Al consultar los logs del servidor web, ha quedado claro lo que estaba ocurriendo. Miles de IPs diferentes, de multitud de países (sobre todo, Indonesia, Estados Unidos, Brasil, Bangladesh e India) estaban accediendo a una URL de Teknofilo añadiendo caracteres aleatorios y diferentes al final de cada petición, como parámetros de la la URL.

No es habitual que la mayoría de nuestro tráfico venga de países donde no se habla español

¿Caracteres aleatorios al final de la URL? ¿Para qué?

La razón de añadir estos caracteres aleatorios es fácil de entender. La mayoría de los blogs, por no decir todos, utilizan un mecanismo de cache para servir más rápido las páginas.

Cuando un visitante accede a una página, esta se genera una vez y se guarda la copia ya generada como cache. Esta página cacheada (perdón por las patadas al diccionario) es la que se sirve a los visitantes que piden la misma página.

De esta forma, el esfuerzo computacional de generar la página (ejecución de código, consultas a la base de datos, etc.) solo se hace una vez, ya que a los siguientes visitantes se les sirve la página cacheada. Esta página cacheada tiene un tiempo de vida (por ejemplo, dos horas), pasado el cual, el cache se regenera.

El objetivo de añadir caracteres aleatorios al final de la URL no es otro que engañar al sistema de cache, que identifica cada petición como una URL diferente, por lo que no sirve la página cacheada sino que la genera de cero, con el esfuerzo computacional que ello conlleva. Si recibes miles de peticiones de páginas que no están en caché por minuto, el servidor acaba colapsando.

Activamos el modo «Under Attack»

Teknófilo, como muchas otras webs, utiliza CloudFlare para acelerar la entrega de imágenes y contenido estático, así como para protegernos de ataques. Este servicio de Internet se sitúa entre los visitantes y el servidor web, filtrando peticiones maliciosas para que no lleguen nunca al servidor.

Lamentablemente, CloudFlare no ha detectado este ataque de DDoS como tal, por lo que no lo ha parado automáticamente. Por suerte, CloudFlare tiene un botón llamado «Under Attack» que, al ser activado, frena la mayoría de ataques DDoS añadiendo medidas de seguridad adicionales.

En concreto, lo que hace este modo es lanzar un reto a todas las peticiones de páginas web de visitantes para distinguir tráfico humano (benigno) de tráfico de máquina (bots). No creo que sea necesario explicar que un ataque de DDoS se produce cuando muchos dispositivos generan tráfico de manera coordinada contra una web.

Reto de CloudFlare para distinguir tráfico humano de bots

Este reto, normalmente, es invisible al usuario, ya que supone la ejecución de un código Javascript por parte del navegador (según CloudFlare, esto puede añadir un retardo de hasta 5 segundos en la carga de la página web).

La mayoría de los ataques proceden de ordenadores o dispositivos que ejecutan scripts, sin usar navegadores reales, por lo que no son capaces de ejecutar el código Javascript y, por tanto, no resuelven el reto. En ese caso, la petición queda descartada por CloudFlare, sin llegar nunca al servidor web de Teknofilo.com.

En ciertas situaciones, CloudFlare opta por mostrar un captcha como reto y, en ese caso, el reto no es invisible para el visitante, sino que tiene que resolver el captcha para acceder a la página web. Esta es una de la razones por las que no es buena idea tener el modo «Under Attack» activo permanentemente, ya que resolver captchas es tedioso para los visitantes.

Al activar el modo «Under Attack», la web ha recuperado la normalidad, pero a ningún administrador web le gusta tener activo este modo durante mucho tiempo, ya que, como he comentado, supone un retraso en la carga de páginas (hasta 5 segundos por página), puede incomodar a ciertos visitantes que tienen que resolver captcha y, además, puede bloquear bots que sean benignos.

Un filtro para descartar tráfico sospechoso de ciertos países

Una vez que la web ya estaba dando servicio, el siguiente paso era repeler el ataque sin necesidad de estar en modo «Under Attack».

Al analizar los países de origen de los millones de peticiones que estábamos recibiendo, nos dimos cuenta de que la inmensa mayoría de ellos eran países donde no se habla español, por lo que no son fuente habitual de visitantes.

Por ello, añadimos una regla al firewall web de CloudFlare para filtrar mediante un reto las conexiones desde esos países, dejando libres de reto a España, Estados Unidos y países de Latinoamérica. En pocos minutos, esta regla bloqueó millones de conexiones, lo que claramente mostró que íbamos por el buen camino.

Regla de bloqueo de países mediante un reto

La razón de utilizar un reto en lugar de bloquear directamente las peticiones de estos países es que no queremos que aquellos visitantes que viajan se encuentren con que no pueden leer Teknofilo.com. Ya nos ha pasado alguna vez que, por bloquear un país, hemos sido contactados por algún lector habitual que no podía acceder a la página.

Además de esta regla, también hemos añadido otras para más seguridad, en caso de que se produjera otro ataque similar desde países que no están bloqueados.

Conclusiones

Cualquier web sufre a diario cientos de ataques, pero, por suerte, no es habitual recibir ataques de DDoS tan dañinos como este, al menos para una web como la nuestra.

En el caso de Teknófilo, utilizamos el plan gratuito de CloudFlare, por lo que todas las opciones de protección y mitigación de ataques que hemos visto en el artículo están disponibles sin coste. En el mercado hay otros servicios similares, aunque no los he probado.

En cualquier caso, mi recomendación es utilizar algún servicio de este tipo para proteger tu página web. De no haberlo tenido, no habríamos tenido forma de bloquear el ataque y quizás a estas horas seguiríamos offline.

Al final, afortunadamente, todo vuelve a la normalidad