web-dev-qa-db-fra.com

Comment activer la protection DDoS?

Les attaques DDoS (attaques par déni de service distribué) sont généralement bloquées au niveau du serveur, non?

Existe-t-il un moyen de le bloquer sur un niveau PHP, ou du moins de le réduire?

Sinon, quel est le moyen le plus rapide et le plus courant d’arrêter les attaques DDoS?

phpsecurityddosdenial-of-service
79
coderama

DDOS est une famille d'attaques qui submerge les systèmes clés du centre de données, notamment:

  • La connexion réseau du centre d'hébergement à Internet
  • Le réseau interne et les routeurs du centre d'hébergement
  • Votre pare-feu et vos équilibreurs de charge
  • Vos serveurs Web, serveurs d'applications et base de données.

Avant de commencer à construire votre défense DDOS, réfléchissez à la valeur en risque la plus défavorable. Pour un service gratuit non critique et gratuit pour une petite communauté, la valeur totale à risque peut être constituée d’arachides. Pour un système payant, faisant face au public et critique pour une entreprise établie pesant plusieurs milliards de dollars, la valeur peut être la valeur de la société. Dans ce dernier cas, vous ne devriez pas utiliser StackExchange :) Quoi qu'il en soit, pour vous défendre contre DDOS, vous avez besoin d'une approche approfondie de la défense:

  1. Travaillez avec votre centre d’hébergement pour comprendre les services qu’ils offrent, y compris le filtrage des adresses IP et des ports au niveau de leurs connexions réseau à Internet et des services de pare-feu proposés. Ceci est essentiel: de nombreux sites sont extraits d'Internet par la société d'hébergement , car celle-ci gère la perturbation généralisée du centre de données causée par le DDOS à un client. De plus, lors d'une attaque DDOS, vous travaillerez en étroite collaboration avec le personnel du centre d'hébergement. Vous devez donc connaître leurs numéros d'urgence et être en bons termes avec eux :) Ils devraient pouvoir bloquer des régions internationales entières, bloquer complètement des services spécifiques ou un réseau. protocoles et autres mesures de défense à large spectre, ou n'autorisez que les adresses IP inscrites sur la liste blanche (en fonction de votre modèle d'entreprise)
  2. Pendant que vous vous trouvez sur le centre d’hébergement, utilisez un réseau de distribution de conten pour distribuer des services (principalement statiques) à proximité de vos utilisateurs finaux et vous cacher. vos vrais serveurs des architectes DDOS. Le CDN complet est trop volumineux pour qu'un DDOS supprime tous les nœuds de tous les pays. Si le DDOS est concentré sur un pays, au moins les autres utilisateurs sont toujours OK.

  3. Gardez tous vos systèmes et packages logiciels mis à jour avec les derniers correctifs de sécurité - et je veux dire tous:

    • Commutateurs gérés - oui, il faut parfois les mettre à jour
    • Routeurs
    • Pare-feu
    • Équilibreurs de charge
    • Systèmes d'exploitation
    • Serveurs web
    • Les langues et leurs bibliothèques

  4. Assurez-vous de disposer d’un bon pare-feu ou d’une bonne appliance de sécurité configurés et régulièrement examinés par un expert en sécurité qualifié . . Des règles strictes sur le pare-feu constituent une bonne défense contre de nombreuses attaques simples. Il est également utile de pouvoir gérer la bande passante disponible pour chaque service ouvert.

  5. Avoir de bons outils de surveillance du résea en place - cela peut vous aider à comprendre:

    • Que vous êtes attaqué plutôt que d'être simplement sous une charge lourde
    • L’origine de l’attaque (pouvant inclure des pays avec lesquels vous ne faites normalement pas affaire) et
    • En réalité, quelle est l'attaque (ports, services, protocoles, IP et contenu du paquet)

  6. L’attaque peut simplement consister en un usage intensif de services de sites Web légitimes (par exemple, frapper des adresses URI "légales" exécutant des requêtes ou insérer/mettre à jour/supprimer des données) - des milliers ou des millions de demandes provenant de dizaines à des millions d’adresses IP différentes les genoux. Par ailleurs, certains services peuvent être si coûteux à exécuter que seules quelques requêtes donnent lieu à un DOS - pensez à un rapport très coûteux. Vous avez donc besoin d'une bonne surveillance au niveau de l'application de ce qui se passe:

    • Quels services ont été appelés et quels arguments/données sont envoyés (c'est-à-dire, enregistrez-vous dans votre application)
    • Quels utilisateurs invoquent et à partir de quelles adresses IP (c'est-à-dire en vous connectant dans votre application)
    • Quelles sont les requêtes et les insertions/mises à jour/suppressions effectuées par la base de données
    • Charge moyenne, utilisation de l'UC, entrée/sortie disque, trafic réseau sur tous les ordinateurs (et les VM) de votre système
    • Assurez-vous que toutes ces informations sont facilement récupérables et que vous pouvez corréler les journaux de différents ordinateurs et services (c.-à-d. Vous assurer que tous les ordinateurs sont synchronisés dans le temps à l’aide de ntp).

  7. Contraintes et limites sensibles dans votre application . Par exemple, vous pourriez:

    • Utilisez une fonctionnalité QoS dans l'équilibreur de charge pour envoyer toutes les sessions anonymes à des serveurs d'applications distincts de votre cluster, tandis que les utilisateurs connectés utilisent un autre ensemble. Cela empêche un DDOS anonyme au niveau de l'application de prendre de précieux clients
    • Utiliser une CAPCHA forte pour protéger les services anonymes
    • Expiration de session
    • Fixez une limite de session ou de débit sur certains types de demandes, tels que les rapports. Assurez-vous de pouvoir désactiver l'accès anonyme si nécessaire
    • Assurez-vous qu'un utilisateur a une limite au nombre de sessions simultanées (pour éviter qu'un compte piraté se connecte un million de fois)
    • Utiliser différents utilisateurs d'applications de base de données pour différents services (par exemple, utilisation transactionnelle ou utilisation de rapports) et utiliser la gestion des ressources de base de données pour empêcher un type de demande Web de submerger tous les autres
    • Si possible, rendez ces contraintes dynamiques, ou au moins configurables. Ainsi, pendant que vous êtes attaqué, vous pouvez définir des limites temporaires agressives ("limiter" l'attaque), telles qu'une seule session par utilisateur et aucun accès anonyme. Ce n'est certainement pas génial pour vos clients, mais bien mieux que de ne pas avoir de service du tout.

  8. Enfin, écrivez un plan de réponse DOS et faites-le réviser en interne par toutes les parties concernées: entreprises, gestion, équipe de développement SW, le Équipe informatique et expert en sécurité. Le processus de rédaction du document vous obligera, ainsi que votre équipe, à réfléchir aux problèmes et vous aidera à vous préparer si le pire devait arriver à 3 heures du matin, le jour de votre congé. Le document devrait couvrir (entre autres):

    • Quels sont les risques et le coût pour l'entreprise
    • Mesures prises pour protéger les actifs
    • Comment une attaque est détectée
    • La procédure de réponse et d'escalade planifiée
    • Processus pour maintenir le système et ce document à jour

Donc, à part le préambule, voici quelques réponses spécifiques:

Les DDOS sont généralement bloqués au niveau du serveur, non?

Pas vraiment - la plupart des pires attaques DDOS sont de faible niveau (au niveau des paquets IP) et sont gérées par des règles de routage, des pare-feu et des dispositifs de sécurité développés pour gérer les attaques DDOS.

Existe-t-il un moyen de le bloquer sur un niveau PHP, ou du moins de le réduire?

Certaines attaques DDOS visent l’application elle-même, en envoyant des requêtes URI et HTTP valides. Lorsque le nombre de demandes augmente, votre ou vos serveurs commencent à éprouver des difficultés et vous subissez une panne SLA. Dans ce cas, vous pouvez effectuer certaines tâches à la PHP niveau:

  • Surveillance au niveau de l'application: assurez-vous que chaque service/page enregistre les demandes de manière à pouvoir voir ce qui se passe (vous pouvez ainsi prendre des mesures pour atténuer l'attaque). Quelques idées:

    • Ayez un format de journal que vous pouvez facilement charger dans un outil de journalisation (ou Excel ou similaire) et analyser avec des outils de ligne de commande (grep, sed, awk). Rappelez-vous qu'un DDOS générera des millions de lignes de journal. Vous devrez probablement découper vos journaux (notamment en ce qui concerne l'URI, l'heure, l'adresse IP et l'utilisateur) pour déterminer ce qui se passe et générer des données telles que:

      • Quels sont les URI accessibles
      • Quels sont les URI qui échouent à un taux élevé (indicateur probable des URI spécifiques que les attaquants attaquent)
      • Quels utilisateurs accèdent au service
      • De combien d'adresses IP chaque utilisateur accède-t-il au service?
      • À quels URI les utilisateurs anonymes accèdent-ils?
      • Quels arguments sont utilisés pour un service donné
      • Auditer les actions d'un utilisateur spécifique

    • Enregistrez l'adresse IP de chaque demande. N'INVERSEZ PAS cela à DNS - ironiquement, le coût de cette opération facilite la DDOS pour les attaquants

    • Consignez l’URI complète et la méthode HTTP, par exemple, "GET http://example.com/path/to/service?arg1=ddos "
    • Enregistrez l'ID utilisateur s'il est présent
    • Journalise les arguments HTTP importants

  • Limites de débit raisonnables: vous pouvez définir des limites quant au nombre de demandes qu'une adresse IP ou un utilisateur donné peut effectuer au cours d'une période donnée. Un client légitime peut-il faire plus de 10 demandes par seconde? Les utilisateurs anonymes peuvent-ils accéder à des rapports coûteux?

  • CAPTCHA pour l'accès anonyme: implémentez une procédure CAPTCHA pour toutes les demandes anonymes afin de vérifier que l'utilisateur est une personne et non un bot DDOS.

Quel est le moyen le plus rapide et le plus courant d’arrêter les attaques DDOS?

Le plus rapide est probablement de céder au chantage, bien que cela ne soit pas souhaitable.

Sinon, la première chose à faire est de contacter votre fournisseur d'hébergement et/ou CDN et de travailler avec lui (s'il ne vous a pas déjà contacté pour savoir ce qui se passe ...). Lorsqu'une DDOS se produit, elle affectera probablement de manière collatérale d'autres clients du fournisseur d'hébergement et le fournisseur peut être soumis à une pression considérable pour fermer votre site simplement pour protéger ses ressources. Préparez-vous à partager vos journaux (toute information) avec le fournisseur; Ces journaux, combinés à leurs moniteurs de réseau, peuvent ensemble fournir suffisamment d’informations pour bloquer/atténuer l’attaque.

Si vous attendez un DDOS, il est très judicieux de qualifier votre fournisseur d’hébergement en fonction du niveau de protection qu’il peut fournir. Ils doivent avoir une expérience DDOS et des outils pour l’atténuer - comprendre leurs outils, leurs processus et leurs procédures d’escalade. Demandez également quel support le fournisseur d’hébergement a de leurs fournisseurs en amont. Ces services peuvent signifier des coûts initiaux ou mensuels plus élevés, mais considérez cela comme une police d'assurance.

Pendant que vous êtes attaqué, vous devrez saisir vos journaux et les exploiter - essayez de déterminer le schéma de l'attaque. Vous devez envisager de désactiver l’accès anonyme et de limiter les services attaqués (c’est-à-dire réduire la limite de débit de l’application pour le service).

Si vous avez de la chance et que vous avez une petite base de clients fixe, vous pourrez peut-être déterminer les adresses IP valides de vos clients. Si tel est le cas, vous pouvez passer à une approche de liste blanche pendant un court instant. Assurez-vous que tous vos clients savent ce qui se passe afin qu'ils puissent appeler s'ils ont besoin d'accéder à une nouvelle adresse IP :)

Doug McClean a quelques bons conseils à: https://stackoverflow.com/a/1029613/1395668

187
Andrew Alcock

Selon la PHP) partie de la question;

