Vous subissez une attaque par déni de service. Si le trafic provient de plusieurs réseaux (différentes adresses IP sur différents sous-réseaux), il s'agit d'un déni de service distribué (DDoS) ; s'il provient du même endroit, il s'agit d'un simple déni de service. Il peut être utile de vérifier, si vous le pouvez ; utilisez netstat pour vérifier. Cela peut être difficile à faire, cependant.

Le déni de service se divise généralement en deux catégories : le déni de trafic et le déni de charge. Le dernier élément (avec le service qui s'effondre) est un déni de service basé sur l'exploitation et est très différent.

Si vous essayez de déterminer le type d'attaque qui se produit, vous voudrez peut-être capturer du trafic (en utilisant wireshark, tcpdump ou libpcap). Vous devriez le faire, si possible, mais sachez également que vous capturerez probablement une grande quantité de trafic.

Le plus souvent, elles proviennent de réseaux de zombies (réseaux d'hôtes compromis placés sous le contrôle central d'un attaquant, dont ils exécutent les ordres). C'est un bon moyen pour l'attaquant d'acquérir (à très bon marché) la bande passante en amont de nombreux hôtes différents sur différents réseaux pour vous attaquer, tout en couvrant ses traces. Le site Canon à ions en orbite basse est un exemple de botnet (bien qu'il soit volontaire et non issu d'un logiciel malveillant) ; Zeus en est un plus typique.

Basé sur le trafic

Si vous êtes sous un DoS basé sur le trafic, vous trouvez que il y a juste tellement de trafic arrivant à votre serveur que sa connexion à Internet est complètement saturée. Le taux de perte de paquets est élevé lorsque vous envoyez une requête ping à votre serveur depuis un autre endroit et (selon les méthodes de routage utilisées), vous constatez parfois aussi une latence très élevée (le ping est élevé). Ce type d'attaque est généralement une attaque DDoS.

Bien qu'il s'agisse d'une attaque vraiment "bruyante" et que ce qui se passe soit évident, il est difficile pour un administrateur de serveur de l'atténuer (et pratiquement impossible pour un utilisateur d'hébergement partagé). Vous aurez besoin de l'aide de votre fournisseur d'accès Internet ; faites-lui savoir que vous subissez une attaque DDoS et il pourra peut-être vous aider.

Cependant, la plupart des FAI et des fournisseurs de transit se rendront compte de manière proactive de ce qui se passe et publieront une route du trou noir pour votre serveur. Cela signifie qu'ils publient une route vers votre serveur avec un coût aussi faible que possible, par le biais de 0.0.0.0 Ils font en sorte que le trafic vers votre serveur ne puisse plus être acheminé sur Internet. Ces routes sont généralement des /32 et elles finissent par être supprimées. Cela ne vous aide pas du tout ; le but est de protéger le réseau du FAI du déluge. Pendant ce temps, votre serveur perd effectivement l'accès à Internet.

Le seul moyen pour votre fournisseur d'accès (ou pour vous, si vous avez votre propre AS) de vous aider est d'utiliser des outils intelligents de gestion du trafic capables de détecter et de limiter le trafic DDoS probable. Tout le monde ne dispose pas de cette technologie. Cependant, si le trafic provient d'un ou deux réseaux, ou d'un seul hôte, ils peuvent aussi être en mesure de bloquer le trafic avant vous.

En bref, il y a très peu de choses que vous pouvez faire sur ce problème. La meilleure solution à long terme consiste à héberger vos services en de nombreux endroits différents sur Internet, qui devraient être soumis à des attaques DDoS individuelles et simultanées, ce qui rendrait l'attaque DDoS beaucoup plus coûteuse. Les stratégies à cet égard dépendent du service que vous devez protéger ; le DNS peut être protégé par de multiples serveurs de noms faisant autorité, le SMTP par des enregistrements MX de secours et des échangeurs de courrier, et le HTTP par un DNS round-robin ou un multihoming (mais une certaine dégradation pourrait être perceptible pendant la durée du service).

Les équilibreurs de charge sont rarement une solution efficace à ce problème, car l'équilibreur de charge lui-même est soumis au même problème et ne fait que créer un goulot d'étranglement. Les IPTables ou autres les règles du pare-feu ne sont d'aucune utilité parce que le problème est que votre tuyau est saturé. Une fois que les connexions sont vues par votre pare-feu, il est déjà trop tard. ; la bande passante vers votre site a été consommée. Peu importe ce que vous faites avec les connexions ; l'attaque est atténuée ou terminée lorsque le volume du trafic entrant revient à la normale.

Si vous êtes en mesure de le faire, envisagez d'utiliser une réseau de distribution de contenu (CDN) comme Akamai, Limelight et CDN77, ou utiliser un service d'élimination des DDoS comme CloudFlare ou Prolexic. Ces services prennent des mesures actives pour atténuer ce type d'attaques et disposent d'une bande passante disponible en tellement d'endroits différents qu'il n'est généralement pas possible de les inonder.

Si vous décidez d'utiliser CloudFlare (ou tout autre CDN/proxy), n'oubliez pas de cacher l'IP de votre serveur. Si un attaquant découvre l'adresse IP, il peut à nouveau lancer une attaque DDoS sur votre serveur directement, en contournant CloudFlare. Pour cacher l'IP, votre serveur ne doit jamais communiquer directement avec d'autres serveurs/utilisateurs, sauf s'ils sont sûrs. Par exemple, votre serveur ne doit pas envoyer d'e-mails directement aux utilisateurs. Cela ne s'applique pas si vous hébergez tout votre contenu sur le CDN et ne disposez pas de votre propre serveur.

En outre, certains fournisseurs de VPS et d'hébergement sont plus aptes à atténuer ces attaques que d'autres. En général, plus ils sont grands, plus ils seront performants dans ce domaine ; un fournisseur très bien desservi et disposant d'une grande largeur de bande sera naturellement plus résilient, et un fournisseur disposant d'une équipe d'exploitation de réseau active et complète sera en mesure de réagir plus rapidement.

Basé sur la charge

Lorsque vous subissez un DDoS basé sur la charge, vous remarquez que la la moyenne de charge est anormalement élevée (ou l'utilisation du processeur, de la mémoire vive ou du disque, en fonction de votre plate-forme et des spécificités). Bien que le serveur ne semble pas faire quoi que ce soit d'utile, il est très occupé. Souvent, les journaux contiennent un grand nombre d'entrées indiquant des conditions inhabituelles. Le plus souvent, cela provient d'un grand nombre d'endroits différents et il s'agit d'un DDoS, mais ce n'est pas nécessairement le cas. Il n'est même pas nécessaire qu'il y ait beaucoup d'hôtes différents. .

Cette attaque est basée sur le fait de faire faire à votre service beaucoup de choses coûteuses. Cela peut être quelque chose comme l'ouverture d'un nombre gargantuesque de connexions TCP et vous forcer à maintenir un état pour celles-ci, ou le téléchargement de fichiers excessivement grands ou nombreux vers votre service, ou peut-être des recherches très coûteuses, ou vraiment tout ce qui est coûteux à gérer. Le trafic se situe dans les limites de ce que vous avez prévu et de ce que vous pouvez supporter, mais les types de demandes formulées sont trop coûteux pour traiter un si grand nombre de demandes. .

Tout d'abord, le fait que ce type d'attaque soit possible est souvent le signe d'une problème ou bogue de configuration à votre service. Par exemple, il se peut que vous ayez activé une journalisation trop verbeuse et que vous stockiez les journaux sur un support dont l'écriture est très lente. Si quelqu'un s'en rend compte et fait quelque chose qui vous oblige à écrire de grandes quantités de journaux sur le disque, votre serveur va ralentir. Votre logiciel peut aussi faire quelque chose d'extrêmement inefficace pour certains cas d'entrée ; les causes sont aussi nombreuses qu'il y a de programmes, mais deux exemples seraient une situation qui fait que votre service ne ferme pas une session qui est autrement terminée, et une situation qui fait qu'il génère un processus enfant et le quitte. Si vous vous retrouvez avec des dizaines de milliers de connexions ouvertes avec un état à suivre, ou des dizaines de milliers de processus enfants, vous aurez des problèmes.

La première chose que vous pouvez faire est de utiliser un pare-feu pour supprimer le trafic . Ce n'est pas toujours possible, mais s'il existe une caractéristique que vous pouvez trouver dans le trafic entrant (tcpdump peut être utile pour cela si le trafic est léger), vous pouvez l'abandonner au niveau du pare-feu et il ne posera plus de problème. L'autre chose à faire est de corriger le bogue dans votre service (prenez contact avec le fournisseur et préparez-vous à une longue expérience de support).

Cependant, si c'est un problème de configuration, commencez par là. . Réduisez la journalisation sur les systèmes de production à un niveau raisonnable (selon le programme, il s'agit généralement de la valeur par défaut, et cela implique généralement de s'assurer que les niveaux de journalisation "debug" et "verbose" sont désactivés ; si tout ce que fait un utilisateur est enregistré dans les moindres détails, votre journalisation est trop verbeuse). En outre, vérifier les limites des processus et des demandes des enfants éventuellement papillon des gaz les requêtes entrantes, les connexions par IP, et le nombre de processus enfants autorisés, le cas échéant.

Il va sans dire que plus votre serveur est bien configuré et bien approvisionné, plus ce type d'attaque sera difficile. Évitez d'être avare en RAM et en CPU en particulier. Assurez-vous que vos connexions à des éléments tels que les bases de données dorsales et le stockage sur disque sont rapides et fiables.

Basé sur des exploits

Si votre service est mystérieusement se plante extrêmement rapidement après être apparu, en particulier si vous pouvez établir un schéma de requêtes qui précèdent le crash et que la requête est atypique ou ne correspond pas aux schémas d'utilisation attendus, vous pourriez être confronté à un DoS basé sur un exploit. Cela peut provenir d'un seul hôte (avec à peu près n'importe quel type de connexion Internet) ou de nombreux hôtes.

C'est similaire à un DoS basé sur la charge à bien des égards, et a fondamentalement les mêmes causes et atténuations. La différence est simplement que dans ce cas, le bogue ne provoque pas le gaspillage de votre serveur, mais sa mort. L'attaquant exploite généralement une vulnérabilité de plantage à distance, telle qu'une entrée déformée qui provoque une déférence nulle ou autre chose dans votre service.

Traitez cela de la même manière qu'une attaque d'accès à distance non autorisé. Pare-feu contre les hôtes d'origine et le type de trafic s'ils peuvent être identifiés. Utiliser des reverse proxies validants le cas échéant. Rassembler les preuves médico-légales (essayez de capturer une partie du trafic), déposez un ticket de bogue auprès du fournisseur, et envisagez de déposer une plainte pour abus (ou une plainte légale) contre l'origine également.

Ces attaques sont relativement peu coûteuses à mettre en place, si un moyen d'exploitation peut être trouvé, et elles peuvent être très puissantes, mais aussi relativement faciles à repérer et à arrêter. Cependant, les techniques qui sont utiles contre les attaques DDoS basées sur le trafic sont généralement inutiles contre les attaques DoS basées sur l'exploitation.