¿Cómo defenderse mejor de un ataque DOS "slowloris" contra un servidor web Apache?

32

Recientemente un guión llamado "slowloris" ha llamado la atención. El concepto básico de lo que hace slowloris no es un nuevo ataque, pero dada la atención reciente, he visto un pequeño aumento en los ataques contra algunos de nuestros sitios web de Apache.

Por el momento no parece haber una defensa del 100% contra esto.

La mejor solución que hemos determinado (hasta ahora) es aumentar los MaxClients.

Por supuesto, esto no hace más que aumentar los requisitos para la computadora del atacante y en realidad no protege el servidor al 100%.

Otro informe indica que usar un proxy inverso (como Perlbal) frente al servidor Apache puede ayudar a prevenir el ataque.

El uso de mod_evasive para limitar el número de conexiones de un host y el uso de mod_security para negar las solicitudes que parecen haber sido emitidas por slowloris parecen ser la mejor defensa hasta ahora.

¿Alguien en ServerFault ha experimentado ataques como este? Si es así, ¿qué medidas implementó para defenderlo / prevenirlo?

NOTA: Esta pregunta es para servidores Apache ya que entiendo que los servidores Windows IIS no se ven afectados.

apache-2.2 web-server denial-of-service KPWINC
fuente

Respuestas:

22

Experimenté tal ataque ... en pleno verano (23 de junio), donde se supone que debes estar en el campo y beber cerveza:>

Puse mi Apache detrás de Varnish , que no solo protegió de slowloris, sino que también aceleró bastante las solicitudes web.

Además, iptablesme ayudó:

iptables -I INPUT -p tcp --dport 80 \
         -m connlimit --connlimit-above 20 --connlimit-mask 40 -j DROP

Esta regla limita un host a 20 conexiones al puerto 80, lo que no debería afectar a usuarios no maliciosos, pero haría que slowloris no se pueda utilizar desde un host.

Kristaps
fuente
44
+1 para la regla de iptables.
Tim
1
Solo un aviso. "Fuera de la caja", el barniz no almacena en caché las páginas si recibió cookies. Debe hacer una configuración personalizada para solucionar esto. Los ejemplos están disponibles en su sitio y son fáciles de implementar.
David
El barniz es bastante programable, por lo que puede configurarlo para ver qué está sucediendo y lidiar con él. Sin embargo, creo que al poner un proxy frente a apache, simplemente está moviendo el problema del servidor web al proxy. El problema sigue ahí, solo en un lugar diferente. Las conexiones / puertos aún se utilizarán. Comenzaría con la regla de iptables enumerada (o el equivalente para su firewall) y luego miraría un proxy.
David
1
El problema con el ataque sloworis se limita al modelo de subprocesamiento múltiple de Apache (y varios otros servidores web que usan un modelo similar). El barniz debería sobrevivir a eso.
Cian el
3

Si todos sus módulos de apache son seguros para subprocesos, slowloris puede ser derrotado simplemente cambiando a MPM de evento o de trabajo. ref: aquí

Cian
fuente
0

En este momento parece que no hay nada más que hacer que limitar las conexiones simultáneas máximas por ip en el servidor.

Maxwell
fuente
0

Hay un parche de usuario que puedes probar. Modifica el tiempo de espera en función de la carga bajo la que se encuentra el servidor, pero teniendo en cuenta su estado, es posible que no desee usarlo en una máquina de producción, sin algunas pruebas serias. Echa un vistazo aquí.

Dentrasi
fuente
0

El firewall basado en iptable debería protegerlo de múltiples conexiones desde 1 ip.


fuente
0

Si esto ayuda a alguien más, a veces puede superar este problema con Apache 2.2.15 o superior con la siguiente configuración:

LoadModule reqtimeout_module modules/mod_reqtimeout.so
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

Más información aquí: https://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html

MrCarrot
fuente