Bien que je ne me fie pas à PHP pour cela, cela pourrait être implémenté mais il faut considérer toutes ces possibilités ou plus;

  1. L'attaquant peut changer d'IP pour chaque requête
  2. L'attaquant peut transmettre à l'URI le ou les paramètres dont le site cible ne s'occupe pas.
  3. L'attaquant peut redémarrer la session avant l'expiration ...

Pseudo simple;

<?php
// Assuming session is already started
$uri = md5($_SERVER['REQUEST_URI']);
$exp = 3; // 3 seconds
$hash = $uri .'|'. time();
if (!isset($_SESSION['ddos'])) {
    $_SESSION['ddos'] = $hash;
}

list($_uri, $_exp) = explode('|', $_SESSION['ddos']);
if ($_uri == $uri && time() - $_exp < $exp) {
    header('HTTP/1.1 503 Service Unavailable');
    // die('Easy!');
    die;
}

// Save last request
$_SESSION['ddos'] = $hash;
?>
19
K-Gun

Le niveau php est trop tard dans la chaîne de demandes.

Mettre votre serveur Apache derrière une appliance open source peut être une bonne option pour vous.

http://tengine.taobao.org/ possède de la documentation et du code source ainsi que plusieurs modules destinés à la prévention des DDOS. C'est une extension de nginx, vous pouvez donc le configurer facilement en tant que proxy inverse pour votre instance Apache.

