Question Je suis sous DDoS. Que puis-je faire?


C'est un Question canonique sur l'atténuation DoS et DDoS.

J'ai trouvé un pic de trafic massif sur un site Web que je héberge aujourd'hui; J'obtiens des milliers de connexions par seconde et je vois que j'utilise toutes les 100 Mbps de ma bande passante disponible. Personne ne peut accéder à mon site car toutes les demandes ont expiré et je ne peux même pas me connecter au serveur car SSH a également expiré! Cela s'est déjà produit plusieurs fois auparavant et chaque fois, cela durait quelques heures et disparaissait seul.

De temps en temps, mon site Web a un autre problème distinct mais lié: la charge moyenne de mon serveur (qui est habituellement autour de 0,25) atteint 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 connexe, j'ai constaté une fois que, pendant un jour ou deux, chaque fois que je démarrais 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 reproduit et il s'est de nouveau écrasé. Comment est-ce semblable, et que puis-je faire à ce sujet?


171
2017-08-19 09:14


origine


J'ai suivi ceci après avoir lu (Création d'une question canonique «Aide, j'obtiens DDOS-ed!»?). Est-ce que je voulais juste dire beau travail !!! - AngryWombat
Regarde aussi security.stackexchange.com/a/792/2379 - Pacerier


Réponses:


Vous rencontrez une attaque par déni de service. Si vous voyez du trafic provenant de plusieurs réseaux (adresses IP différentes sur différents sous-réseaux), vous obtenez un déni de service distribué (DDoS); si tout vient du même endroit, vous avez un vieux DoS. Il peut être utile de vérifier si vous le pouvez. Utilisez netstat pour vérifier. Cela pourrait être difficile à faire, cependant.

Le déni de service est généralement divisé en deux catégories: basé sur le trafic et basé sur la charge. Le dernier élément (avec le service en panne) est un déni de service basé sur l'exploit et est très différent.

