Les meilleures pratiques pour détecter les attaques par déni de service (DOS)? [fermé]

Question

Je recherche les meilleures pratiques pour détecter et prévenir le DOS dans la mise en œuvre du service (pas pour la surveillance du réseau externe). Le service traite les requêtes d'informations sur les utilisateurs, les groupes et les attributs.

Quelle est votre source d’information préférée pour traiter avec DOS?

Answer 1

C’est une technique que j’ai trouvée très utile ..

Prévenez les attaques par déni de service (DOS) dans votre application Web

Answer 2

Quoi que vous fassiez contre les attaques DoS, pensez si ce que vous faites peut réellement augmenter la charge requise pour traiter les requêtes malveillantes ou indésirables!

Si vous utilisez Linux, vous devriez lire cet article:
Script de shell de prévention des attaques DoS basées sur des règles (extrait de la Gazette Linux) Il contient les sujets suivants:

• Comment détecter les attaques par déni de service / var / log / fichier sécurisé
• Comment réduire les adresses IP détectées redondantes à partir du fichier temporaire
• Comment activer / sbin / iptables
• Comment installer le script shell proposé

Appliquer cela sans limiter correctement le nombre d'adresses IP bloquées dans iptables peut introduire une vulnérabilité du DoS en augmentant les ressources requises pour traiter les demandes non sollicitées. Pour réduire ce risque, utilisez ipset pour faire correspondre les adresses IP dans iptables.

Consultez également la prévention des attaques par le dictionnaire ssh à l'aide d'iptables . (Activer iptables avec un pare-feu avec état, comme suggéré ici, ne protège pas contre la plupart des attaques DoS, mais peut en réalité faciliter les attaques DoS qui polluent votre RAM avec des informations d'état inutiles.)

Nouveau sur Linux? lisez la feuille de route de Windows vers Linux: Partie 5. Journalisation sous Linux d'IBM.

Bonne chance!

Answer 3

Ma première tentative de résolution de la vulnérabilité de déni de service a utilisé l'approche proposée par Gulzar, qui consiste essentiellement à limiter le nombre d'appels autorisés à partir de la même adresse IP. Je pense que c'est une bonne approche, mais malheureusement, mon code a échoué lors d'un test de performance.

N'ayant pas réussi à faire modifier le test du groupe de test de performance (problème politique et non technique), j'ai décidé de limiter le nombre d'appels autorisés pendant un intervalle configurable. J'ai établi le nombre maximal d'appels et l'intervalle de temps configurable. J'ai également permis de définir une valeur de 0 ou un nombre négatif qui désactive les limites.

Le code devant être protégé est utilisé en interne par plusieurs produits. J'ai donc demandé à chaque groupe de produits d'exécuter leurs suites de tests d'assurance qualité et de performances et de proposer des valeurs par défaut aussi réduites que possible pour limiter les attaques par déni de service, tout en satisfaisant tous les tests.

FWIW, l’intervalle de temps était de 30 secondes et le nombre maximal d’appels était de 100. Cette approche n’est pas totalement satisfaisante, mais elle est simple et pratique et a été approuvée par l’équipe de sécurité de l’entreprise (autre considération politique).