Voir: http://blog.zhuzhaoyuan.com/2012/01/a-mechanism-to-help-write-web-application-firewalls-for-nginx/ pour savoir comment lutter contre les collisions avec DoS attaques.

Totalement oublié aussi, http://www.cloudflare.com est l’un des meilleurs pare-feu pour applications Web gratuites, ils ont des forfaits gratuits et payants et vous épargnerons le cul de DDOS que nous utilisons pour beaucoup de nos sites de trafic juste pour ses capacités de mise en cache. C'est génial!

8
j_mcnally

Les applications DDoS sont mieux gérées par des appareils réseau très coûteux et spécialement conçus à cet effet. Les hôtes ne sont généralement pas doués pour la protection contre les attaques DDoS car ils sont soumis à des performances relativement faibles, à l'épuisement de l'état, à une bande passante limitée, etc. L'utilisation d'iptables, de mods Apache et de services similaires peut vous aider dans certaines situations si vous n'avez pas accès au matériel d'atténuation des attaques DDoS. ou un service d'atténuation des attaques DDoS, mais il est loin d'être idéal et vous expose toujours au risque d'une attaque.

5
ryan

Que diriez-vous de quelque chose comme ceci du côté PHP:

//if user does not change IP, then ban the IP when more than 10 requests per second are detected in 1 second
$limitps = 10;
if (!isset($_SESSION['first_request'])){
    $_SESSION['requests'] = 0;
    $_SESSION['first_request'] = $_SERVER['REQUEST_TIME'];
}
$_SESSION['requests']++;
if ($_SESSION['requests']>=10 && strtotime($_SERVER['REQUEST_TIME'])-strtotime($_SESSION['first_request'])<=1){
    //write the IP to a banned_ips.log file and configure your server to retrieve the banned ips from there - now you will be handling this IP outside of PHP
    $_SESSION['banip']==1;
}elseif(strtotime($_SERVER['REQUEST_TIME'])-strtotime($_SESSION['first_request']) > 2){
    $_SESSION['requests'] = 0;
    $_SESSION['first_request'] = $_SERVER['REQUEST_TIME'];
}

