Herramienta Slow Loris de RSnake

Question

Herramienta Slow Loris de RSnake

#1 de WhiteWinterWolf (4 votos)

4

Estaba viendo la implementación de RSnakes de su Slow Loris hecha en perl que se puede ver aquí . Configuré un pequeño servidor para escuchar sus paquetes, y al principio encontré esto

GET / HTTP/1.1\r\nHost: David-PC\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\nContent-Length: 42\r\n

Sí, así es como debería verse un encabezado de Slow Loris, por lo que es ideal, pero después de un tiempo recibí más datos en el mismo zócalo que estaba

X-a: b\r\n

Y esto se enviaría continuamente después de intervalos de tiempo en los mismos sockets que ya hicieron conexiones y enviaron el primer encabezado, y el programa continuaría haciendo nuevas conexiones después de intervalos de tiempo.

Mi pregunta es, ¿cuál es el uso de la segunda parte de los datos enviados?

X-a: b\r\n

¿Es significativo?

denial-of-service http packet

pregunta user3818650 18.04.2015 - 10:04

fuente

1 respuesta

Lea otras preguntas en las etiquetas denial-of-service http packet

¿Qué clave pública de GPG debo publicar? ¿Debo limpiar una máquina y un disco duro nuevos?

score 4 · Accepted Answer

Esta segunda parte de los datos enviados es en realidad parte de un bucle para mantener artificialmente alguna actividad en la línea.

Si su secuencia de comandos solo estaba abriendo la conexión al servidor, envíe el primer encabezado, luego espere pasivamente, el servidor cerrará la conexión después de un tiempo de inactividad.

Aquí, mantienes una actividad baja, simulando en realidad algún tipo de cliente muy lento que necesita mucho, mucho tiempo para completar su solicitud. Dado que todavía hay actividad, el servidor no puede alcanzar ningún tiempo de espera de inactividad y, como el cliente aún no ha finalizado su solicitud, el servidor no puede enviar ninguna respuesta todavía. Por lo tanto, el hilo del servidor está atascado esperando que este "cliente lento" complete su solicitud. Y si tiene suficientes solicitudes de este tipo en curso en paralelo, esperamos que bloquee cada subproceso disponible en este servidor con sus solicitudes de "clientes lentos", lo que provocará una denegación de servicio.

Según la información complementaria, los datos reales enviados al servidor para mantener una actividad baja no son tan importantes. La idea aquí es simplemente enviar un encabezado HTTP formalmente válido (: \ r \ n), el prefijo "X-" se agrega a los encabezados no estándar o propietarios, por lo que todavía parece que enviamos algunos datos de solicitud legítimos.