Pourquoi NginX et Lighttpd ne sont-ils pas affectés par Slowloris?
23
J'étudie la vulnérabilité de Slowloris et je pense comprendre comment et pourquoi ce type d'attaque fonctionne.
Ce que je ne comprends pas, c'est pourquoi Lighttpd et NginX ne sont pas affectés (selon le même article comme lié ci-dessus). Qu'est-ce qui les rend si différents?
C'est le nombre de connexions simultanées qu'il peut gérer. IE si un serveur apache a une limite de «max clients» de 100 et que chaque requête prend 1 seconde, il peut gérer un maximum de 100 requêtes par seconde.
Une application comme SlowLoris inondera un serveur de connexions, dans notre exemple si SlowLoris envoie 200 connexions par seconde, et Apache ne peut gérer que 100 connexions par seconde, la file d'attente de connexion ne cessera de s'agrandir et d'utiliser toute la mémoire de la machine pour l'amener à un hault. Ceci est similaire à la façon dont LOIC anonyme fonctionne.
NGINX et Lighttpd (entre autres) n'ont pas de connexions maximales, ils utilisent à la place des threads de travail, donc, théoriquement, il n'y a pas de limite au nombre de connexions qu'ils peuvent gérer.
Si vous surveillez vos connexions Apache, vous verrez que la majorité des connexions actives sont «Envoi» ou «Réception» de données du client. Dans NGINX / Lighttpd, ils ignorent simplement ces demandes et les laissent s'exécuter en arrière-plan, sans utiliser de ressources système, et il n'a qu'à traiter les connexions avec quelque chose qui se passe (analyser les réponses, lire les données des serveurs principaux, etc.)
En fait, j'ai répondu à une question similaire cet après-midi, donc les informations qu'il contient pourraient également vous intéresser Réduire la file d'attente des demandes Apache
Correction mineure: nginx n'utilise pas de threads de travail pour atteindre un nombre élevé de connexions. De nginx.org : "Nginx ne s'appuie pas sur les threads pour gérer les requêtes. Au lieu de cela, il utilise une architecture événementielle (asynchrone) beaucoup plus évolutive"
Jour
2
Bien qu'il s'agisse d'un effet secondaire possible, l'intention de Slowloris n'est pas «d'utiliser toute la mémoire de la machine», mais plutôt d'épuiser la capacité de connexion maximale en refusant aux connexions suivantes de réussir.
wulfgarpro
@Day Nginx utilise des threads de travail pour prendre en charge son fonctionnement asynchrone. Un schéma d'architecture d'application utile est fourni ici: aosabook.org/en/nginx.html#fig.nginx.arch
Terry Burton
13
Nginx est en fait vulnérable aux attaques de slowloris. La ressource rare est le nombre maximal de connexions de travail simultanées. Ce nombre peut être calculé en tant que worker_connections * worker_processes et est égal à 512 dans la configuration par défaut de nginx. Ainsi, il est assez facile de supprimer nginx non protégé avec des outils tels que goloris .
golorisressemble à l'outil dont j'ai besoin pour m'assurer que mon implémentation / configuration fonctionne comme prévu!
Alexis Wilke
8
Le commentaire de valyala doit être accepté comme réponse.
La plupart des serveurs nginx utilisent des configurations par défaut et sont donc vulnérables aux attaques de slowloris. J'ai utilisé slowloris pour supprimer certains des sites Web nginx de mon ami en utilisant uniquement mon ordinateur portable et cela prenait généralement moins de 5 minutes (mes amis m'ont mis au défi de le faire).
Comme l'a indiqué valyala, techniquement, nginx n'est pas vulnérable à slowloris, mais les configurations par défaut limitent le nombre maximum de connexions, donc lorsque les connexions dépassent ce nombre, nginx abandonne la nouvelle demande, ce qui entraîne un déni de service.
Les moyens connus pour protéger nginx de slowloris incluent la limitation du nombre de connexions à partir de la même IP et l'augmentation de la configuration de worker_connections. L'attaque peut toujours fonctionner, mais elle devient plus difficile (peut-être plus de 5 minutes?: D)
Nginx est en fait vulnérable aux attaques de slowloris. La ressource rare est le nombre maximal de connexions de travail simultanées. Ce nombre peut être calculé en tant que worker_connections * worker_processes et est égal à 512 dans la configuration par défaut de nginx. Ainsi, il est assez facile de supprimer nginx non protégé avec des outils tels que goloris .
la source
golorisressemble à l'outil dont j'ai besoin pour m'assurer que mon implémentation / configuration fonctionne comme prévu!Le commentaire de valyala doit être accepté comme réponse.
La plupart des serveurs nginx utilisent des configurations par défaut et sont donc vulnérables aux attaques de slowloris. J'ai utilisé slowloris pour supprimer certains des sites Web nginx de mon ami en utilisant uniquement mon ordinateur portable et cela prenait généralement moins de 5 minutes (mes amis m'ont mis au défi de le faire).
Comme l'a indiqué valyala, techniquement, nginx n'est pas vulnérable à slowloris, mais les configurations par défaut limitent le nombre maximum de connexions, donc lorsque les connexions dépassent ce nombre, nginx abandonne la nouvelle demande, ce qui entraîne un déni de service.
Les moyens connus pour protéger nginx de slowloris incluent la limitation du nombre de connexions à partir de la même IP et l'augmentation de la configuration de worker_connections. L'attaque peut toujours fonctionner, mais elle devient plus difficile (peut-être plus de 5 minutes?: D)
la source