Je suis sous DDoS. Que puis-je faire?
Il s'agit d'une Question canonique sur l'atténuation DoS et DDoS.
J'ai trouvé un pic de trafic massif sur un site Web que j'héberge aujourd'hui; J'obtiens des milliers de connexions par seconde et je vois que j'utilise tous les 100 Mbps de ma bande passante disponible. Personne ne peut accéder à mon site car toutes les demandes expirent, et je ne peux même pas me connecter au serveur car SSH expire aussi! Cela s'est déjà produit quelques fois auparavant, et chaque fois cela a duré quelques heures et s'est évanoui de lui-même.
Parfois, mon site Web a un autre problème distinct mais connexe: la moyenne de charge de mon serveur (qui est généralement d'environ 0,25) augmente jusqu'à 20 ou plus et personne ne peut accéder à mon site de la même manière que dans l'autre cas. Il disparaît également après quelques heures.
Redémarrer mon serveur n'aide pas; que puis-je faire pour rendre mon site accessible à nouveau et que se passe-t-il?
De manière similaire, j'ai constaté une fois que pendant un jour ou deux, chaque fois que je commençais mon service, il obtenait une connexion à partir d'une adresse IP particulière, puis se bloquait. Dès que je l'ai redémarré, cela s'est produit à nouveau et il s'est à nouveau écrasé. En quoi est-ce similaire et que puis-je faire à ce sujet?
Vous rencontrez une attaque par déni de service. Si vous voyez du trafic provenant de plusieurs réseaux (différentes IP sur différents sous-réseaux), vous avez un déni de service distribué (DDoS); si tout vient du même endroit, vous avez un vieux DoS simple. Il peut être utile de vérifier si vous en êtes capable; utilisez netstat pour vérifier. Cela pourrait cependant être difficile à faire.
Le déni de service se divise généralement en deux catégories: en fonction du trafic et en fonction de la charge. Le dernier élément (avec le service de plantage) est un DoS basé sur l'exploit et est assez différent.
Si vous essayez de déterminer le type d'attaque qui se produit, vous souhaiterez peut-être capturer du trafic (à l'aide de wirehark, tcpdump ou libpcap). Vous devez, si possible, mais également être conscient que vous capturerez probablement beaucoup de trafic.
Le plus souvent, ceux-ci proviendront de réseaux de zombies (réseaux d'hôtes compromis sous le contrôle central de certains attaquants, dont ils feront les enchères). 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 leurs traces. Low Orbit Ion Cannon est un exemple de botnet (bien qu'il soit volontaire plutôt que dérivé d'un malware); Zeus est plus typique.
Basé sur le trafic
Si vous êtes sous un DoS basé sur le trafic, vous constatez que il y a tellement de trafic qui arrive sur votre serveur que sa connexion à Internet est complètement saturé. Il y a un taux de perte de paquets élevé lorsque vous envoyez une requête ping à votre serveur depuis un autre emplacement et (selon les méthodes de routage utilisées), vous constatez parfois également une latence très élevée (la requête ping est élevée). Ce type d'attaque est généralement un DDoS.
Bien qu'il s'agisse d'une attaque vraiment "bruyante" et que ce qui se passe est évident, il est difficile pour un administrateur de serveur d'atténuer (et fondamentalement impossible pour un utilisateur d'hébergement mutualisé d'atténuer). Vous allez avoir besoin de l'aide de votre FAI; faites-leur savoir que vous êtes sous DDoS et ils pourront peut-être vous aider.
Cependant, la plupart des FAI et des fournisseurs de transit réaliseront de manière proactive ce qui se passe et publieront un itinéraire de trou noir pour votre serveur. Cela signifie qu'ils publient un itinéraire vers votre serveur avec le moins de frais possible, via 0.0.0.0: ils rendent le trafic vers votre serveur plus routable sur Internet. Ces routes sont généralement des/32 et finalement elles sont supprimées. Cela ne vous aide pas du tout; le but est de protéger le réseau du FAI du déluge. Pour la durée, votre serveur perdra effectivement l'accès à Internet.
La seule façon dont votre FAI (ou vous-même, si vous avez votre propre AS) sera en mesure de vous aider est d'utiliser des shapers de trafic intelligents capables de détecter et de limiter le trafic DDoS probable. Tout le monde n'a pas cette technologie. Cependant, si le trafic provient d'un ou deux réseaux, ou d'un hôte, ils peuvent également être en mesure de bloquer le trafic devant vous.
En bref, vous ne pouvez pas faire grand chose sur ce problème. La meilleure solution à long terme consiste à héberger vos services dans de nombreux endroits différents sur Internet qui devraient être DDoSed individuellement et simultanément, ce qui rend le DDoS beaucoup plus cher. Les stratégies pour cela dépendent du service que vous devez protéger; DNS peut être protégé avec plusieurs serveurs de noms faisant autorité, SMTP avec des enregistrements MX de sauvegarde et des échangeurs de messagerie, et HTTP avec DNS à tour de rôle ou multihébergement (mais une dégradation peut être perceptible pour la durée de toute façon).
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 crée simplement un goulot d'étranglement. Les règles de pare-feu IPTables ou autres n'aideront pas car le problème est que votre pipe est saturée. Une fois que les connexions sont vues par votre pare-feu, il est déjà trop tard ; la bande passante de 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 la quantité de trafic entrant revient à la normale.
Si vous êtes en mesure de le faire, envisagez d'utiliser un réseau de distribution de contenu (CDN) comme Akamai, Limelight et CDN77, ou utilisez un service de nettoyage DDoS comme CloudFlare ou Prolexic. Ces services prennent des mesures actives pour atténuer ces types d'attaques, et disposent également d'une bande passante tellement disponible dans 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 masquer l'IP de votre serveur. Si un attaquant découvre l'adresse IP, il peut de nouveau DDoS directement votre serveur, en contournant CloudFlare. Pour masquer 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.
De plus, certains VPS et fournisseurs d'hébergement sont mieux à même d'atténuer ces attaques que d'autres. En général, plus ils sont grands, mieux ils seront dans ce domaine; un fournisseur qui est très bien homologue et qui a beaucoup de bande passante sera naturellement plus résilient, et celui avec une équipe d'exploitation de réseau active et dotée d'un personnel complet sera en mesure de réagir plus rapidement.
Basé sur la charge
Lorsque vous rencontrez un DDoS basé sur la charge, vous remarquez que la moyenne de charge est anormalement élevée (ou l'utilisation du processeur, de la RAM ou du disque, selon votre plate-forme et les détails). Bien que le serveur ne semble rien faire d'utile, il est très occupé. Souvent, il y aura de nombreuses entrées dans les journaux indiquant des conditions inhabituelles. Le plus souvent, cela vient de beaucoup d'endroits différents et est 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 que votre service fasse beaucoup de choses coûteuses. Cela pourrait être quelque chose comme ouvrir un nombre gargantuesque de connexions TCP et vous forcer à maintenir l'état pour elles, ou télécharger des fichiers trop volumineux ou trop nombreux sur votre service, ou peut-être faire des recherches très coûteuses, ou vraiment faire tout ce qui est coûteux à gérer. Le trafic est dans les limites de ce que vous avez prévu et peut prendre, mais les types de demandes en cours sont trop chers pour gérer autant de .
Tout d'abord, le fait que ce type d'attaque soit possible indique souvent un problème de configuration ou un bug dans votre service. Par exemple, vous pouvez avoir une journalisation trop prolixe activée et stocker des journaux sur quelque chose qui est très lent à écrire. Si quelqu'un s'en rend compte et fait beaucoup de choses qui vous obligent à écrire de nombreuses quantités de journaux sur le disque, votre serveur ralentira à une analyse. Votre logiciel peut également 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 amènerait votre service à ne pas fermer une session qui est par ailleurs terminée, et une situation qui l'obligerait à générer un processus enfant et à le quitter. 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 rencontrerez des problèmes.
La première chose que vous pourriez faire est d'utiliser un pare-feu pour supprimer le trafic . Ce n'est pas toujours possible, mais s'il y a une caractéristique que vous pouvez trouver dans le trafic entrant (tcpdump peut être sympa pour cela si le trafic est léger), vous pouvez le déposer sur le pare-feu et cela ne causera plus de problème. L'autre chose à faire est de corriger le bogue de votre service (contactez le fournisseur et préparez-vous à une longue expérience de support).
Cependant, s'il s'agit d'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 impliquera généralement de vous assurer que les niveaux de journalisation "debug" et "verbose" sont désactivés; si tout ce qu'un utilisateur fait est connecté exactement et détail, votre journalisation est trop verbeuse). De plus, vérifie le processus enfant et les limites de demande , éventuellement étrangle les demandes entrantes, connexions par IP et le nombre de processus enfants autorisés, le cas échéant.
Il va sans dire que plus votre serveur est mieux configuré et mieux provisionné, plus ce type d'attaque sera difficile. Évitez d'être avare avec RAM et CPU en particulier. Assurez-vous que vos connexions à des choses comme les bases de données dorsales et le stockage sur disque sont rapides et fiables.
Basé sur les exploits
Si votre service tombe mystérieusement en panne extrêmement rapidement après avoir été lancé, en particulier si vous pouvez établir un modèle de requêtes qui précède le crash et que la requête est atypique ou ne fonctionne pas ne correspondent pas aux modèles d'utilisation attendus, vous rencontrez peut-être un DoS basé sur les exploits. Cela peut provenir d'aussi peu qu'un seul hôte (avec à peu près n'importe quel type de connexion Internet) ou de plusieurs hôtes.
C'est similaire à un DoS basé sur la charge à bien des égards, et a essentiellement les mêmes causes et atténuations. La différence est simplement que dans ce cas, le bogue ne cause pas le gaspillage de votre serveur, mais sa mort. L'attaquant exploite généralement une vulnérabilité de crash à distance, telle qu'une entrée tronquée qui provoque une déréférence nulle ou quelque chose dans votre service.
Gérez cela de la même manière qu'une attaque d'accès à distance non autorisée. Pare-feu contre les hôtes d'origine et le type de trafic s'ils peuvent être épinglés. Utilisez des procurations inverses de validation le cas échéant. Recueillir des preuves médico-légales (essayer de capturer une partie du trafic), déposer un ticket de bogue auprès du vendeur et envisager de déposer une plainte pour abus (ou une plainte légale) contre l'Origine aussi.
Ces attaques sont assez bon marché à monter, si un exploit peut être trouvé, et elles peuvent être très puissantes, mais aussi relativement faciles à rechercher et à arrêter. Cependant, les techniques utiles contre les DDoS basés sur le trafic sont généralement inutiles contre les DoS basés sur les exploits.
Si vous êtes une entreprise, vous disposez de nombreuses options. Si vous êtes un petit gars comme moi, louant un VPS ou un serveur dédié pour servir un petit site Web, le coût peut rapidement devenir prohibitif.
D'après mon expérience, je pense que la plupart des fournisseurs VPS et dédiés ne configureront pas de règles de pare-feu spéciales uniquement pour votre serveur. Mais de nos jours, vous avez quelques options.
CDN
Si vous exécutez un serveur Web, envisagez de le mettre derrière un CDN comme CloudFlare ou Amazon CloudFront.
Les CDN sont chers. Pour garder le coût sous contrôle, servez des fichiers volumineux (grandes images, audio, vidéo) directement à partir de votre serveur plutôt que via le CDN. Cependant, cela peut exposer l'adresse IP de votre serveur à des attaquants.
Nuage privé
Les clouds privés sont généralement des solutions d'entreprise coûteuses, mais Amazon VPC ne coûte presque rien à configurer. Cependant, la bande passante d'Amazon en général est chère. Si vous pouvez vous le permettre, vous pouvez configurer le groupe de sécurité d'Amazon VPC et la liste de contrôle d'accès réseau pour bloquer le trafic avant qu'il n'arrive sur votre instance. Vous devez bloquer tous les ports sauf votre TCP port du serveur.
Notez qu'un attaquant peut toujours attaquer votre port de serveur TCP. S'il s'agit d'un serveur Web, envisagez d'utiliser quelque chose comme nginx qui utilise un non-blocage IO et peut gérer un grand nombre de connexions. En dehors de cela, vous ne pouvez pas faire grand-chose en plus de vous assurer que vous exécutez la dernière version du logiciel serveur.
Lorsque votre TCP est attaqué et que tout le reste échoue)
Il s'agit d'une solution que j'ai développée qui s'applique aux serveurs non Web qui ne peuvent pas se cacher derrière un CDN, tels que WebSocket, les serveurs de contenu multimédia/streaming. CloudFlare prend en charge WebSocket mais uniquement pour les entreprises pour le moment.
Le but est de changer votre TCP port d'écoute assez rapidement pour qu'un botnet ne puisse pas suivre, disons une fois toutes les 10 secondes. Ceci est accompli en utilisant un simple programme proxy qui effectue l'itinérance du port. Le la séquence de ports est pseudo-aléatoire, mais doit être basée sur l'heure du serveur. Et l'algorithme de calcul de l'heure et du port du serveur doit être caché dans le code javascript/flash de votre client. Le programme doit également modifier le pare-feu lorsqu'il change de port d'écoute , et le pare-feu doit être dynamique. Si quelqu'un est intéressé, je téléchargerai mon script node.js qui fonctionne avec Amazon, sur GitHub.
Modifiez votre domaine pour accéder à un trou noir comme 0.0.0.0 pendant une courte période.
Parlez à votre serveur et voyez s'il peut vous fournir une autre adresse IP comme moyen temporaire d'accéder au serveur ou voir si le serveur a un accès à la console à distance (comme si vous étiez assis en face de lui). De là, vous pouvez voir s'il s'agit d'une seule adresse IP et la bloquer du site ou d'une attaque distribuée.
Lorsque vous subissez une attaque DDoS contre votre FAI, cela peut vous être le plus utile, mais s'il n'a pas de protection DDoS, il est très probable que vous serez hors service jusqu'à la fin de l'attaque. Habituellement, ils verront l'adresse IP attaquée et annuleront le réseau sur leur routeur en amont. Si vous n'avez pas beaucoup de trafic, il existe de nombreux services en ligne pour la protection DDoS où votre trafic est redirigé, filtré et renvoyé à votre serveur.