Comment se défendre au mieux contre une attaque DOS «slowloris» contre un serveur Web Apache?

32

Récemment, un script appelé "slowloris" a attiré l'attention. Le concept de base de ce que fait slowloris n'est pas une nouvelle attaque, mais compte tenu de l'attention récente, j'ai constaté une légère augmentation des attaques contre certains de nos sites Web Apache.

Pour le moment, il ne semble pas y avoir de défense à 100% contre cela.

La meilleure solution que nous avons déterminée (jusqu’à présent) est d’augmenter MaxClients.

Cela ne fait évidemment que renforcer les exigences de l'ordinateur de l'attaquant et ne protège pas réellement le serveur à 100%.

Un autre rapport indique que l’utilisation d’un proxy inverse (tel que Perlbal) devant le serveur Apache peut aider à prévenir l’attaque.

Utiliser mod_evasive pour limiter le nombre de connexions d'un hôte et utiliser mod_security pour refuser des demandes qui semblent avoir été émises par slowloris semble être la meilleure défense à ce jour.

Quelqu'un sur ServerFault a-t-il été victime d'attaques de ce type? Si oui, quelles mesures avez-vous mises en place pour la défendre / l’empêcher?

REMARQUE: cette question concerne les serveurs Apache, car je crois comprendre que les serveurs Windows IIS ne sont pas affectés.

apache-2.2 web-server denial-of-service

— KPWINC
source

22

J'ai vécu une telle attaque ... au milieu de l'été (23 juin), où vous êtes censé être à la campagne et boire de la bière:>

J'ai mis mon Apache derrière Varnish , qui non seulement était protégé contre slowloris, mais qui accélérait un peu les requêtes Web.

Aussi, iptablesm'a aidé:

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

Cette règle limite un hôte à 20 connexions sur le port 80, ce qui ne devrait pas affecter les utilisateurs non malveillants, mais rendrait slowloris inutilisable à partir d'un hôte.

— Kristaps
source

4

+1 pour la règle iptables.

— Tim le

1

Juste un heads-up. "Out of the Box", le vernis ne cache pas les pages s'il a reçu des cookies. Vous devez faire une configuration personnalisée pour résoudre ce problème. Des exemples sont disponibles sur leur site et sont faciles à mettre en œuvre.

— David

Le vernis est assez programmable, vous pouvez donc le configurer pour voir ce qui se passe et le gérer. Cependant, je pense qu’en plaçant un proxy devant apache, vous ne faites que déplacer le problème du serveur Web au proxy. Le problème est toujours là, mais dans un endroit différent. Les connexions / ports seront toujours utilisés. Je commencerais par la règle iptables listée (ou l’équivalent pour votre pare-feu), puis examinons un proxy.

— David

1

le problème de l'attaque sloworis est limité au modèle multi-threading d'apache (et à plusieurs autres serveurs Web qui utilisent un modèle similaire). Le vernis devrait survivre à cela.

— Cian

4

mod_antiloris , aussi simple que cela.

— LiraNuna
source

3

Si tous vos modules apache sont thread-safe, slowloris peut être neutralisé simplement en basculant sur un MPM événement ou ouvrier. ref: ici

— Cian
source

0

À l'heure actuelle, il semble qu'il n'y ait plus rien à faire qui limite le nombre maximal de connexions simultanées par adresse IP sur le serveur.

— Maxwell
source

0

Vous pouvez essayer un patch utilisateur. Il modifie le délai d'attente en fonction de la charge du serveur, mais compte tenu de son statut, il est possible que vous ne souhaitiez pas l'utiliser sur une machine de production, sans quelques tests sérieux. Jetez un coup d'oeil ici.

— Dentrasi
source

0

Le pare-feu basé sur iptable devrait vous protéger de plusieurs connexions à partir d’une adresse IP.

0

Si cela aide quelqu'un d'autre, vous pouvez parfois résoudre ce problème avec Apache 2.2.15 ou une version ultérieure avec la configuration suivante:

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

Plus d'informations ici: https://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html

— MrCarrot
source