C’est une question canonique sur l’atténuation des DoS et des 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 constate que j'utilise 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, le service obtenait une connexion à partir d'une adresse IP particulière, puis se bloquait. Dès que j'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?

Vous rencontrez une attaque par déni de service. Si vous voyez du trafic provenant de plusieurs réseaux (différentes adresses IP 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 qui tombe 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.

Bien souvent, ils proviendront de réseaux de zombies (réseaux d’hôtes compromis contrôlés 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 Cannon Ion Basse Orbite 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 utilisez un système DoS basé sur le trafic, vous constatez que votre serveur reçoit tellement de trafic 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, en fonction des 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 ses effets (et, en gros, impossible pour un utilisateur d'hébergement mutualisé d'atténuer ses effets). 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 services 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 une route vers votre serveur avec le moins de frais possible, via 0.0.0.0: ils rendent le trafic vers votre serveur ne peut plus être routé 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 toute cette période, 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) est en mesure de vous aider, s’ils utilisent 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, vous ne pouvez rien faire contre 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 une dégradation peut néanmoins être perceptible 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 d'autres règles de pare-feu ne vous aideront pas, car le problème est que votre canal est saturé. 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) tel que 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 courrier électronique directement aux utilisateurs. Cela 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 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 de ses 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. Le plus souvent, 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 effectuées sont trop coûteux pour être traités en si grand nombre .

Premièrement, le fait que ce type d’attaque soit possible indique souvent un problème de configuration ou un 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 de nombreuses quantités 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 à 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 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 résoudre le problème 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 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). En outre, vérifiez les limites du processus enfant et des demandes , éventuellement, étranglez 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 plante mystérieusement très rapidement après avoir été activé, en particulier si vous pouvez établir un modèle de demandes qui précède le blocage et si la demande est atypique ou ne correspond pas aux modèles d'utilisation prévus, vous rencontrez peut-être un déni de service basé sur un exploit. Cela peut venir d'un seul hôte (avec pratiquement n'importe quel type de connexion Internet) ou de nombreux hôtes.

Cela ressemble à 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 cause pas le gaspillage à 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 épinglés. Utilisez des proxy inversés de validation, le cas échéant. Rassemblez des preuves médico-légales (essayez de capturer une partie du trafic), déposez un ticket de bogue auprès du vendeur 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.

Si vous êtes une entreprise, vous avez beaucoup d'options. Si vous êtes un petit garçon 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 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 avec état. Si quelqu'un est intéressé, je téléchargerai mon script node.js qui fonctionne avec Amazon sur GitHub.

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.

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.

Nous avons la même situation avant. Ci-dessous est ce que nous avons fait.

Commencez par brancher le câble réseau de votre serveur. Maintenant, vérifiez que les services de votre serveur ont retrouvé leur comportement normal en examinant le moniteur de performances et le gestionnaire de tâches. Sinon, analysez votre serveur avec le logiciel malwarebytes pour vous assurer que votre serveur est nettoyé. Cette étape assurera généralement le retour à la normale de votre serveur déconnecté.

Ensuite, avez-vous un pare-feu en place? Si oui, avez-vous renouvelé votre abonnement? Assurez-vous d'activer la fonctionnalité d'intrusion IPS dans le pare-feu. Tout en renouvelant l'abonnement de pare-feu a résolu notre attaque DDOS.

Nous avons appris que nous devrions renouveler notre abonnement de sécurité (par exemple, Firwall ou antivirus) et ne pas le prendre à la légère. Les attaques DDOS se produisent tous les jours et peuvent également toucher les petites entreprises. J'espère que cela t'aides.