Cómo proteger Tomcat 7 contra el ataque de Slowloris

Se ha asignado un CVE específicamente para este problema, ya que se aplica a Apache Tomcat: CVE-2012-5568 . Hay referencias más apropiadas que la que te dieron.

Los desarrolladores de Tomcat no consideran que esto sea una vulnerabilidad y no tienen planes para solucionarlo.

Soluciones potenciales:

• Use las reglas del firewall para evitar demasiadas conexiones desde un solo host. Esto mitigará los ataques de denegación de servicio de ejecución normal pero no los distribuidos (DDoS).

    

  Aquí hay un ejemplo de un comando de iptables que se puede usar para limitar el número   de conexiones simultáneas que se pueden establecer en el puerto 80 desde una sola   cliente host:

       

  # iptables -A INPUT -p tcp --syn --dport 80
-m connlimit --connlimit-above 50 -j REJECT

  enlace

  Sin embargo, esto tendría efectos secundarios si muchos usuarios se conectaran legítimamente desde una única IP (por ejemplo, un mega-proxy), por lo que la cantidad de conexiones debería ajustarse de manera razonable, dependiendo del tráfico esperado.

• Desafortunadamente, la mejor opción es colocar el servicio Tomcat en un servidor web que pueda manejar mejor las conexiones HTTP, como Apache. Luego use una solución Apache como mod_reqtimeout o mod_antiloris.

Hay un módulo de Apache que aplica algunas heurísticas para (tratar de) detectar el ataque "slowloris" y contrarrestarlo. Se llama mod_antiloris (este es un módulo para Apache, no un módulo de la Apache Software Foundation ). Consulte esta respuesta para obtener más información.

Recuerda que, como en todos los ataques de denegación de servicio , no hay solución , solo mitigaciones .

  

_{Tenga en cuenta que Tomcat es parte de Apache Foundation, por lo que técnicamente se llama Apache Tomcat. Sin embargo, el servidor web tradicional de Apache (oficialmente llamado "El Proyecto del Servidor HTTP de Apache") se refiere a menudo simplemente como Apache. A continuación, "Apache" se refiere al servidor HTTP Apache, y no Tomcat.}

Tomcat normalmente no se ejecuta como un servidor web, se ejecuta como un servidor de aplicaciones. Si Tomcat está expuesto directamente a Internet (sin asociarse con Apache), su solución debería ser una de las siguientes:

• Configura un servidor proxy inverso frente a Tomcat, como Nginx, Lighttpd o incluso Apache.

• Configure Apache y Tomcat juntos como configurado tradicionalmente .

Si usa Apache en su solución, entonces también necesitará usar una estrategia de mitigación de slowloris. Hay mod_antiloris, que lo hará por usted como se describe en el artículo que vinculó. Y también hay mod_reqtimeout , cuyo departamento que forma parte de Apache Core a menudo no está incluido por defecto en Apache instalaciones.

mod_antiloris funciona al limitar el número de conexiones simultáneas que puede crear un IP determinado.
mod_reqtimeout funciona al limitar la cantidad de tiempo que una sola solicitud puede permanecer inactiva.

Ambos tienen su lugar, y una buena defensa probablemente empleará ambos.

Además, la mpm_event la configuración de Apache worker funciona de la misma manera que otros servidores, como Nginx, Cherokee y lighttpd, y no es susceptible al ataque de Slowloris. Está disponible en la mayoría de las instalaciones modernas, pero está marcado como "experimental". En particular, puede que no sea compatible con algunos módulos más antiguos que se basan en el concepto de conexión por hilo. Un ejemplo que se cita con frecuencia es mod_php , aunque puede que no se aplique a las versiones más recientes.

¿tienes apache (el servidor web) delante de tu gato? si es así - > mejorar. apache no es vulnerable a slowloris desde 2.2.16 IIRC, y 2.2.16 se distribuye con debian squeeze, que es oldstable.

si no tiene un proxy inverso delante de su gato: use uno, preferiblemente barniz o nginx.

para conocer las razones para usar un proxy inverso, consulte esta respuesta @ serverfault

Aquí hay una solución. Esto no afectará a las personas que usan un proxy. El equipo de Apache Tomcat no considera esto como una vulnerabilidad en Tomcat ni planea lanzar un parche. Este código también detendrá otros métodos de ataque ddos. ps no escribí esto.

BLACKLIST = cat /usr/local/AS/etc/blacklist.txt

para i en $ BLACKLIST; hacer   iptables -A ENTRADA -p tcp -m tcp --dport http -s $ i -j DROP hecho

- # IPs que nunca serán rechazadas - hosts anfitriones

WHITELIST=**** INSERTE SU LISTA BLANCA PERMANENTE AQUÍ ** * ***

para i en $ WHITELIST; hacer   iptables -A ENTRADA -p tcp -m tcp --dport http -s $ i -j ACEPTAR hecho

- # no baje demasiado: los navegadores abren varias conexiones

OVERLIM_NEW = 500
- # límite global para nuevas conexiones por segundo
INDILIM_NEW = 30
- # límite para IP individual, nuevas conexiones por segundo - evita inundaciones
INDILIM_CURRENT = 200
- # límite para IP individual, conexiones totales - evita el uso excesivo
CURRENT_EVAL_INTERVAL = 300
- # longitud del intervalo para la evaluación del uso de IP

iptables -N LIMIT_INDIVIDUAL_NEW
iptables -N LIMIT_INDIVIDUAL_CURRENT
iptables -N LIMIT_OVERALL_NEW

iptables -A ENTRADA -p tcp --dport 80 -m estado --estado ESTABLECIDO -j LIMIT_INDIVIDUAL_CURRENT
iptables -A ENTRADA -p tcp --dport 80 --syn -m estado --estado NEW -j LIMIT_INDIVIDUAL_NEW

iptables -A LIMIT_INDIVIDUAL_CURRENT -m recent --set
iptables -A LIMIT_INDIVIDUAL_CURRENT -p tcp --tcp-flags FIN FIN -m reciente --remove
iptables -A LIMIT_INDIVIDUAL_CURRENT -m reciente --update --seconds $ CURRENT_EVAL_INTERVAL --hitcount $ INDILIM_CURRENT -j DROP
iptables -A LIMIT_INDIVIDUAL_CURRENT -j ACEPTAR

iptables -A LIMIT_INDIVIDUAL_NEW -m recent --set
iptables -A LIMIT_INDIVIDUAL_NEW -m reciente --update --seconds 1 --hitcount $ INDILIM_NEW -j DROP
iptables -A LIMIT_INDIVIDUAL_NEW -j LIMIT_OVERALL_NEW
iptables -A LIMIT_OVERALL_NEW -m limit --limit $ OVERLIM_NEW / second -j ACEPTAR
iptables -A LIMIT_OVERALL_NEW -j DROP