Protégez-vous contre les attaques Dos

Question

Cela pourrait être quelque chose de plus adapté à Serverfault, mais de nombreux développeurs Web qui viennent uniquement ici bénéficieront probablement des réponses possibles à cette question.

La question qui se pose est la suivante: comment vous protéger efficacement contre les attaques par déni de service contre votre serveur Web?

Je me suis posé la question après avoir lu cet article

.

Pour ceux qui ne sont pas familiers, voici ce dont je me souviens: une attaque par déni de service tentera d'occuper toutes vos connexions en envoyant à plusieurs reprises de faux en-têtes à vos serveurs.

Ce faisant, votre serveur atteindra la limite des connexions simultanées possibles et, par conséquent, les utilisateurs normaux ne pourront plus accéder à votre site.

Wikipedia fournit des informations supplémentaires: http://en.wikipedia.org/wiki/Denial_of_service" rel="noreferrer"> http://en.wikipedia.org/wiki/Denial_of_service"/a >

Answer 1

Il n'y a pas de panacée, mais vous pouvez rendre les attaques de déni de service plus difficiles en effectuant les opérations suivantes:

• Ne faites pas (ou ne limitez pas votre volonté de) faire des opérations coûteuses pour le compte de clients non authentifiés
• Tentatives d'authentification de la manette
• Limitez les opérations effectuées au nom de chaque client authentifié et verrouillez temporairement son compte s'il fait trop de choses en trop peu de temps
• Disposez d'une limitation globale similaire pour tous les clients non authentifiés et soyez prêt à réduire ce paramètre si vous détectez une attaque en cours
• Avoir un drapeau que vous pouvez utiliser lors d'une attaque pour désactiver tous les accès non authentifiés
• Ne stockez pas d'objets au nom de clients non authentifiés et utilisez un quota pour limiter le stockage de chaque client authentifié
• En général, rejetez toutes les demandes mal formées, déraisonnablement compliquées ou déraisonnablement énormes aussi rapidement que possible (et enregistrez-les pour vous aider à détecter une attaque)
• N'utilisez pas un cache LRU pur si les demandes de clients non authentifiés peuvent entraîner l'éviction d'éléments de ce cache, car vous serez soumis à des attaques par empoisonnement du cache (lorsqu'un client malveillant demande de nombreux éléments différents rarement utilisés, expulser toutes les choses utiles de votre cache et avoir besoin de faire beaucoup plus de travail pour servir vos clients légitimes)

N'oubliez pas qu'il est important de rejeter directement les demandes limitées (par exemple, avec un HTTP 503: service indisponible ou une réponse similaire, quel que soit le protocole que vous utilisez) plutôt que de mettre en file d'attente les demandes limitées. Si vous les mettez en file d'attente, la file d'attente absorbera toute votre mémoire et l'attaque DoS sera au moins aussi efficace qu'elle l'aurait été sans la limitation.

Quelques conseils plus spécifiques pour les serveurs HTTP:

• Assurez-vous que votre serveur Web est configuré pour rejeter les messages POST sans en-tête Content-Length , et pour rejeter les demandes (et limiter le client incriminé) dépassant la Content-Length , et de rejeter les demandes avec un Content-Length excessivement long pour le service que POST (ou PUT ) est destiné à

Answer 2

Pour cette attaque spécifique (tant que la requête est GET), un équilibreur de charge ou un WAF basé uniquement sur des requêtes complètes sur le serveur Web fonctionnerait.

Les problèmes commencent lorsque vous utilisez plutôt GET POST (ce qui est facile), car vous ne pouvez pas savoir s’il s’agit d’un POST malveillant ou si le téléchargement est très lent depuis un utilisateur.

En fait, vous ne pouvez pas vraiment protéger votre application Web à cause d’un simple fait. Vos ressources sont limitées alors que l'attaquant dispose potentiellement d'un temps et de ressources illimités pour effectuer le DoS. Et la plupart du temps, l'attaquant exécute les étapes requises à moindre coût. par exemple. cette attaque mentionnée ci-dessus quelques 100 connexions lentes - > pas de problème

Answer 3

Les serveurs asynchrones, par exemple, sont plus ou moins immunisés contre cette forme d’attaque particulière. Par exemple, je sers mes applications Django en utilisant un proxy inverse Nginx, et l'attaque n'a apparemment pas affecté son fonctionnement. Lighttpd est un autre serveur asynchrone populaire.

Attention, cette attaque est dangereuse car elle peut être effectuée même par une seule machine avec une connexion lente. Toutefois, les attaques DDoS courantes opposent votre serveur à une multitude de machines et vous ne pouvez rien faire pour vous en protéger.

Answer 4

Réponse courte:

Vous ne pouvez pas vous protéger contre les dénis de service.

Et je ne suis pas d'accord sur le fait qu'il appartient à serverfault car le DoS est classé comme un problème de sécurité et est définitivement lié à la programmation