if ($_SESSION['banip']==1) {
    header('HTTP/1.1 503 Service Unavailable');
    die;
}
5
NVG

Vous ne pouvez pas faire cela au niveau PHP. DDOS est une sorte d’attaque qui envoie trop de requêtes à votre serveur Web. Votre serveur Web rejettera la demande avant d'appeler votre script PHP.

Si vous utilisez Apache, voici quelques conseils d’Apache: http://httpd.Apache.org/docs/trunk/misc/security_tips.html

4
ndlinh

Il existe des plugins que vous pouvez utiliser dans Apache pour ddos ​​/ dos. Bon début ici http://www.debianadmin.com/how-to-protect-Apache-against-dosddos-or-brute-force-attacks.html

Si vous êtes sur LEMP, vous pouvez vérifier ici. http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

Ce sont de bons points de départ peu coûteux.

3
JasonG

Les DDOS sont généralement bloqués au niveau du serveur. Veuillez activer la protection DDOS dans votre niveau de serveur. S'il vous plaît vérifier les notes ci-dessous pour les protections DDOS.

Les paramètres de configuration du serveur HTTP Apache qui peuvent aider à prévenir les problèmes de DDOS:

La directive RequestReadTimeout permet de limiter le temps qu’un client peut prendre pour envoyer la demande.

