En agosto de 2023, Google, Cloudflare y AWS resistieron simultáneamente los mayores ataques DDoS registrados hasta ese momento — con picos en torno a 398 millones de peticiones por segundo. La causa no fue una botnet más grande sino una técnica más lista: un fallo del protocolo HTTP/2 ahora conocido como Rapid Reset, catalogado como CVE-2023-44487. Las tres empresas parchearon de forma coordinada antes de divulgarlo, precisamente porque la técnica permitía que un puñado de máquinas golpeara muy por encima de su tamaño.
Cómo funciona Rapid Reset
HTTP/2 multiplexa muchas peticiones sobre una sola conexión TCP, y permite a un cliente cancelar una petición de inmediato con un frame RST_STREAM. Rapid Reset abusa de eso enviando un flujo continuo de pares de petición-y-cancelación-inmediata. El servidor hace el trabajo caro de montar y desmontar cada petición a un ritmo extremo, pero el atacante nunca tiene que mantener conexiones longevas — así que una huella diminuta genera una enorme tasa de peticiones.
La eficiencia se convirtió en la vulnerabilidad
Una botnet de unas 20.000 máquinas produjo 398 millones de peticiones por segundo contra Google. Un ataque HTTP/1.1 comparable habría necesitado unas 100 veces más bots. La misma característica que hace rápido a HTTP/2 es la que abarató tanto el ataque.
Mitigación
- Parchea tu implementación de HTTP/2 — todos los grandes servidores web han publicado una corrección para CVE-2023-44487.
- Limita SETTINGS_MAX_CONCURRENT_STREAMS a nivel de servidor o de proxy.
- Aplica límite de tasa a los frames RST_STREAM por conexión para que las cancelaciones rápidas se estrangulen.
- Termina HTTP/2 en un proxy inverso delante de tu origen — el proxy de Akarguard gestiona la capa HTTP/2 en tu nombre, así que un origen sin parchear queda protegido de la técnica en bruto.
La lección más amplia
Rapid Reset fue un punto de inflexión porque mostró que la frontera se había desplazado del ancho de banda bruto a la astucia de protocolo — ataques de capa de aplicación baratos de lanzar y difíciles de distinguir del tráfico legítimo. La defensa duradera es terminar el transporte en un proxy inverso parcheado y endurecido de forma independiente, en lugar de exponer directamente a internet la pila HTTP/2 de tu origen. Akarguard hace esto en el edge: termina HTTP/2, absorbe el vaivén de petición/reset lejos de tu origen y aplica límites de tasa y desafíos al flujo de peticiones — mientras que el lado volumétrico de capa de red se queda con tu proveedor upstream. Cuando aparezca la próxima técnica a nivel de protocolo, un proxy mantenido por delante es lo que te compra tiempo para parchear.