Si vous essayez d'identifier le type d'attaque en cours, vous souhaiterez peut-être capturer du trafic (à l'aide de wireshark, de tcpdump ou de libpcap). Vous devriez, si possible, mais vous devez aussi savoir que vous allez capturer beaucoup de trafic.

Celles-ci proviendront souvent de réseaux de zombies (réseaux d’hôtes compromis contrôlés de manière centralisée par un attaquant dont ils feront les enchères). C’est un bon moyen pour l’attaquant d’acquérir (à moindre coût) la bande passante amont de nombreux hôtes différents sur des réseaux différents pour vous attaquer, tout en couvrant leurs traces. le Canon Ion Orbite Basse est un exemple de botnet (bien qu’il soit volontaire au lieu d’un logiciel malveillant); 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 venir sur votre serveur que sa connexion à Internet est complètement saturée. Il y a un taux de perte de paquets élevé lorsque vous envoyez une commande ping à votre serveur depuis un autre lieu (et, selon les méthodes de routage utilisées), vous constatez parfois une latence très élevée (la commande ping est élevée). Ce type d'attaque est généralement un DDoS.

Bien que cette attaque soit vraiment "forte" et que ce qui se passe réellement soit évidente, il est difficile pour un administrateur de serveur d'atténuer (et, en gros, 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 un DDoS et qu'ils pourront peut-être vous aider.

Cependant, la plupart des FAI et des fournisseurs de transit réalisent de manière proactive ce qui se passe et publient un rapport. route des trous noirs 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 sur votre serveur non plus routable sur Internet. Ces itinéraires sont typiquement / 32s et finalement ils sont supprimés. Cela ne vous aide pas du tout. le but est de protéger le réseau du FAI du déluge. Pendant la durée de validité de votre serveur, votre serveur perdra l'accès à Internet.

Le seul moyen que votre FAI (ou vous-même, si vous avez votre propre AS) est en mesure de vous aider est d'utiliser des adaptateurs de trafic intelligents capables de détecter et de limiter le trafic probable par DDoS. Tout le monde n'a pas cette technologie. Toutefois, 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 qui vous précède.

En bref, il y a très peu que vous puissiez faire à propos de ce problème. La meilleure solution à long terme consiste à héberger vos services dans de nombreux endroits sur Internet, qui doivent être DDoSed individuellement et simultanément, ce qui rend le traitement DDoS beaucoup plus coûteux. Les stratégies à cet égard dépendent du service que vous devez protéger. Le DNS peut être protégé avec plusieurs serveurs de noms faisant autorité, SMTP avec des enregistrements MX de sauvegarde et des échangeurs de courrier, et HTTP avec un DNS alternatif ou le multi-hébergement (mais certaines dégradations peuvent néanmoins être perceptibles pour la durée).

Les équilibreurs de charge sont rarement une solution efficace à ce problème, car l'équilibreur de charge est lui-même soumis au même problème et crée simplement un goulot d'étranglement. IPTables ou autres les règles de pare-feu ne va pas aider parce que 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 redevient normale.

Si vous le pouvez, envisagez d’utiliser un réseau de distribution de contenu (CDN) comme Akamai, Limelight et CDN77, ou utilisez un service de nettoyage DDoS tel que CloudFlare ou Prolexic. Ces services prennent des mesures actives pour atténuer ces types d’attaques et disposent d’une bande passante tellement large dans des endroits si divers qu’il n’est généralement pas envisageable de les inonder.

Si vous décidez d'utiliser CloudFlare (ou tout autre CDN / proxy), n'oubliez pas de masquer l'adresse IP de votre serveur. Si un attaquant découvre l'adresse IP, il peut à nouveau DDoS directement sur votre serveur, en contournant CloudFlare. Pour masquer l'adresse IP, votre serveur ne doit jamais communiquer directement avec d'autres serveurs / utilisateurs, à moins qu'ils ne soient en sécurité. Par exemple, votre serveur ne doit pas envoyer de courriels directement aux utilisateurs. Ceci ne s'applique pas si vous hébergez tout votre contenu sur le CDN et que vous n'avez pas de serveur vous-même.

En outre, certains fournisseurs de services VPS et d’hébergement atténuent mieux ces attaques que d’autres. En général, plus ils sont grands, mieux ils seront. un fournisseur très homogène et disposant de beaucoup de bande passante sera naturellement plus résilient, et un autre doté d’une équipe d’exploitation réseau active et disposant de tout le personnel nécessaire pourra réagir plus rapidement.

Basé sur la charge

Lorsque vous rencontrez un DDoS basé sur la charge, vous remarquez que le charge moyenne anormalement élevée (ou l’utilisation du processeur, de la RAM ou du disque, selon votre plate-forme et les spécificités). Bien que le serveur ne semble rien faire d’utile, il est très occupé. Souvent, les journaux contiennent de nombreuses entrées indiquant des conditions inhabituelles. Plus souvent qu'autrement, cela provient de nombreux endroits et est un DDoS, mais ce n'est pas nécessairement le cas. Il ne doit même pas y avoir beaucoup d'hôtes différents.

Cette attaque est basée sur l’obligation faite à votre service de faire beaucoup de choses coûteuses. Cela peut être quelque chose comme ouvrir un nombre gigantesque de connexions TCP et vous obliger à conserver leur état, ou télécharger des fichiers excessivement volumineux ou nombreux sur votre service, ou peut-être faire des recherches vraiment coûteuses, ou vraiment tout ce qui est coûteux à gérer. Le trafic est dans les limites de ce que vous aviez prévu et pouvez assumer, mais les types de demandes présentées sont trop coûteux pour traiter autant de.

Premièrement, le fait que ce type d’attaque soit possible indique souvent une problème de configuration ou bogue à votre service. Par exemple, vous pouvez activer la journalisation trop détaillée et stocker des journaux sur quelque chose de très lent à écrire. Si quelqu'un s'en rend compte et fait beaucoup de choses qui vous amènent à écrire des quantités copieuses de journaux sur le disque, votre serveur ralentira jusqu'à 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 sont une situation dans laquelle votre service ne ferme pas une session qui est autrement terminée et une situation dans laquelle il engendre un processus enfant et le laisse. Si vous vous retrouvez avec des dizaines de milliers de connexions ouvertes avec l'état à suivre, ou des dizaines de milliers de processus enfants, vous rencontrerez des problèmes.

La première chose que vous pourriez être capable de faire est 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 intéressant pour cela si le trafic est léger), vous pouvez le laisser tomber au niveau du pare-feu et cela ne causera plus de problèmes. L'autre chose à faire est de corriger le bogue dans votre service (contactez 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 configuration par défaut. Vous devrez donc vous assurer que les niveaux de journalisation "débogage" et "détaillé" sont désactivés. Si tout ce que l'utilisateur fait est journalisé exactement et détail, votre enregistrement est trop prolixe). Aditionellement, vérifier le processus enfant et demander des limites, peut-être étrangler les demandes 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 configuré et mis en service, plus ce type d'attaque sera difficile. Évitez d'être radin avec la RAM et le processeur en particulier. Assurez-vous que vos connexions à des éléments tels que les bases de données principales et le stockage sur disque sont rapides et fiables.

Basé sur les exploits

