¿Qué tan lento HTTP puede derribar un servidor?

Los HTTP lentos son ataques de denegación de servicio (DoS) de la capa de aplicación y tienen el potencial de derribar un servidor con recursos limitados. Debido a la naturaleza del ataque (velocidad lenta y volumen bajo), son difíciles de detectar y pueden causar el mismo daño que un DDoS de gran volumen. En esta publicación, compartiré mi experiencia con estos ataques.

Introducción

Como se explica en WiKi , los ataques HTTP lentos se basan en el hecho de que el protocolo HTTP, por diseño, requiere que el servidor reciba completamente las requests antes de procesarlas. Si una solicitud HTTP no está completa, o si la tasa de transferencia es muy baja, el servidor mantiene sus recursos ocupados esperando el resto de los datos. Si el servidor mantiene demasiados recursos ocupados, esto crea una denegación de servicio. [Fuente :https://github.com/shekyan/slowhttptest/wiki ]

Los ataques HTTP lentos son principalmente de tres tipos.

1. Encabezados lentos (también conocido como Slowloris)
   Este ataque funciona abriendo una gran cantidad de conexiones con el servidor web y manteniéndolas vivas al ralentizar el envío de encabezados interminables. El servidor no cerrará las conexiones ya que la solicitud no está completa y eventualmente agotará todos los recursos en el servidor, bloqueando las requests legítimas.
2. Cuerpo lento (también conocido como RU-Dead-Yet)
   RU-Dead-Yet funciona como Slowloris, pero en lugar de enviar encabezados interminables, envía un cuerpo POST interminable, lo que obliga al servidor a mantener abiertas las conexiones. Cuando todos los recursos del servidor están ocupados, no puede atender las requests legítimas.
3. Lectura lenta
   Los ataques mencionados anteriormente explotan un servidor web mediante el envío de requests lentas; sin embargo, el exploit de lectura lenta se basa en leer las respuestas de un servidor muy lentamente. Funciona anunciando un tamaño de búfer de recepción de cliente muy bajo, desenstringndo una gran respuesta del servidor y tardando hasta minutos en leer una sola respuesta. Cuando se crean múltiples conexiones de este tipo al mismo tiempo, puede consumir todos los recursos del servidor y provocar DoS. No se puede explicar mejor que el propio autor de este ataque en esta publicación .

   Arquitectura de Nginx Nginx tiene un proceso maestro y varios procesos auxiliares (incluidos los procesos de trabajo). El proceso maestro administra todas las operaciones privilegiadas, mientras que los procesos de trabajo hacen el trabajo real y manejan las conexiones. La arquitectura de Nginx es fundamentalmente diferente de la de Apache. Apache genera un hilo de bloqueo para cada nueva conexión , mientras que Nginx se basa en una arquitectura basada en eventos sin bloqueo. El siguiente diagrama resume el flujo:
   
   

   

   Esta arquitectura proporciona prevención innata contra ataques HTTP lentos hasta cierto punto, ya que el proceso de trabajo no está bloqueado en IO. Puede seguir atendiendo otras requests. Sin embargo, no es una prueba completa y también depende de las opciones de configuración de Nginx.

   Algunas de las opciones de configuración comunes proporcionadas por Nginx para evitar este tipo de ataques son:

   1) limit_req: para limitar la tasa de requests de una IP
   2) limit_conn: para limitar la cantidad de conexiones de una IP
   3) client_body_timeout: para cerrar las conexiones con cuerpo lento
   4) client_header_timeout: para cerrar las conexiones con encabezados lentos
   5) send_timeout: si el cliente no recibe nada dentro de este tiempo, la conexión se cierra.

Conclusión
Los ataques HTTP lentos pueden ser tan maliciosos como los ataques DDoS volumétricos, si no se tratan adecuadamente. Además, hay muchas partes móviles en la configuración de Nginx y debemos comprenderlas correctamente antes de realizar cambios aleatorios de copiar/pegar.

También veo una solución más a este problema al rechazar tamaños de ventana de búfer de recepción del lado del cliente muy bajos, pero todavía tengo que explorar ese camino.

Referencias
1) SlowHTTPTest
2) ¿Estás listo para una lectura lenta?
3) Dentro de Nginx
4) Referencia de Nginx
5) Mitigación de Nginx DDOS

Este artículo es una contribución de Saket Kumar . Si le gusta GeeksforGeeks y le gustaría contribuir, también puede escribir un artículo usando contribuya.geeksforgeeks.org o envíe su artículo por correo a contribuya@geeksforgeeks.org. Vea su artículo que aparece en la página principal de GeeksforGeeks y ayude a otros Geeks.

Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.