¿Por qué NginX y Lighttpd no se ven afectados por Slowloris?
23
Estoy investigando la vulnerabilidad a Slowloris y creo que entiendo cómo y por qué funciona este tipo de ataque.
Lo que no entiendo es por qué Lighttpd y NginX no se ven afectados (de acuerdo con el mismo artículo vinculado anteriormente). ¿Qué hacen tan diferente?
Esa es la cantidad de conexiones simultáneas que puede manejar. Es decir, si un servidor apache tiene un límite de 'clientes máximos' de 100, y cada solicitud tarda 1 segundo en completarse, puede manejar un máximo de 100 solicitudes por segundo.
Una aplicación como SlowLoris inundará un servidor con conexiones, en nuestro ejemplo, si SlowLoris envía 200 conexiones por segundo, y Apache solo puede manejar 100 conexiones por segundo, la cola de conexiones seguirá creciendo y usará toda la memoria en la máquina llevándola a una bóveda Esto es similar a la forma en que funciona LOIC de Anonymous.
NGINX y Lighttpd (entre otros) no tienen conexiones máximas, en su lugar usan hilos de trabajo, por lo que, en teoría, no hay límite para la cantidad de conexiones que pueden manejar.
Si supervisa sus conexiones de Apache, verá que la mayoría de las conexiones activas son datos de "Envío" o "Recepción" del cliente. En NGINX / Lighttpd simplemente ignoran estas solicitudes y les permiten ejecutarse en segundo plano, sin agotar los recursos del sistema, y solo tiene que procesar las conexiones con algo que está sucediendo (analizar respuestas, leer datos de servidores de fondo, etc.)
En realidad, respondí una pregunta similar esta tarde, por lo que la información allí también podría ser interesante para usted Reducir la cola de solicitudes de Apache
Corrección menor: nginx no utiliza subprocesos de trabajo para lograr un gran número de conexiones. De nginx.org : "Nginx no se basa en hilos para manejar solicitudes. En su lugar, utiliza una arquitectura mucho más escalable (asíncrona) basada en eventos"
Día
2
Aunque es un posible efecto secundario, la intención de Slowloris no es "usar toda la memoria en la máquina", sino más bien agotar la capacidad de conexión máxima que impide que las conexiones posteriores tengan éxito.
wulfgarpro
@Day Nginx usa hilos de trabajo para soportar su operación asincrónica. Aquí se proporciona un esquema de arquitectura de aplicación útil: aosabook.org/en/nginx.html#fig.nginx.arch
Terry Burton
13
Nginx es realmente vulnerable al ataque de slowloris. El recurso escaso es el número máximo de conexiones simultáneas de trabajadores. Este número se puede calcular como trabajador_conexiones * trabajador_procesos y equivale a 512 en la configuración predeterminada de nginx. Por lo tanto, es bastante fácil eliminar nginx sin protección con herramientas como goloris .
goloris¡Parece la herramienta que necesito para asegurarme de que mi implementación / configuración funcione como se espera!
Alexis Wilke
8
el comentario de valyala debe ser aceptado como la respuesta.
La mayoría de los servidores nginx usan configuraciones predeterminadas y, por lo tanto, son vulnerables al ataque de slowloris. He usado slowloris para eliminar algunos de los sitios web nginx de mis amigos usando solo mi computadora portátil y usualmente me tomó menos de 5 minutos (mis amigos me desafiaron a hacerlo).
Como dijo valyala, técnicamente, nginx no es vulnerable a slowloris, pero las configuraciones predeterminadas limitan el número máximo de conexiones, por lo que cuando las conexiones exceden ese número, nginx descarta la nueva solicitud, lo que resulta en una denegación de servicio.
Las formas conocidas de proteger nginx de slowloris incluyen limitar el número de conexiones desde la misma IP y aumentar la configuración de trabajo_conexiones. El ataque aún puede funcionar, pero se vuelve más difícil (¿tal vez tarda más de 5 minutos?: D)
Nginx es realmente vulnerable al ataque de slowloris. El recurso escaso es el número máximo de conexiones simultáneas de trabajadores. Este número se puede calcular como trabajador_conexiones * trabajador_procesos y equivale a 512 en la configuración predeterminada de nginx. Por lo tanto, es bastante fácil eliminar nginx sin protección con herramientas como goloris .
fuente
goloris¡Parece la herramienta que necesito para asegurarme de que mi implementación / configuración funcione como se espera!el comentario de valyala debe ser aceptado como la respuesta.
La mayoría de los servidores nginx usan configuraciones predeterminadas y, por lo tanto, son vulnerables al ataque de slowloris. He usado slowloris para eliminar algunos de los sitios web nginx de mis amigos usando solo mi computadora portátil y usualmente me tomó menos de 5 minutos (mis amigos me desafiaron a hacerlo).
Como dijo valyala, técnicamente, nginx no es vulnerable a slowloris, pero las configuraciones predeterminadas limitan el número máximo de conexiones, por lo que cuando las conexiones exceden ese número, nginx descarta la nueva solicitud, lo que resulta en una denegación de servicio.
Las formas conocidas de proteger nginx de slowloris incluyen limitar el número de conexiones desde la misma IP y aumentar la configuración de trabajo_conexiones. El ataque aún puede funcionar, pero se vuelve más difícil (¿tal vez tarda más de 5 minutos?: D)
fuente