Attendez 10 secondes pour recevoir la demande, y compris les en-têtes et 30 secondes pour recevoir le corps de la demande:

RequestReadTimeout header=10 body=30

Attendez au moins 10 secondes pour recevoir le corps de la demande. Si le client envoie des données, augmentez le délai d'attente de 1 seconde pour chaque tranche de 1 000 octets reçus, sans limite supérieure pour le délai d'attente (à l'exception de la limite indiquée indirectement par LimitRequestBody):

RequestReadTimeout body=10,MinRate=1000

RequestReadTimeout header=10-30,MinRate=500
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

La directive KeepAliveTimeout peut également être réduite sur les sites soumis à des attaques par déni de service. Certains sites désactivent même complètement la maintenance via KeepAlive, ce qui présente bien entendu d'autres inconvénients en termes de performances. Les valeurs des différentes directives relatives au délai d'attente fournies par d'autres modules doivent être vérifiées.

Les directives LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine et LimitXMLRequestBody doivent être soigneusement configurées pour limiter la consommation de ressources déclenchée par l'entrée du client. Réglez la directive MaxRequestWorkers pour permettre au serveur de gérer le nombre maximal de connexions simultanées sans manquer de ressources.

2
Raja Rama Mohan Thavalam

Ne [~ # ~] pas [~ # ~] utilisez la protection basée sur PHP, c'est horrible et n'aura quasiment aucun impact! Configurez votre serveur Web pour limiter le nombre de demandes, par exemple dans Nginx à l'aide du module limit_req ( http://nginx.org/en/docs/http/ngx_http_limit_req_module.html )

Bien que, je recommanderais d'utiliser CloudFlare pour combattre la couche 4 - mais pas les attaques basées sur la couche 7 sauf si vous êtes prêt à payer.

2
JustLloyd

Anti DDOS étapes:

  • La toute première chose importante est d’identifier en premier l’attaque DDOS. Identifier l’attaque DDOS plus tôt signifie mieux pour votre serveur.
  • Obtenir une meilleure bande passante disponible pour votre serveur. Conservez toujours suffisamment de bande passante pour votre serveur. Cela n’empêchera pas les attaques par DDOS mais cela prendra plus de temps. Par ce que vous aurez un peu plus de temps pour agir.
  • Si vous possédez votre propre serveur Web, vous pouvez alors définir des paramètres réseau en limitant le débit de votre routeur, en ajoutant des filtres pour lâcher des paquets vers différentes sources d'attaques et en expirant de manière plus agressive les connexions à moitié ouvertes. Définissez également des seuils d'abandon inondation SYN, ICMP et UDP inférieurs.
  • Si vous n’êtes pas très au courant de ces choses, contactez rapidement vos hébergeurs. Ils peuvent faire de leur mieux pour empêcher les attaques DDOS.
  • Il existe également un service spécial d'atténuation DDOS fourni par Cloudflare et de nombreuses autres entreprises. Grâce à quoi ils peuvent vous aider à prévenir les attaques DDOS. En outre, de nombreuses entreprises proposent des services bon marché: protection du texte et protection du dos.
1
IamNOOB