En los últimos años, Google ha observado que los ataques distribuidos de denegación de servicio (DDoS) están aumentando en frecuencia y en tamaño exponencialmente. Las cargas de trabajo orientadas a Internet de hoy en día corren un riesgo constante de ataques con impactos que van desde el rendimiento y la experiencia del usuario degradados para los usuarios legítimos, hasta el aumento de los costos operativos y de hospedaje, hasta la indisponibilidad total de las cargas de trabajo de misión crítica. Los clientes de Google Cloud pueden usar Cloud Armor para aprovechar la escala global y la capacidad del borde de la red de Google para proteger su entorno de algunos de los ataques DDoS más grandes jamás vistos. El 1 de junio, un cliente de Google Cloud Armor fue blanco de una serie de ataques HTTPS DDoS que alcanzaron un máximo de 46 millones de solicitudes por segundo. Este es el DDoS de capa 7 más grande informado hasta la fecha, al menos un 76 % más grande que el registro informado anteriormente. Para dar una idea de la escala del ataque, es como recibir todas las solicitudes diarias a Wikipedia (uno de los 10 sitios web más traficados del mundo) en solo 10 segundos. Cloud Armor Adaptive Protection pudo detectar y analizar el tráfico en las primeras etapas del ciclo de vida del ataque. Cloud Armor alertó al cliente con una regla de protección recomendada que luego se implementó antes de que el ataque alcanzara su máxima magnitud. Cloud Armor bloqueó el ataque asegurando que el servicio del cliente permaneciera en línea y siguiera atendiendo a sus usuarios finales.Qué sucedió: análisis de ataques y cronograma A partir de las 9:45 a. m. (hora del Pacífico) del 1 de junio de 2022, comenzó un ataque de más de 10 000 solicitudes por segundo (rps) dirigido al equilibrador de carga HTTP/S de nuestro cliente. Ocho minutos después, el ataque creció a 100 000 solicitudes por segundo. Cloud Armor Adaptive Protection detectó el ataque y generó una alerta que contenía la firma del ataque al evaluar el tráfico en varias docenas de características y atributos. La alerta incluía una regla recomendada para bloquear la firma maliciosa. La siguiente es la alerta que muestra los detalles del ataque antes de que llegara a su punto máximo. El equipo de seguridad de la red de nuestro cliente implementó la regla recomendada por Cloud Armor en su política de seguridad e inmediatamente comenzó a bloquear el tráfico de ataque. En los dos minutos que siguieron, el ataque comenzó a intensificarse, pasando de 100 000 rps a un pico de 46 millones de rps. Dado que Cloud Armor ya estaba bloqueando el tráfico de ataque, la carga de trabajo objetivo siguió funcionando con normalidad. Durante los siguientes minutos, el ataque comenzó a disminuir en tamaño y finalmente finalizó 69 minutos después a las 10:54 a. m. Presumiblemente, el atacante probablemente determinó que no estaba teniendo el impacto deseado e incurrió en gastos significativos para ejecutar el ataque. analizando el ataque Además de su volumen de tráfico inesperadamente alto, el ataque tenía otras características destacables. Hubo 5.256 IP de origen de 132 países que contribuyeron al ataque. Como puede ver en la Figura 2 anterior, los 4 principales países contribuyeron con aproximadamente el 31 % del tráfico total de ataques. El ataque aprovechó las solicitudes cifradas (HTTPS) que habrían necesitado recursos informáticos adicionales para generarse. Aunque era necesario finalizar el cifrado para inspeccionar el tráfico y mitigar el ataque de manera efectiva, el uso de HTTP Pipelining requirió que Google completara relativamente pocos protocolos de enlace TLS. Aproximadamente el 22% (1.169) de las IP de origen correspondieron a nodos de salida de Tor, aunque el volumen de solicitudes provenientes de esos nodos representó solo el 3% del tráfico de ataque. Si bien creemos que la participación de Tor en el ataque fue incidental debido a la naturaleza de los servicios vulnerables, incluso al 3 % del pico (más de 1,3 millones de rps), nuestro análisis muestra que los nodos de salida de Tor pueden enviar una cantidad significativa de tráfico no deseado a aplicaciones y servicios web. La distribución geográfica y los tipos de servicios no seguros aprovechados para generar el ataque coinciden con la familia de ataques Mēris. Conocido por sus ataques masivos que han batido récords DDoS, el método Mēris abusa de servidores proxy no seguros para ocultar el verdadero origen de los ataques. Cómo detuvimos el ataque El ataque se detuvo en el borde de la red de Google y las solicitudes maliciosas se bloquearon antes de la aplicación del cliente. Antes de que comenzara el ataque, el cliente ya había configurado Adaptive Protection en su política de seguridad relevante de Cloud Armor para aprender y establecer un modelo de referencia de los patrones de tráfico normales para su servicio. Como resultado, Adaptive Protection pudo detectar el ataque DDoS en una etapa temprana de su ciclo de vida, analizar su tráfico entrante y generar una alerta con una regla de protección recomendada, todo antes de que el ataque se intensificara. El cliente actuó en la alerta implementando la regla recomendada aprovechando la capacidad de limitación de velocidad lanzada recientemente por Cloud Armor para acelerar el tráfico de ataque. Eligieron la acción de 'acelerador' en lugar de una acción de 'denegar' para reducir la posibilidad de impacto en el tráfico legítimo mientras limitaban severamente la capacidad de ataque al dejar caer la mayor parte del volumen de ataque en el borde de la red de Google. Antes de implementar la regla en modo de cumplimiento, primero se implementó en modo de vista previa, lo que permitió al cliente validar que solo se denegaría el tráfico no deseado mientras los usuarios legítimos podían continuar accediendo al servicio. A medida que el ataque aumentó a su pico de 46 millones de rps, la regla sugerida por Cloud Armor ya estaba implementada para bloquear la mayor parte del ataque y garantizar que las aplicaciones y los servicios objetivo permanecieran disponibles. Protegiendo sus aplicaciones en la nube El tamaño de los ataques seguirá creciendo y las tácticas seguirán evolucionando. Para estar preparado, Google recomienda utilizar una estrategia de defensa en profundidad mediante la implementación de defensas y controles en varias capas de su entorno y la red de sus proveedores de infraestructura para proteger sus aplicaciones y servicios web de ataques web dirigidos. Esta estrategia incluye realizar modelos de amenazas para comprender las superficies de ataque de sus aplicaciones, desarrollar estrategias proactivas y reactivas para protegerlas y diseñar sus aplicaciones con la capacidad suficiente para administrar aumentos imprevistos en el volumen de tráfico. Con Google Cloud Armor, puede proteger sus aplicaciones orientadas a Internet en el borde de la red de Google y absorber el tráfico no deseado mucho antes de sus aplicaciones. Gerardo J Gil Dams