Si votre service mystérieusement se bloque extrêmement vite après avoir été mis en place, en particulier si vous pouvez établir un modèle de demandes précédant le blocage et si la demande est atypique ou ne correspond pas aux modèles d'utilisation attendus, vous rencontrerez peut-être un déni de service basé sur l'exploit. Cela peut venir d'un seul hôte (avec pratiquement 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 essentiellement 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 la mort. L'attaquant exploite généralement une vulnérabilité d'incident à distance, telle qu'une entrée tronquée qui provoque une déréférence null ou quelque chose de votre service.

Manipulez-le de la même manière qu'une attaque par accès distant non autorisée. Pare-feu contre les hôtes d'origine et le type de trafic s'ils peuvent être bloqués. Utiliser des proxys inversés de validation le cas échéant. Rassembler des 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 plainte légale) contre l'origine également.

Ces attaques sont relativement peu coûteuses à monter, si un exploit peut être trouvé, et elles peuvent être très puissantes, mais aussi relativement faciles à localiser et à arrêter. Cependant, les techniques utiles contre les attaques DDoS basées sur le trafic sont généralement inutiles contre les attaques DoS basées sur les exploitations.


183
2017-08-19 09:14



En ce qui concerne votre dernier paragraphe, et si vous obtenez basé sur l'exploit ré DoS? Comment pourriez-vous localiser et arrêter? - Pacerier


Si vous êtes une entreprise, vous avez beaucoup d'options. Si vous êtes un petit bonhomme comme moi qui loue un VPS ou un serveur dédié pour servir un petit site web, les coûts peuvent vite devenir prohibitifs.

D'après mon expérience, je pense que la plupart des fournisseurs dédiés et VPS 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 utilisez un serveur Web, envisagez de le placer derrière un CDN tel que CloudFlare ou Amazon CloudFront.

Les CDN sont chers. Pour contrôler les coûts, servez des fichiers volumineux (grandes images, audio, vidéo) directement à partir de votre serveur plutôt que via le CDN. Cependant, cela peut exposer votre adresse IP de 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 pratiquement rien à configurer. Cependant, la bande passante d'Amazon est généralement chère. Si vous en avez les moyens, vous pouvez configurer les groupes de sécurité du groupe de sécurité et du réseau Amazon VPC pour bloquer le trafic avant son arrivée sur votre instance. Vous devez bloquer tous les ports sauf le port de votre serveur TCP.

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 des E / S non bloquantes et peut gérer un grand nombre de connexions. En dehors de cela, vous ne pouvez rien faire d'autre que de vous assurer d'exécuter la dernière version du logiciel serveur.

Lorsque votre port TCP est attaqué et que tout le reste échoue

C’est une solution que j’ai développée et 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 supporte WebSocket mais uniquement pour les entreprises pour le moment.

L'objectif est de changer votre port d'écoute TCP assez rapidement pour qu'un réseau de zombies ne puisse pas suivre, par exemple une fois toutes les 10 secondes. Ceci est accompli en utilisant un programme proxy simple qui effectue l'itinérance de port. 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 du serveur et du port doit être masqué 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 avec état. Si quelqu'un est intéressé, je téléchargerai mon script node.js qui fonctionne avec Amazon sur GitHub.


6
2017-12-05 18:04





Changez votre domaine pour aller dans un trou noir comme 0.0.0.0 pendant une courte période.

Parlez à votre serveur et voyez s'il peut vous attribuer une autre adresse IP comme moyen temporaire d'accéder au serveur ou si le serveur dispose d'un accès à la console à distance (comme si vous étiez assis en face de lui). À partir de là, vous pouvez voir s’il s’agit d’une adresse IP unique et la bloquer depuis le site ou une attaque distribuée.


3
2018-02-26 07:44



Changer le DNS de cette façon fera probablement plus de mal que de bien. Au début, je réduisais la durée de vie de l'enregistrement A, mais je ne modifiais pas l'adresse IP - jusqu'à ce que je dispose d'une nouvelle adresse IP. - kasperd


Lorsque vous êtes sous attaque DDoS chez votre fournisseur de services Internet, cela peut vous aider au maximum, mais s’ils n’ont pas de protection DDoS, il est fort probable que vous serez hors service jusqu’à ce que l’attaque cesse. Habituellement, ils verront l'adresse IP attaquée et annuleront le réseau sur leur routeur en amont. Si vous avez peu de trafic, il existe de nombreux services en ligne pour la protection contre les attaques DDoS, dans lesquels votre trafic est redirigé, filtré et renvoyé à votre serveur.


0
2017-11-18 11:42