Comment protéger Tomcat 7 contre l'attaque de Slowloris
J'utilise Apache Tomcat 7 pour exécuter ma webapp sur Linux. Je l'ai scanné par Acunetix et ça me dit que ma webapp est vulnérable à "Slow HTTP Denial of Service Attack". Comment puis-je le protéger?
Acunetix me demande de ici , mais il s'agit de sécuriser Apache, pas Tomcat.
Un CVE a été attribué spécifiquement pour ce problème car il s'applique à Apache Tomcat: CVE-2012-5568 . Des références plus appropriées que celle qui vous a été donnée.
Les développeurs de Tomcat ne considèrent pas cela comme une vulnérabilité , et n'ont aucun plan à corriger.
Solutions potentielles:
Utilisez des règles de pare-feu pour empêcher trop de connexions à partir d'un seul hôte. Cela permettra d'atténuer les attaques de déni de service courantes, mais pas les attaques distribuées (DDoS).
Voici un exemple de commande iptables qui peut être utilisée pour limiter le nombre de connexions simultanées pouvant être établies vers le port 80 à partir d'un seul hôte client:
# iptables -A INPUT -p tcp --syn --dport 80
-m connlimit --connlimit-above 50 -j REJECThttps://bugzilla.redhat.com/show_bug.cgi?id=CVE-2007-675
Cependant, cela aurait des effets secondaires si de nombreux utilisateurs se connectaient légitimement à partir d'une seule adresse IP (par exemple, un méga-proxy), de sorte que le nombre de connexions devrait être réglé de manière raisonnable - en fonction du trafic attendu.
Malheureusement, la meilleure option consiste à placer le service Tomcat en aval d'un serveur Web qui peut mieux gérer les connexions HTTP, comme Apache. Utilisez ensuite une solution Apache telle que mod_reqtimeout ou mod_antiloris.
Il existe un module Apache qui applique des heuristiques pour (essayer de) détecter l'attaque "slowloris" et la contrer. On l'appelle mod_antiloris (c'est un module pour Apache, pas un module de le Apache Software Foundation ). Voir cette réponse pour plus de détails.
N'oubliez pas que, comme pour toutes les attaques par déni de service , il n'y a pas de solution , seulement atténuations .
Notez que Tomcat fait partie de la Fondation Apache, donc techniquement cela s'appelle Apache Tomcat. Cependant, le serveur Web Apache traditionnel (officiellement appelé "The Apache HTTP Server Project") est souvent appelé simplement Apache. Ci-dessous, "Apache" fait référence au serveur HTTP Apache et pas Tomcat.
Tomcat ne fonctionne généralement pas en tant que serveur Web, il s'exécute en tant que serveur d'applications. Si Tomcat est directement exposé à Internet (sans être associé à Apache), votre solution doit être l'une des suivantes:
Configurez un serveur proxy inverse devant Tomcat, tel que Nginx, Lighttpd ou même Apache.
Configurez Apache et Tomcat ensemble comme traditionnellement configuré .
Si vous utilisez Apache dans votre solution, alors vous aurez aussi besoin d'utiliser une stratégie d'atténuation slowloris. Il y a mod_antiloris, qui fera cela pour vous comme décrit dans l'article que vous avez lié. Et il y a aussi mod_reqtimeout , quel dépôt faisant partie d'Apache Core n'est souvent pas inclus par défaut dans les installations Apache.
mod_antiloris fonctionne en limitant le nombre de connexions simultanées qu'une IP donnée peut créer.mod_reqtimeout fonctionne en limitant la durée pendant laquelle une seule demande peut rester inactive.
Les deux ont leur place, et une bonne défense emploiera probablement les deux.
De plus, la configuration mpm_event du travailleur Apache fonctionne de la même manière que les autres serveurs, tels que Nginx, Cherokee et lighttpd, et n'est pas sensible à l'attaque Slowloris. Ceci est disponible sur la plupart des installations modernes, mais est marqué "expérimental". En particulier, il peut ne pas être compatible avec certains modules plus anciens qui reposent sur le concept de thread par connexion. Un exemple souvent cité est mod_php, mais cela peut ne pas s'appliquer aux versions plus récentes.
avez-vous Apache (le serveur Web) devant votre tomcat? si c'est le cas -> mise à niveau. Apache n'est pas vulnérable à slowloris depuis 2.2.16 IIRC, et 2.2.16 est livré avec Debian Squeeze, qui est oldstable.
si vous n'avez pas de proxy inverse devant votre Tomcat: utilisez-en un, de préférence un vernis ou un nginx.
pour des raisons d'utiliser un proxy inverse, voir cette réponse @ serverfault
Voici une solution. Cela n'affectera pas les personnes utilisant un proxy. L'équipe Apache Tomcat ne considère pas cela comme une vulnérabilité dans Tomcat ou prévoit de publier un correctif. Ce code arrêtera également les autres méthodes d'attaque ddos. ps je n'ai pas écrit cela.
LISTE NOIRE = cat /usr/local/AS/etc/blacklist.txt
pour i dans $ BLACKLIST; faire iptables -A INPUT -p tcp -m tcp --dport http -s $ i -j DROP done
- # IPs qui ne seront jamais refusées - hôtes partenaires
LISTE BLANCHE = * *** INSÉREZ VOTRE LISTE BLANCHE PERMANENTE IPS ICI ** * ***
pour i dans $ WHITELIST; faire iptables -A INPUT -p tcp -m tcp --dport http -s $ i -j ACCEPT done
- # ne baisse pas trop - les navigateurs ouvrent plusieurs connexions
OVERLIM_NEW = 500
- # limite globale de nouvelles connexions par seconde
INDILIM_NEW = 30
- # limite pour IP individuelle, nouvelles connexions par seconde - empêche les inondations
INDILIM_CURRENT = 200
- # limite pour IP individuelle, nombre total de connexions - empêche la surutilisation
CURRENT_EVAL_INTERVAL = 300
- # longueur d'intervalle pour l'évaluation de l'utilisation IP
iptables -N LIMIT_INDIVIDUAL_NEW
iptables -N LIMIT_INDIVIDUAL_CURRENT
iptables -N LIMIT_OVERALL_NEW
iptables -A INPUT -p tcp --dport 80 -m state --state ESTABLISHED -j LIMIT_INDIVIDUAL_CURRENT
iptables -A INPUT -p tcp --dport 80 --syn -m state --state NEW -j LIMIT_INDIVIDUAL_NEW
iptables -A LIMIT_INDIVIDUAL_CURRENT -m récent --set
iptables -A LIMIT_INDIVIDUAL_CURRENT -p tcp --tcp-flags FIN FIN -m récent --remove
iptables -A LIMIT_INDIVIDUAL_CURRENT -m récent --update --secondes $ CURRENT_EVAL_INTERVAL --hitcount $ INDILIM_CURRENT -j DROP
iptables -A LIMIT_INDIVIDUAL_CURRENT -j ACCEPTER
iptables -A LIMIT_INDIVIDUAL_NEW -m récent --set
iptables -A LIMIT_INDIVIDUAL_NEW -m récent --update --secondes 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 ACCEPT
iptables -A LIMIT_OVERALL_NEW -j DROP