edición general
142 meneos
2969 clics
Cloudflare: HTTP/2 Rapid Reset: cómo desarmamos el ataque sin precedentes (blog oficial)

Cloudflare: HTTP/2 Rapid Reset: cómo desarmamos el ataque sin precedentes (blog oficial)

El 25 de agosto de 2023, empezamos a observar algunos ataques de inundación HTTP inusualmente voluminosos que afectaban a muchos de nuestros clientes. Nuestro sistema DDoS automatizado detectó y mitigó estos ataques. Sin embargo, no pasó mucho tiempo antes de que empezaran a alcanzar tamaños sin precedentes, hasta alcanzar finalmente un pico de 201 millones de solicitudes por segundo, casi el triple que el mayor ataque registrado hasta ese momento.

| etiquetas: cloudflare , rapid reset , http/2
  1. “ Lo más inquietante es que el atacante fuera capaz de generar semejante ataque con una botnet de solo 20 000 máquinas” :-O
  2. #1 No me parece tan sorprendente, salen a 10.000 peticiones por segundo por cada máquina....

    Mis hijas en verano seguro que superan de largo esa cifra... :-/
  3. ¿Estará relacionado con el asunto de la activación de ECH?
  4. #3 En principio no tiene nada que ver, Rapid reset es una vulnerabilidad del protocolo http2 y el ECH es una ampliación del protocolo TLS, puede que al final tengan relación, pero yo no veo ninguna.
  5. Por eso va tan bien estos días OVH? :'(
  6. #3 #4 En teoría ya han desactivado ECH: www.meneame.net/story/cloudflare-ve-obligado-desactivar-ech-toda-red-s
    No se sabe si es por algo técnico y lo reactivarán cuando lo arreglen, o si es algo político y se quedará desactivado {0x1f610}
  7. #2 Creo que lo sorprendente era por la limitación de 100 concurrentes del servidor...
  8. La verdad es que los ataques ahora molan cuando van a por lo grandes como Cloudflare o akamai para que demuestren lo gorda que la tienen.
  9. #7 Pues eso sí que me parece sorprendente, si hasta yo acepto muchas más peticiones concurrentes de mi mujer... :troll:
  10. #7 Sí.
    O bien porque el cliente puede resetear conexiones sobre la marcha y no llegar nunca al límite a pesar de hacerlas a máxima capacidad (petición de conexión, petición de reset, rinse and repeat), o bien porque el cliente pase de esas limitaciones, resulta que el límite práctico de conexiones por cliente acaban siendo las que quepan en un paquete TCP, que son muchas más de 100, y el servidor no lo detecta como un abuso y sigue intentando procesarlas (y le lleva más tiempo que al cliente seguir enviándolas, por lo que se acumulan).

    Me encanta lo que se deduce de todo esto:
    - Que si hubieran usado una botnet de 100K máquinas, Cloudfare entero se habría caído durante horas tras 10 minutos de ataque.
    - Que los de Cloudfare están haciendo todo lo que pueden para presionar y que se arregle este fallo del protocolo antes de que los malos se pongan las pilas y ellos no puedan dar a basto.
  11. Tanto derroche de genio y tecnología para defenderse y no son capaces de poner los encabezados con un único tipo y peso de fuente.
  12. #8 o que Cloudflare o algunas de estas…pues…como los antivirus y los virus..tu ya me entiendes.
    Seguro que ahora Cloudflare tiene una avalancha de clientes…
    cough
  13. ¿Soy al único al que el texto en castellano le rechina? No sé si porque la traducción es regular o porque estoy muy acostumbrado a leer los téctos técnicos en inglés...pero me rechina, es como si no estuviese bien escrito, pero tampoco encuentro ninguna falta de forma o algo concreto.
  14. #13 será una traducción de una IA?
  15. #14 eso me ha parecido?
  16. #15 Tiene toda la pinta pero me despista el tratamiento de los tecnicismos. Puede ser un no nativo con buen nivel de español.
  17. #2 Si se trata de una botnet de IoT (lo normal últimamente) puede ser sorprendente
  18. #12 Demasiado riesgo, te puede salir el tiro por la culata muy fácilmente
  19. #16 también lo he pensado, que sea un técnico con un español muy bueno pero muy neutro.
  20. Será por los IoT chinorros que se compra la peña, hace no mucho me encontré un cliente que no podía acceder a Internet, tenía una cámara de vigilancia saturando el rúter con 8192 conexiones, aunque en este caso eran peticiones telnet.
comentarios cerrados

menéame