Qu'est-ce qu'une attaque ddos. Attaque DDoS : qu'est-ce que c'est, comment ça marche et s'il est possible de se protéger

Sur un système informatique afin de le mettre en panne, c'est-à-dire la création de telles conditions dans lesquelles les utilisateurs légaux (légitimes) du système ne peuvent pas accéder aux ressources (serveurs) fournies par le système, ou cet accès est difficile. La défaillance du système "ennemi" peut également être une étape vers la maîtrise du système (si en cas d'urgence, le logiciel donne des informations critiques - par exemple, la version, une partie du code du programme, etc.). Mais le plus souvent, il s'agit d'une mesure de pression économique : temps d'arrêt d'un service générateur de revenus, factures du fournisseur et mesures pour éviter qu'une attaque ne touche de manière significative la « cible » dans la poche.

Si une attaque est menée simultanément depuis un grand nombre d'ordinateurs, on parle de Attaque DDoS(de l'anglais. Déni de service distribué, attaque par déni de service distribué). Dans certains cas, une action involontaire conduit à une véritable attaque DDoS, par exemple placer un lien sur une ressource Internet populaire vers un site hébergé sur un serveur peu productif (effet slash dot). Un afflux important d'utilisateurs entraîne un dépassement de la charge autorisée sur le serveur et, par conséquent, un déni de service pour certains d'entre eux.

Types d'attaques DoS

Il existe plusieurs raisons pour lesquelles une condition DoS peut se produire :

Erreur dans le code du programme, entraînant l'accès à un fragment inutilisé de l'espace d'adressage, l'exécution d'une instruction non valide ou toute autre exception non gérée lorsque le programme serveur tombe en panne - le programme serveur. Un exemple classique est le référencement à base zéro. nul) adresse.
Validation insuffisante des données utilisateur, entraînant un cycle infini ou long ou une consommation accrue à long terme des ressources processeur (jusqu'à l'épuisement des ressources processeur) ou l'allocation d'une grande quantité de RAM (jusqu'à l'épuisement de la mémoire disponible).
inondation(Anglais) inondation- "flood", "overflow") - une attaque associée à un grand nombre de requêtes généralement dénuées de sens ou mal formatées adressées à un système informatique ou à un équipement réseau, qui a pour objectif ou conduit à une défaillance du système en raison de l'épuisement des ressources système - le processeur, la mémoire ou les canaux de communication.
Attaque du deuxième type- une attaque qui cherche à provoquer une fausse alarme du système de protection et ainsi conduire à l'indisponibilité de la ressource.

Si une attaque (généralement un flood) est menée simultanément à partir d'un grand nombre d'adresses IP - à partir de plusieurs ordinateurs dispersés dans le réseau - alors dans ce cas on l'appelle distribué attaque par déni de service ( DDoS).

Exploitation de bogues

Exploiter fait référence à un programme, à un morceau de code de programme ou à une séquence de commandes de programme qui exploitent les vulnérabilités d'un logiciel et sont utilisées pour attaquer un cybersystème. Parmi les exploits qui mènent à une attaque DoS, mais qui sont inadaptés, par exemple, pour prendre le contrôle d'un système « ennemi », les plus célèbres sont WinNuke et Ping of death (Ping de la mort).

inondation

Pour les inondations en tant que violation de la nétiquette, voir inondations .

inondation ils appellent un énorme flux de demandes sans signification de différents ordinateurs afin de prendre le système "ennemi" (processeur, RAM ou canal de communication) avec le travail et ainsi le désactiver temporairement. Le concept d'"attaque DDoS" est presque équivalent au concept de "flood", et dans la vie de tous les jours, les deux sont souvent interchangeables ("flood the server" = "DDoS'it the server").

Pour créer une inondation, vous pouvez utiliser à la fois des utilitaires réseau ordinaires tels que ping (ce que l'on appelle, par exemple, la communauté Internet " Upyachka") et des programmes spéciaux. La possibilité de DDoS est souvent "cousue" dans les botnets. Si une vulnérabilité de script intersite ou la possibilité d'inclure des images provenant d'autres ressources est détectée sur un site à fort trafic, ce site peut également être utilisé pour une attaque DDoS.

Inondation du canal de communication et du sous-système TCP

Tout ordinateur qui communique avec le monde extérieur via le protocole TCP/IP est sujet à ces types d'inondations :

Inondation SYN - avec ce type d'attaque par inondation, un grand nombre de paquets SYN sont envoyés au nœud attaqué via le protocole TCP (demandes d'ouverture de connexion). Dans le même temps, après un court laps de temps, le nombre de sockets disponibles pour l'ouverture (sockets réseau logiciels, ports) est épuisé sur l'ordinateur attaqué et le serveur cesse de répondre.
Inondation UDP - ce type d'inondation n'attaque pas l'ordinateur cible, mais son canal de communication. Les fournisseurs supposent raisonnablement que les paquets UDP doivent être livrés en premier, tandis que TCP peut attendre. Un grand nombre de paquets UDP de différentes tailles obstruent le canal de communication et le serveur fonctionnant sur le protocole TCP cesse de répondre.
Inondation ICMP - la même chose, mais avec l'aide de paquets ICMP.

Inondation de la couche d'application

De nombreux services sont conçus de telle manière qu'une petite requête peut entraîner une grande consommation de puissance de calcul sur le serveur. Dans ce cas, ce n'est pas le canal de communication ou le sous-système TCP qui est attaqué, mais le service (service) lui-même - un flot de telles requêtes "malades". Par exemple, les serveurs Web sont vulnérables à l'inondation HTTP - soit un simple GET / ou une requête de base de données complexe comme GET /index.php?search= peut être utilisé pour désactiver un serveur Web<случайная строка> .

Détection d'attaque DoS

Il existe une opinion selon laquelle des outils spéciaux pour détecter les attaques DoS ne sont pas nécessaires, car le fait d'une attaque DoS ne peut être négligé. Dans de nombreux cas, cela est vrai. Cependant, des attaques DoS réussies ont été observées assez souvent, qui n'ont été remarquées par les victimes qu'après 2-3 jours. Il est arrivé que les conséquences négatives d'une attaque ( inondation-attaques) ont entraîné des coûts excessifs pour payer le trafic Internet excédentaire, qui n'a été découvert que lors de la réception d'une facture d'un fournisseur d'accès Internet. De plus, de nombreuses méthodes de détection d'intrusion sont inefficaces près de la cible de l'attaque, mais sont efficaces sur les dorsales du réseau. Dans ce cas, il est conseillé d'installer des systèmes de détection exactement là, et de ne pas attendre que l'utilisateur qui a été attaqué le remarque lui-même et demande de l'aide. De plus, afin de contrer efficacement les attaques DoS, il est nécessaire de connaître le type, la nature et d'autres caractéristiques des attaques DoS, et les systèmes de détection permettent d'obtenir rapidement ces informations.

Les méthodes de détection d'attaques DoS peuvent être divisées en plusieurs grands groupes :

signature - basée sur une analyse qualitative du trafic.
statistiques - basées sur une analyse quantitative du trafic.
hybride (combiné) - combinant les avantages des deux méthodes ci-dessus.

Protection DoS

Les mesures pour contrer les attaques DoS peuvent être divisées en passives et actives, ainsi qu'en préventives et réactives.

Vous trouverez ci-dessous une brève liste des principales méthodes.

La prévention. Prévention des raisons qui poussent certains individus à organiser et entreprendre des attaques DoS. (Très souvent, les cyberattaques en général sont le résultat de griefs personnels, de désaccords politiques, religieux et autres, d'un comportement provocateur de la victime, etc.)
Filtrage et blackholing. Bloquer le trafic des machines attaquantes. L'efficacité de ces méthodes diminue à mesure que vous vous rapprochez de l'objet de l'attaque et augmente à mesure que vous vous rapprochez de la machine attaquante.
DDOS inversé- rediriger le trafic utilisé pour l'attaque vers l'attaquant.
Élimination des vulnérabilités. Ne fonctionne pas contre inondation-les attaques pour lesquelles la "vulnérabilité" est la finitude de certaines ressources système.
Augmenter les ressources. Naturellement, il n'offre pas une protection absolue, mais c'est un bon arrière-plan pour appliquer d'autres types de protection contre les attaques DoS.
Dispersion. Construire des systèmes distribués et dupliqués qui n'arrêteront pas de servir les utilisateurs, même si certains de leurs éléments deviennent indisponibles en raison d'une attaque DoS.
Évasion.Éloigner la cible immédiate de l'attaque (nom de domaine ou adresse IP) des autres ressources qui sont souvent également affectées avec la cible immédiate de l'attaque.
Réponse active. Impact sur les sources, l'organisateur ou le centre de contrôle de l'attaque, à la fois par des moyens humains, organisationnels et légaux.
Utiliser des équipements pour repousser les attaques DoS. Par exemple DefensePro® (Radware), Perimeter (MFI Soft), Arbor Peakflow® et d'autres fabricants.
Acquisition d'un service de protection contre les attaques DoS. Réel en cas de dépassement de la bande passante du canal réseau par le flood.

voir également

Remarques

Littérature

Chris Kaspersky Virus informatiques à l'intérieur et à l'extérieur. - Pierre. - Saint-Pétersbourg. : Pierre, 2006. - S. 527. - ISBN 5-469-00982-3
Stephen Northcutt, Mark Cooper, Matt Fearnow, Karen Frederik. Analyse des failles de sécurité typiques dans les réseaux = Intrusion Signatures and Analysis. - New Riders Publishing (anglais) St. Petersburg: Williams Publishing House (russe), 2001. - P. 464. - ISBN 5-8459-0225-8 (russe), 0-7357-1063-5 (anglais)
Morris, R.T.= Une faiblesse dans le logiciel 4.2BSD Unix TCP/IP. - Rapport Technique Informatique N°117. - AT&T Bell Laboratories, février 1985.
Bellovin, S.M.= Problèmes de sécurité dans la suite de protocoles TCP/IP. - Revue de communication informatique, Vol. 19, n°2. - Laboratoires AT&T Bell, avril 1989.
= daemon9 / route / infinity "IP-spooling démystifié : Trust Realationship Exploitation". - Phrack Magazine, Vol.7, Numéro 48. - Guild Production, juillet 1996.
= daemon9/route/infinity "Projet Neptune". - Phrack Magazine, Vol.7, Numéro 48. - Guild Production, juillet 1996.

Liens

Attaque DOS dans le répertoire de liens du projet Open Directory (

De plus en plus, dans les messages officiels des hébergeurs, ici et là, les mentions d'attaques DDoS réfléchies scintillent. De plus en plus, les utilisateurs, ayant découvert l'indisponibilité de leur site, assument immédiatement le DDoS. En effet, début mars, le Runet a connu toute une vague d'attaques de ce type. Dans le même temps, les experts assurent que le plaisir ne fait que commencer. Il est tout simplement impossible d'ignorer un phénomène aussi pertinent, formidable et intrigant. Parlons donc aujourd'hui des mythes et des faits sur les attaques DDoS. Du point de vue de l'hébergeur, bien sûr.

jour commémoratif

Le 20 novembre 2013, pour la première fois en 8 ans d'histoire de notre société, l'ensemble du site technique était indisponible pendant plusieurs heures en raison d'une attaque DDoS sans précédent. Des dizaines de milliers de nos clients dans toute la Russie et la CEI ont souffert, sans parler de nous et de notre fournisseur d'accès Internet. La dernière chose que le fournisseur a réussi à corriger avant que la lumière blanche ne disparaisse pour tout le monde était que ses canaux d'entrée étaient étroitement obstrués par le trafic entrant. Pour visualiser cela, imaginez votre baignoire avec un évier ordinaire, dans lequel les chutes du Niagara se sont engouffrées.

Même les fournisseurs en amont ont ressenti les échos de ce tsunami. Les graphiques ci-dessous illustrent clairement ce qui s'est passé ce jour-là avec le trafic Internet à Saint-Pétersbourg et en Russie. Faites attention aux pics abrupts à 15h00 et 18h00, juste au moment où nous avons enregistré les attaques. Sur ces soudain plus 500-700 Go.

Il a fallu plusieurs heures pour localiser l'attaque. Le serveur auquel il a été envoyé a été calculé. Ensuite, le but des terroristes sur Internet a été calculé. Savez-vous qui a touché toute cette artillerie ennemie ? Un site client très ordinaire et modeste chacun.

Mythe numéro un : « L'objet de l'attaque est toujours l'hébergeur. Ce sont les machinations de ses concurrents. Pas le mien." En fait, la cible la plus probable pour les terroristes sur Internet est un site client régulier. C'est-à-dire le site d'un de vos voisins hébergeurs. Et peut-être le vôtre aussi.

Pas tous les DDoS...

Après les événements survenus sur notre site technique le 20 novembre 2013 et leur répétition partielle le 9 janvier 2014, certains utilisateurs ont commencé à présumer du DDoS en cas de défaillance particulière de leur propre site : « This is DDoS ! et "Avez-vous encore DDoS ?"

Il est important de se rappeler que si nous subissons un tel DDoS que même les clients le ressentent, nous le signalons immédiatement nous-mêmes.

Nous voulons rassurer ceux qui sont pressés de paniquer : si quelque chose ne va pas avec votre site, alors la probabilité qu'il s'agisse d'un DDoS est inférieure à 1 %. Tout simplement parce que beaucoup de choses peuvent arriver sur le site et que ce "beaucoup de choses" arrive beaucoup plus souvent. Nous parlerons des méthodes d'autodiagnostic rapide de ce qui se passe exactement avec votre site dans l'un des articles suivants.

En attendant - dans un souci d'exactitude de l'utilisation des mots - clarifions les termes.

À propos des termes

Attaque DoS (de l'anglais Denial of Service) - il s'agit d'une attaque conçue pour empêcher un serveur d'accéder au service en raison de sa surcharge.

Les attaques DoS ne sont pas liées à des dommages à l'équipement ou au vol d'informations ; leur objectif - faire en sorte que le serveur cesse de répondre. La différence fondamentale entre DoS est que l'attaque se produit d'une machine à l'autre. Il y a exactement deux participants.

Mais en réalité, nous n'observons pratiquement pas d'attaques DoS. Pourquoi? Car les objets d'attaques sont le plus souvent des objets industriels (par exemple, de puissants serveurs productifs d'hébergeurs). Et pour causer des dommages notables au fonctionnement d'une telle machine, il faut beaucoup plus de puissance que la sienne. C'est le premier. Et deuxièmement, l'initiateur d'une attaque DoS est assez facile à calculer.

DDoS - essentiellement le même que DoS, seule l'attaque est caractère distribué. Pas cinq, pas dix, pas vingt, mais des centaines et des milliers d'ordinateurs accèdent simultanément à un serveur à partir de différents endroits. Une telle armée de machines s'appelle botnet. Il est presque impossible de calculer le client et l'organisateur.

complices

Quels types d'ordinateurs sont inclus dans le botnet ?

Vous serez surpris, mais ce sont souvent les machines domestiques les plus ordinaires. Qui sait?.. - très probablement votre ordinateur personnel attiré du côté du mal.

Il faut un peu pour cela. Un attaquant trouve une vulnérabilité dans un système d'exploitation ou une application populaire et l'utilise pour infecter votre ordinateur avec un cheval de Troie qui, à un certain jour et à une certaine heure, demande à votre ordinateur de commencer à effectuer certaines actions. Par exemple, envoyez des requêtes à une adresse IP spécifique. Sans votre connaissance et votre participation, bien sûr.

Mythe numéro deux : « DDoS se fait quelque part loin de moi, dans un bunker souterrain spécial où sont assis des pirates barbus aux yeux rouges. En effet, sans le savoir, vous, vos amis et voisins - n'importe qui peut être un complice involontaire.

C'est vraiment ce qui se passe. Même si vous n'y pensez pas. Même si vous êtes terriblement loin de l'informatique (surtout si vous êtes loin de l'informatique !).

Piratage divertissant ou mécanique DDoS

Le phénomène DDoS est hétérogène. Ce concept combine de nombreuses options d'actions qui conduisent à un résultat (déni de service). Considérez les options pour les problèmes que les DDoSers peuvent nous apporter.

Surconsommation des ressources informatiques du serveur

Cela se fait en envoyant des paquets à une adresse IP spécifique, dont le traitement nécessite une grande quantité de ressources. Par exemple, pour charger une page, vous devez exécuter un grand nombre de requêtes SQL. Tous les attaquants demanderont cette page particulière, ce qui entraînera une surcharge du serveur et un déni de service pour les visiteurs normaux et légitimes du site.
C'est une attaque du niveau d'un écolier qui a consacré quelques soirées à lire le magazine Hacker. Elle n'est pas un problème. La même URL demandée est calculée instantanément, après quoi son accès est bloqué au niveau du serveur Web. Et ce n'est qu'une des solutions.

Surcharge des canaux de communication vers le serveur (vers la sortie)

Le niveau de difficulté de cette attaque est à peu près le même que le précédent. L'attaquant calcule la page la plus lourde du site, et le botnet sous son contrôle commence à la demander en masse.

Imaginez que la partie de Winnie l'ourson qui nous est invisible soit infiniment grande
Dans ce cas, il est aussi très facile de comprendre ce qui engorge exactement le canal sortant, et d'interdire l'accès à cette page. Les requêtes du même type sont faciles à voir à l'aide d'utilitaires spéciaux qui vous permettent de regarder l'interface réseau et d'analyser le trafic. Ensuite, une règle est écrite pour le pare-feu, qui bloque de telles requêtes. Tout cela est fait régulièrement, automatiquement et si rapidement que la plupart des utilisateurs ne sont au courant d'aucune attaque.

Mythe numéro trois : "UN Cependant, ils visitent rarement souvent mon hébergement et je les remarque toujours. En fait, 99,9 % des attaques ne sont ni visibles ni ressenties. Mais la lutte quotidienne avec eux - c'est le travail quotidien et routinier d'une société d'hébergement. C'est notre réalité, dans laquelle l'attaque est bon marché, la concurrence est hors normes, et tout le monde ne fait pas preuve de lisibilité dans les méthodes de lutte pour une place au soleil.

Surcharge des canaux de communication vers le serveur (à l'entrée)

C'est déjà un casse-tête pour ceux qui lisent le magazine Hacker depuis plus d'une journée.

Photo du site Web de la radio "Echo de Moscou". Ils n'ont rien trouvé de plus illustratif pour représenter les DDoS avec surcharge de canal à l'entrée.
Pour remplir le canal de trafic entrant à pleine capacité, vous devez disposer d'un botnet dont la puissance vous permet de générer la quantité de trafic requise. Mais peut-être existe-t-il un moyen de donner peu de trafic et d'en obtenir beaucoup ?

Il y en a, et pas un. Il existe de nombreuses options pour améliorer l'attaque, mais l'une des plus populaires en ce moment est attaque via des serveurs DNS publics. Les experts appellent cette méthode d'amplification Amplification DNS(au cas où quelqu'un préfère les termes d'experts). Et si c'est plus simple, alors imaginez une avalanche : un petit effort suffit pour la perturber, et des moyens inhumains pour l'arrêter.

Toi et moi savons que serveur DNS public sur demande, informe quiconque veut des données sur n'importe quel nom de domaine. Par exemple, nous demandons à un tel serveur : parlez-moi du domaine sprinthost.ru. Et lui, sans hésitation, nous balance tout ce qu'il sait.

Interroger un serveur DNS est une opération très simple. Cela ne coûte presque rien de le contacter, la demande sera microscopique. Par exemple, comme ceci :

Il ne reste plus qu'à choisir un nom de domaine, dont les informations constitueront un ensemble de données impressionnant. Ainsi, les 35 octets d'origine avec un léger mouvement de la main se transforment en près de 3700. Il y a une augmentation de plus de 10 fois.

Mais comment s'assurer que la réponse est dirigée vers la bonne IP ? Comment falsifier l'IP source de la requête pour que le serveur DNS émette ses réponses en direction de la victime, qui n'a demandé aucune donnée ?

Le fait est que les serveurs DNS fonctionnent sur Protocole de communication UDP, qui n'a pas du tout besoin de confirmation de l'origine de la requête. Forger une adresse IP sortante dans ce cas n'est pas un gros problème pour un doseur. C'est pourquoi ce type d'attaque est si populaire en ce moment.

Plus important encore, un très petit botnet suffit pour mettre en œuvre une telle attaque. Et plusieurs DNS publics disparates, qui ne verront rien d'étrange dans le fait que différents utilisateurs demandent de temps en temps des données à l'adresse d'un hôte. Et alors seulement, tout ce trafic fusionnera en un seul flux et clouera fermement un «tuyau».

Ce que le doseur ne peut pas savoir, c'est la capacité des canaux de l'attaquant. Et s'il ne calcule pas correctement la puissance de son attaque et ne bloque pas immédiatement le canal vers le serveur à 100%, l'attaque peut être rapidement et facilement repoussée. Utiliser des utilitaires comme Vidage TCP il est facile de savoir que le trafic entrant provient du DNS, et au niveau du Firewall d'en interdire l'acceptation. Cette option - refuser d'accepter le trafic du DNS - est associée à un certain inconvénient pour tout le monde, cependant, les serveurs et les sites qu'ils contiennent continueront à fonctionner avec succès.

Ce n'est qu'une des nombreuses options pour améliorer l'attaque. Il existe bien d'autres types d'attaques, nous pourrons en reparler une autre fois. En attendant, je voudrais résumer que tout ce qui précède est vrai pour une attaque dont la puissance ne dépasse pas la largeur du canal vers le serveur.

Si l'attaque est forte

Si la puissance d'attaque dépasse la capacité du canal vers le serveur, ce qui suit se produit. Le canal Internet est instantanément bouché vers le serveur, puis vers le site d'hébergement, vers son fournisseur d'accès Internet, vers le fournisseur en amont, et ainsi de suite et dans l'ordre croissant (dans le futur - jusqu'aux limites les plus absurdes), jusqu'à la la puissance d'attaque est suffisante.

Et puis cela devient un problème mondial pour tout le monde. Et bref, c'est ce à quoi nous avons dû faire face le 20 novembre 2013. Et lorsque des bouleversements à grande échelle se produisent, il est temps d'activer une magie spéciale !

Voici à quoi ressemble une magie spéciale.Avec l'aide de cette magie, il est possible de calculer le serveur vers lequel le trafic est dirigé et de bloquer son adresse IP au niveau du FAI. Pour qu'il cesse d'accepter tous les appels vers cette IP via ses canaux de communication avec le monde extérieur (uplinks). Aux amateurs de termes: les experts appellent cette procédure "coupure électrique", de l'anglais blackhole.

Dans le même temps, le serveur attaqué avec 500-1500 comptes reste sans son adresse IP. Un nouveau sous-réseau d'adresses IP lui est attribué, sur lequel les comptes clients sont répartis de manière aléatoire et uniforme. De plus, les experts attendent une répétition de l'attaque. Il se répète presque toujours.

Et quand ça se répète, il n'y a plus 500-1000 comptes sur l'IP attaquée, mais une dizaine ou deux.

Le cercle des suspects se resserre. Ces 10 à 20 comptes sont à nouveau distribués à différentes adresses IP. Une fois de plus, les ingénieurs guettent une autre attaque. Encore et encore, ils diffusent les comptes restant suspects à différentes adresses IP et ainsi, par approximation progressive, ils calculent l'objet de l'attaque. Tous les autres comptes à ce stade reviennent à un fonctionnement normal sur la même adresse IP.

Comme vous le savez, ce n'est pas une procédure instantanée, cela prend du temps à mettre en œuvre.

Mythe numéro quatre :"Lorsqu'une attaque massive se produit, mon hébergeur n'a pas de plan d'action. Il attend juste les yeux fermés la fin du bombardement et répond à mes lettres par le même type de réponses.Ce n'est pas le cas : en cas d'attaque, l'hébergeur agit selon un plan afin de la localiser et d'en éliminer les conséquences au plus vite. Et le même type de lettres vous permet de transmettre l'essence de ce qui se passe et en même temps d'économiser les ressources nécessaires au traitement le plus rapide possible d'une situation d'urgence..

Y a t-il de la lumière au bout du tunnel?

Maintenant, nous voyons que l'activité DDoS est en constante augmentation. Commander une attaque est devenu très accessible et moche pas cher. Pour éviter les accusations de propagande, il n'y aura pas de liens de preuve. Mais croyez-nous sur parole, ça l'est.

Cinquième mythe : « Une attaque DDoS est un événement très coûteux, et seuls les gros bonnets commerciaux peuvent se permettre d'en commander une. En dernier recours, ce sont les machinations des services secrets ! En fait, de tels événements sont devenus extrêmement accessibles.

Par conséquent, il n'est pas nécessaire de s'attendre à ce que l'activité malveillante disparaisse d'elle-même. Au contraire, cela ne fera que s'intensifier. Il ne reste plus qu'à forger et à aiguiser les armes. Ce que nous faisons, améliorer l'infrastructure du réseau.

Le côté juridique de la question

C'est un aspect très impopulaire des discussions sur les attaques DDoS, car nous entendons rarement parler de cas de capture et de punition des instigateurs. Cependant, rappelez-vous : Une attaque DDoS est une infraction pénale. Dans la plupart des pays du monde, y compris la Russie.

Mythe numéro six : « Maintenant que j'en sais assez sur les DDoS, je vais commander des vacances pour un concurrent - Et je n'en tirerai rien !" Il n'est pas exclu que ce soit le cas. Et si c'est le cas, cela ne semblera pas grand-chose.

Historique des liens avec le système de paiement DDoS Assist
Dénouement passionnant

De manière générale, nous ne conseillons à personne de se livrer à la pratique vicieuse du DDoS, afin de ne pas encourir les foudres de la justice et de ne pas plier son propre karma. Et nous, en raison des spécificités de notre activité et d'un vif intérêt pour la recherche, continuons à étudier le problème, à monter la garde et à améliorer les structures défensives.

PS :nous n'avons pas assez de mots gentils pour exprimer toute notre gratitude, alors nous disons simplement"Merci!" à nos clients patients qui nous ont chaleureusement soutenus lors d'une journée difficile le 20 novembre 2013. Vous avez prononcé de nombreux mots d'encouragement à l'appui de notre

Combattre les attaques DDoS est non seulement un travail difficile, mais aussi passionnant. Il n'est pas surprenant que chaque administrateur système essaie d'abord d'organiser lui-même sa défense - d'autant plus que cela est encore possible.

Nous avons décidé de vous aider dans cette tâche difficile et de publier quelques conseils courts, triviaux et non universels pour protéger votre site des attaques. Ces recettes ne vous aideront pas à faire face à toutes les attaques, mais elles vous éviteront la plupart des dangers.

Les bons ingrédients

La dure vérité est que de nombreux sites peuvent être supprimés par quiconque utilise l'attaque Slowloris, qui tue Apache de manière stricte, ou en organisant une soi-disant inondation SYN à l'aide d'une batterie de serveurs virtuels créés en une minute dans le cloud Amazon EC2. Tous nos autres conseils pour vous protéger vous-même contre les attaques DDoS sont basés sur les conditions importantes suivantes.

1. Débarrassez-vous de Windows Server

La pratique suggère qu'un site fonctionnant sous Windows (2003 ou 2008 - peu importe) est condamné en cas de DDoS. La raison de l'échec réside dans la pile réseau de Windows : lorsqu'il y a beaucoup de connexions, le serveur commencera certainement à mal répondre. Nous ne savons pas pourquoi Windows Server fonctionne si mal dans de telles situations, mais nous l'avons rencontré plus d'une ou deux fois. Pour cette raison, cet article se concentrera sur les moyens de protection contre les attaques DDoS dans le cas où le serveur fonctionne sous Linux. Si vous êtes un heureux propriétaire d'un noyau relativement moderne (à partir de 2.6), alors les principaux outils seront les utilitaires iptables et ipset (pour ajouter rapidement des adresses IP), avec lesquels vous pourrez rapidement bannir les bots. Une autre clé du succès est une pile réseau bien préparée, dont nous parlerons également ensuite.

2. Se séparer d'Apache

La deuxième condition importante est le rejet d'Apache. Si vous avez Apache, placez au moins un proxy de mise en cache devant - nginx ou lighttpd. Apache "est extrêmement difficile à donner des fichiers, et, pire encore, il est fondamentalement (c'est-à-dire incorrigible) vulnérable à l'attaque Slowloris la plus dangereuse, qui vous permet d'inonder le serveur presque à partir d'un téléphone mobile. Pour lutter contre divers types de Slowloris, les utilisateurs d'Apache ont d'abord proposé un patch Anti-slowloris.diff, puis mod_noloris, puis mod_antiloris, mod_limitipconn, mod_reqtimeout... Mais si vous voulez bien dormir la nuit, il est plus simple de prendre un serveur HTTP immunisé contre Slowloris au niveau de l'architecture du code. Ainsi, toutes nos autres recettes sont basées sur l'hypothèse que nginx est utilisé sur le frontend.

Combattre les DDoS

Que faire en cas de DDoS ? La technique d'autodéfense traditionnelle consiste à lire le fichier journal du serveur HTTP, à écrire un modèle grep (qui intercepte les requêtes du bot) et à interdire toute personne qui en relève. Cette technique fonctionnera... si vous avez de la chance. Il existe deux types de botnets, tous deux dangereux, mais de manières différentes. L'un vient complètement sur le site instantanément, l'autre - progressivement. Le premier tue tout d'un coup, mais le tout apparaît dans les logs, et si vous les grépez et bannissez toutes les adresses IP, alors vous êtes le gagnant. Le deuxième botnet établit le site avec douceur et précaution, mais vous devrez probablement l'interdire pendant une journée. Il est important que tout administrateur comprenne : si vous envisagez de vous battre avec grep, vous devez être prêt à consacrer quelques jours à combattre l'attaque. Voici des conseils sur l'endroit où vous pouvez mettre des pailles à l'avance afin qu'il ne soit pas si douloureux de tomber.

3. Utilisez le module testcookie

Peut-être la recette la plus importante, la plus efficace et la plus opérationnelle de cet article. Si un DDoS arrive sur votre site, alors le module testcookie-nginx, développé par @kyprizel, peut devenir le moyen le plus efficace de riposter. L'idée est simple. Le plus souvent, les robots qui implémentent l'inondation HTTP sont plutôt stupides et n'ont pas de mécanismes de cookie et de redirection HTTP. Parfois, des robots plus avancés se présentent - ils peuvent utiliser des cookies et traiter les redirections, mais presque jamais un bot DoS ne porte un moteur JavaScript à part entière (bien que cela devienne de plus en plus courant). Testcookie-nginx agit comme un filtre rapide entre les bots et le backend lors d'une attaque DDoS L7, vous permettant de filtrer les demandes indésirables. Qu'est-ce qui est inclus dans ces chèques ? Le client sait-il comment effectuer la redirection HTTP, prend-il en charge JavaScript, est-ce le navigateur qu'il prétend être (parce que JavaScript est différent partout et si le client dit qu'il s'agit, disons, de Firefox, alors nous pouvons vérifier cela). La vérification est mise en œuvre à l'aide de cookies selon différentes méthodes :

"Set-Cookie" + redirection avec emplacement HTTP 301 ;
"Set-Cookie" + redirection à l'aide de la méta-actualisation HTML ;
modèle arbitraire et vous pouvez utiliser JavaScript.

Pour éviter l'analyse automatique, le cookie de validation peut être chiffré avec AES-128 puis déchiffré côté client JavaScript. La nouvelle version du module a la capacité de définir des cookies via Flash, ce qui vous permet également d'éliminer efficacement les bots (que Flash, en règle générale, ne prend pas en charge), mais bloque cependant l'accès à de nombreux utilisateurs légitimes (en fait , tous les appareils mobiles). Il est à noter qu'il est extrêmement facile de commencer à utiliser testcookie-nginx. Le développeur, en particulier, donne plusieurs exemples clairs d'utilisation (pour différents cas d'attaque) avec des exemples de configuration pour nginx.

Outre les avantages, les cookies de test présentent également des inconvénients :

coupe tous les bots, y compris Googlebot. Si vous envisagez de laisser le testcookie de manière permanente, assurez-vous de ne pas disparaître des résultats de recherche ;
crée des problèmes pour les utilisateurs avec les navigateurs Links, w3m et autres ;
ne sauve pas des bots équipés d'un moteur de navigation à part entière avec JavaScript.

En un mot, testcookie_module n'est pas universel. Mais à partir d'un certain nombre de choses, comme, par exemple, les kits d'outils primitifs en Java et C #, cela aide. Ainsi, vous coupez une partie de la menace.

4.Code 444

Les DDoSers ciblent souvent la partie la plus gourmande en ressources d'un site. Un exemple typique est une recherche qui effectue des requêtes de base de données complexes. Naturellement, les attaquants peuvent en profiter en chargeant simultanément plusieurs dizaines de milliers de requêtes sur le moteur de recherche. Ce que nous pouvons faire? Désactiver temporairement la recherche. Bien que les clients ne puissent pas rechercher les informations dont ils ont besoin avec les outils intégrés, l'ensemble du site principal restera opérationnel jusqu'à ce que vous trouviez la racine de tous les problèmes. Nginx prend en charge le code 444 non standard, qui vous permet simplement de fermer la connexion et de ne rien renvoyer en réponse :

Localisation/recherche ( retour 444; )

Ainsi, il est possible, par exemple, de mettre en place rapidement un filtrage par URL. Si vous êtes sûr que les requêtes de localisation/recherche ne proviennent que de bots (par exemple, votre confiance est basée sur le fait que votre site n'a pas du tout de section /recherche), vous pouvez installer le package ipset sur le serveur et bannissez les bots avec un simple script shell :

Ipset -N interdire iphash tail -f access.log | tout en lisant LINE ; faites echo "$LIGNE" | \ cut -d""" -f3 | cut -d" " -f2 | grep -q 444 && ipset -A ban "$(L%% *)" ; fait

Si le format des fichiers journaux n'est pas standard (non combiné) ou si vous devez interdire pour d'autres motifs que le statut de la réponse, vous devrez peut-être remplacer cut par une expression régulière.

5. Géo-banim

Le code de réponse non standard 444 peut également être utile pour interdire rapidement des clients basés sur la géo-référence. Vous pouvez restreindre sévèrement les pays individuels dans lesquels vous vous sentez mal à l'aise. Par exemple, il est peu probable qu'un magasin d'appareils photo en ligne de Rostov-on-Don compte de nombreux utilisateurs en Égypte. Ce n'est pas un très bon moyen (pour le dire franchement - dégoûtant), car les données GeoIP sont inexactes et les Rostovites s'envolent parfois pour l'Égypte en vacances. Mais si vous n'avez rien à perdre, suivez les instructions :

Connectez le module GeoIP à nginx (wiki.nginx.org/HttpGeoipModule).
Afficher les informations de géoréférencement dans le journal d'accès.
Ensuite, après avoir modifié le script shell ci-dessus, grep le journal d'accès de nginx et ajoutez les clients géographiquement expulsés à l'interdiction.

Si, par exemple, les bots venaient principalement de Chine, cela pourrait aider.

6. Réseau de neurones (PoC)

Enfin, vous pouvez répéter l'expérience de l'utilisateur @SaveTheRbtz, qui a pris le réseau de neurones PyBrain, y a inséré le journal et analysé les requêtes (habrahabr.ru/post/136237). La méthode fonctionne, bien qu'elle ne soit pas universelle :). Mais si vous connaissez vraiment l'intérieur de votre site - et vous, en tant qu'administrateur système, devriez - alors il y a de fortes chances que dans les situations les plus tragiques, un tel outil basé sur des réseaux de neurones, une formation et des informations recueillies à l'avance vous aidera. Dans ce cas, il est très utile d'avoir access.log avant le début du DDoS, puisqu'il décrit presque 100% des clients légitimes, et donc, un excellent jeu de données pour former un réseau de neurones.De plus, les bots ne sont pas toujours visibles dans le enregistrer.

Diagnostic du problème

Le site ne fonctionne pas - pourquoi ? Est-ce DDoSed ou est-ce un bug du moteur non remarqué par le programmeur ? Peu importe. Ne cherchez pas de réponse à cette question. Si vous pensez que votre site est susceptible d'être attaqué, contactez les sociétés qui assurent la protection contre les attaques - un certain nombre de services anti-DDoS proposent gratuitement le premier jour après la connexion - et ne perdez plus de temps à chercher les symptômes. Concentrez-vous sur le problème. Si le site fonctionne lentement ou ne s'ouvre pas du tout, alors quelque chose ne va pas avec ses performances, et - qu'il y ait ou non une attaque DDoS - vous, en tant que professionnel, êtes obligé de comprendre ce qui en est la cause. Nous avons été témoins à plusieurs reprises qu'une entreprise rencontrant des difficultés dans le fonctionnement de son site en raison d'une attaque DDoS, au lieu de rechercher des faiblesses dans le moteur du site, a tenté d'envoyer des applications au ministère de l'Intérieur afin de trouver et de punir les attaquants. Ne faites pas de telles erreurs. La recherche de cybercriminels est un processus long et difficile, compliqué par la structure même et les principes d'Internet, et le problème de fonctionnement du site doit être résolu rapidement. Demandez aux techniciens de découvrir ce qui cause la baisse des performances du site, et les avocats pourront rédiger la plainte.

7. Utiliser un profileur et un débogueur

Pour la plate-forme de création de sites Web la plus courante - PHP + MySQL - le goulot d'étranglement peut être trouvé à l'aide des outils suivants :

le profileur Xdebug montrera sur quels appels l'application passe le plus de temps ;
le débogueur APD intégré et la sortie de débogage dans le journal des erreurs vous aideront à déterminer exactement quel code effectue ces appels ;
dans la plupart des cas, le chien est enterré dans la complexité et la lourdeur des requêtes de base de données. La directive SQL d'explication intégrée au moteur de base de données vous aidera ici.

Si le site est couché sur le dos et que vous ne perdez rien, déconnectez-vous du réseau, regardez les journaux, essayez de les lire. Si ce n'est pas le cas, parcourez les pages, regardez la base.

L'exemple est pour PHP, mais l'idée est valable pour n'importe quelle plate-forme. Un développeur écrivant des produits logiciels dans n'importe quel langage de programmation doit être capable d'utiliser rapidement à la fois le débogueur et le profileur. Entraînez-vous à l'avance !

8. Analysez les erreurs

Analysez la quantité de trafic, le temps de réponse du serveur, le nombre d'erreurs. Voir les journaux pour cela. Dans nginx, le temps de réponse du serveur est enregistré dans le journal par deux variables : request_time et upload_response_time. Le premier est le temps d'exécution total de la requête, y compris les délais de réseau entre l'utilisateur et le serveur ; le second indique depuis combien de temps le backend (Apache, php_fpm, uwsgi...) a exécuté la requête. La valeur amont_response_time est extrêmement importante pour les sites avec beaucoup de contenu dynamique et une communication active entre le frontend et la base de données, et ne doit pas être négligée. Vous pouvez utiliser la configuration suivante comme format de journal :

Log_format xakep_log "$remote_addr - $remote_user [$time_local] " ""$request" $status $body_bytes_sent " ""$http_referer" "$http_user_agent" $request_time \ $upstream_response_time" ;

Il s'agit d'un format combiné avec des champs de synchronisation ajoutés.

9. Suivre les requêtes par seconde

Regardez aussi le nombre de requêtes par seconde. Dans le cas de nginx, vous pouvez estimer approximativement cette valeur avec la commande shell suivante (la variable ACCESS_LOG contient le chemin vers le journal des requêtes nginx au format combiné) :

Echo $(($(fgrep -c "$(env LC_ALL=C date [courriel protégé]$(($(date \ +%s)-60)) +%d/%b/%Y:%H:%M)" "$ACCESS_LOG")/60))

Par rapport au niveau normal pour cette heure de la journée, le nombre de requêtes par seconde peut à la fois diminuer et augmenter. Ils grandissent si un grand botnet arrive et chutent si le botnet entrant plante le site, le rendant complètement inaccessible aux utilisateurs légitimes, et en même temps, le botnet ne demande pas de statique, mais les utilisateurs légitimes le font. La baisse du nombre de requêtes est observée justement à cause de la statique. Mais, d'une manière ou d'une autre, nous parlons de changements importants dans les indicateurs. Lorsque cela se produit soudainement - pendant que vous essayez de résoudre le problème par vous-même et si vous ne le voyez pas tout de suite dans le journal, il est préférable de vérifier rapidement le moteur et de contacter des spécialistes en parallèle.

10. N'oubliez pas tcpdump

Beaucoup de gens oublient que tcpdump est un outil de diagnostic génial. Je vais donner quelques exemples. En décembre 2011, un bogue a été découvert dans le noyau Linux lors de l'ouverture d'une connexion TCP lorsque les indicateurs de segment TCP SYN et RST étaient définis. Le premier rapport de bogue a été envoyé par un administrateur système de Russie, dont la ressource a été attaquée par cette méthode - les attaquants ont découvert la vulnérabilité plus tôt que le monde entier. De toute évidence, un tel diagnostic l'a aidé. Un autre exemple : nginx a une propriété pas très agréable - il écrit dans le journal uniquement après que la requête a été complètement traitée. Il y a des situations où le site est en panne, rien ne fonctionne et il n'y a rien dans les journaux. En effet, toutes les requêtes qui chargent actuellement le serveur ne sont pas encore terminées. Tcpdump aidera ici aussi.

C'est tellement bon que j'ai conseillé aux gens de ne pas utiliser de protocoles binaires tant qu'ils ne sont pas sûrs que tout est en ordre, car les protocoles textuels sont faciles à déboguer avec tcpdump, mais pas les protocoles binaires. Cependant, le renifleur est un bon outil de diagnostic - comme moyen de maintenir la production" et il fait peur. Il peut facilement perdre plusieurs packages à la fois et gâcher votre historique d'utilisateur. Il est pratique de regarder sa sortie, et cela sera utile pour les diagnostics manuels et une interdiction, mais essayez de ne rien baser de critique dessus. Un autre outil favori pour les "demandes de réchauffement" - ngrep - essaie généralement par défaut de demander environ deux gigaoctets de mémoire non échangeable et commence alors seulement à réduire ses besoins.

11. Attaquer ou pas ?

Comment distinguer une attaque DDoS, par exemple, de l'effet d'une campagne publicitaire ? Cette question peut sembler ridicule, mais ce sujet n'en est pas moins complexe. Il y a des cas assez drôles. Pour certains bons gars, quand ils se sont tendus et ont complètement foiré la mise en cache, le site est tombé malade pendant quelques jours. Il s'est avéré que depuis plusieurs mois ce site avait été dataminé imperceptiblement par certains allemands, et avant d'optimiser la mise en cache de la page du site pour ces allemands, avec toutes les photos, le temps de chargement était assez long. Lorsque la page a commencé à sortir instantanément du cache, le bot, qui n'avait pas de délai d'attente, a également commencé à les collecter instantanément. C'était difficile. Le cas est particulièrement difficile car si vous avez vous-même modifié le paramètre (activé la mise en cache) et que le site a cessé de fonctionner après cela, alors qui, à votre avis et à celui du patron, est à blâmer ? Exactement. Si vous constatez une forte augmentation du nombre de requêtes, regardez, par exemple, dans Google Analytics, qui est venu sur quelles pages.

Réglage du serveur Web

Quels sont les autres points clés ? Bien sûr, vous pouvez définir le nginx "par défaut" et espérer que tout ira bien pour vous. Cependant, les bonnes choses ne se produisent pas toujours. Par conséquent, l'administrateur de n'importe quel serveur doit consacrer beaucoup de temps au réglage fin et au réglage de nginx.

12. Limiter les ressources (taille des tampons) dans nginx

Que faut-il retenir avant tout ? Chaque ressource a une limite. Tout d'abord, cela concerne la RAM. Par conséquent, les tailles des en-têtes et de tous les tampons utilisés doivent être limitées à des valeurs adéquates par client et par serveur dans son ensemble. Ils doivent être enregistrés dans la configuration nginx.

client_header_buffer_size_ _ Définit la taille de la mémoire tampon pour lire l'en-tête de la requête client. Si la chaîne de requête ou le champ d'en-tête de requête ne tient pas entièrement dans ce tampon, des tampons plus grands sont alloués, spécifiés par la directive large_client_header_buffers.
large_client_header_buffers Spécifie le nombre et la taille maximum de tampons pour lire l'en-tête de requête client volumineux.
client_body_buffer_size Définit la taille de la mémoire tampon pour lire le corps de la requête client. Si le corps de la requête est plus volumineux que le tampon spécifié, le corps entier de la requête ou seulement une partie de celui-ci est écrit dans un fichier temporaire.
client_max_body_size Définit la taille maximale autorisée pour un corps de requête client, spécifiée dans le champ Content-Length de l'en-tête de requête. Si la taille est supérieure à celle spécifiée, le client renvoie l'erreur 413 (Request Entity Too Large).

13. Configurer des délais d'attente dans nginx

Le temps est aussi une ressource. Par conséquent, la prochaine étape importante devrait être de définir tous les délais d'attente, ce qui, encore une fois, il est très important de s'enregistrer soigneusement dans les paramètres nginx.

reset_timedout_connection activé ; Aide à gérer les sockets bloqués dans la phase FIN-WAIT.
client_header_timeout Spécifie un délai d'expiration lors de la lecture d'un en-tête de requête client.
client_body_timeout Spécifie un délai d'expiration lors de la lecture du corps d'une demande client.
keepalive_timeout Définit le délai d'attente pendant lequel la connexion persistante avec le client ne sera pas fermée par le serveur. Beaucoup ont peur de fixer de grandes valeurs ici, mais nous ne sommes pas sûrs que cette peur soit justifiée. Vous pouvez éventuellement définir une valeur de délai d'attente dans l'en-tête HTTP Keep-Alive, mais Internet Explorer est connu pour ignorer cette valeur.
send_timeout Spécifie un délai d'attente lors de l'envoi d'une réponse au client. Si le client ne reçoit rien après ce délai, la connexion sera fermée.

Immédiatement la question est : quels paramètres de buffers et timeouts sont corrects ? Il n'y a pas de recette universelle ici, chaque situation a la sienne. Mais il existe une approche éprouvée. Il est nécessaire de définir les valeurs minimales auxquelles le site reste opérationnel (en temps de paix), c'est-à-dire que les pages sont renvoyées et les demandes sont traitées. Ceci est déterminé uniquement par des tests - à la fois à partir d'ordinateurs de bureau et d'appareils mobiles. L'algorithme pour trouver les valeurs de chaque paramètre (taille du buffer ou timeout) :

Nous fixons la valeur mathématique minimale du paramètre.
Nous commençons à exécuter des tests de site.
Si toutes les fonctionnalités du site fonctionnent sans problème, le paramètre est défini. Sinon, augmentez la valeur du paramètre et passez à l'étape 2.
Si la valeur du paramètre dépasse même la valeur par défaut, c'est un motif de discussion au sein de l'équipe de développement.

Dans certains cas, la révision de ces paramètres devrait conduire à un refactoring/redesign du site. Par exemple, si le site ne fonctionne pas sans demandes d'interrogation AJAX longues de trois minutes, vous n'avez pas besoin d'augmenter le délai d'attente, mais remplacez l'interrogation longue par autre chose - un botnet de 20 000 machines, suspendu aux demandes pendant trois minutes, tuera facilement un serveur bon marché moyen.

14. Limiter les connexions dans nginx (limit_conn et limit_req)

Nginx a également la capacité de limiter les connexions, les requêtes, etc. Si vous n'êtes pas sûr du comportement d'une certaine partie de votre site, vous devriez idéalement la tester, déterminer le nombre de requêtes qu'elle peut gérer et l'écrire dans votre configuration nginx. C'est une chose lorsque le site est en panne et que vous pouvez venir le récupérer. Et c'est une question complètement différente - quand il s'est couché à un point tel que le serveur est entré en échange. Dans ce cas, il est souvent plus facile de redémarrer que d'attendre son retour triomphal.

Supposons que le site comporte des sections avec les noms révélateurs /download et /search. Ce faisant, nous :

nous ne voulons pas que les robots (ou les personnes avec des gestionnaires de téléchargement récursifs trop zélés) remplissent notre table de connexion TCP avec leurs téléchargements ;
nous ne voulons pas que les robots (ou les robots d'indexation des moteurs de recherche) épuisent les ressources informatiques du SGBD avec de nombreuses requêtes de recherche.

À ces fins, la configuration suivante conviendra :

Http ( limit_conn_zone $binary_remote_addr zone=download_c:10m; limit_req_zone $binary_remote_addr zone=search_r:10m \ rate=1r/s; server ( location /download/ ( limit_conn download_c 1; # Autre emplacement de configuration ) location /search/ ( limit_req zone= search_r burst=5 ; # Autre emplacement de configuration ) ) )

Il est généralement judicieux de définir des limites limit_conn et limit_req pour les emplacements où se trouvent les scripts coûteux à exécuter (la recherche est indiquée dans l'exemple, et ce n'est pas un hasard). Les contraintes doivent être choisies en fonction des résultats des tests de charge et de régression, ainsi que du bon sens.

Notez le paramètre 10m dans l'exemple. Cela signifie qu'un dictionnaire avec un tampon de 10 mégaoctets et pas un mégaoctet de plus sera alloué pour le calcul de cette limite. Dans cette configuration, cela permettra de surveiller 320 000 sessions TCP. Pour optimiser l'utilisation de la mémoire, la variable $binary_remote_addr est utilisée comme clé dans le dictionnaire, qui contient l'adresse IP de l'utilisateur sous forme binaire et occupe moins de mémoire que la variable de chaîne normale $remote_addr. Il convient de noter que le deuxième paramètre de la directive limit_req_zone peut être non seulement IP, mais également toute autre variable nginx disponible dans ce contexte - par exemple, dans le cas où vous ne souhaitez pas fournir un mode plus indulgent pour le proxy, vous pouvez utiliser $binary_remote_addr$http_user_agent ou $binary_remote_addr$http_cookie_myc00kiez - mais de telles constructions doivent être utilisées avec prudence, car, contrairement à $binary_remote_addr 32 bits, ces variables peuvent être beaucoup plus longues et le "10m" que vous avez déclaré peut se terminer soudainement.

Tendances en matière de DDoS

La puissance des attaques réseau et de la couche transport ne cesse de croître. Le potentiel d'une attaque SYN flood moyenne a déjà atteint 10 millions de paquets par seconde.
Les attaques contre le DNS ont été particulièrement demandées ces derniers temps. L'inondation UDP avec des requêtes DNS valides avec des adresses IP sources usurpées est l'une des attaques les plus faciles à mettre en œuvre et difficiles à contrer. De nombreuses grandes entreprises russes (y compris des sociétés d'hébergement) ont récemment rencontré des problèmes à la suite d'attaques sur leurs serveurs DNS. Plus loin, plus ces attaques seront nombreuses et leur puissance augmentera.
À en juger par des signes extérieurs, la plupart des botnets ne sont pas contrôlés de manière centralisée, mais via un réseau peer-to-peer. Cela donne aux attaquants la possibilité de synchroniser les actions du botnet dans le temps - si les commandes de contrôle antérieures étaient distribuées sur un botnet de 5 000 machines en quelques dizaines de minutes, maintenant les secondes comptent, et votre site peut soudainement connaître une multiplication par cent instantanée du nombre de demandes.
La part des bots équipés d'un moteur de navigation à part entière avec JavaScript est encore faible, mais elle ne cesse de croître. Une telle attaque est plus difficile à repousser avec des moyens improvisés intégrés, les bricoleurs doivent donc surveiller cette tendance avec prudence.

préparation de l'OS

Outre le réglage fin de nginx, vous devez prendre soin des paramètres de la pile réseau du système. À tout le moins, incluez immédiatement net.ipv4.tcp_syncookies dans sysctl pour vous protéger immédiatement d'une petite attaque par inondation SYN.

15. Accordez le noyau

Attention aux réglages plus poussés de la partie réseau (kernel), toujours en termes de timeouts et de mémoire. Il y en a des plus importants et des moins importants. Tout d'abord, vous devez faire attention à:

net.ipv4.tcp_fin_timeout Le temps que le socket passera dans la phase TCP FIN-WAIT-2 (attente d'un segment FIN/ACK).
net.ipv4.tcp_(,r,w)mem Taille du tampon de réception du socket TCP. Trois valeurs : minimum, valeur par défaut et maximum.
net.core.(r,w)mem_max Idem pour les tampons non TCP.

Avec un lien de 100 Mbps, les valeurs par défaut sont encore en quelque sorte adaptées ; mais si vous avez au moins des gigabits par seconde disponibles, alors il vaut mieux utiliser quelque chose comme :

sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" sysctl -w net.ipv4.tcp_wmem="4096 65536 8388608" sysctl - w net.ipv4.tcp_fin_timeout=10

16. Révision /proc/sys/net/**

Il est idéal pour étudier tous les paramètres /proc/sys/net/**. Nous devons voir en quoi ils diffèrent de ceux par défaut et comprendre à quel point ils sont exposés de manière adéquate. Un développeur Linux (ou un administrateur système) qui comprend le fonctionnement du service Internet sous son contrôle et qui souhaite l'optimiser devrait lire avec intérêt la documentation de tous les paramètres de la pile réseau du noyau. Peut-être y trouvera-t-il des variables spécifiques à son site qui aideront non seulement à protéger le site contre les intrus, mais aussi à accélérer son travail.

N'ayez pas peur!

Les attaques DDoS réussies jour après jour éteignent le commerce électronique, secouent les médias, assomment les plus grands systèmes de paiement d'un seul coup. Des millions d'internautes perdent l'accès à des informations critiques. La menace est urgente, vous devez donc l'affronter entièrement armé. Faites vos devoirs, n'ayez pas peur et gardez la tête froide. Vous n'êtes pas le premier ni le dernier à faire face à une attaque DDoS sur votre site, et c'est à vous, guidé par vos connaissances et votre bon sens, de minimiser les conséquences de l'attaque.

On parle beaucoup d'attaques sur le site, de piratage, mais on n'a pas évoqué le sujet des DDOS. Aujourd'hui, nous corrigeons cette situation et vous proposons un aperçu complet des technologies d'organisation des attaques DDoS et des outils bien connus pour effectuer des attaques de pirates.

Vous pouvez afficher la liste des outils disponibles pour les attaques DDOS dans KALI en exécutant la commande :

kali > /usr/share/exploitdb/platforms/windows/dos

Cette commande affiche la base de données des exploits pour attaquer les systèmes Windows.

Pour afficher les outils d'attaque Linux DDoS disponibles, saisissez la commande :

/usr/share/exploitdb/platforms/Linux/dos.

2.LOIC

Le canon à ions en orbite basse (LOIC) Peut-être le programme DDOS le plus populaire. Il peut envoyer des requêtes en masse via les protocoles ICMP, UDP, bloquant ainsi le canal vers le serveur de la victime. L'attaque LOIC la plus notoire a été menée par Anonymous en 2009 contre PayPal, Visa, MasterCard en représailles à la coupure de WikiLeaks du système de collecte de fonds.

Les attaques organisées à l'aide de LOIC peuvent être exploitées en bloquant les paquets UDP et ICMP sur l'équipement réseau des fournisseurs Internet. Vous pouvez télécharger gratuitement le programme LOIC lui-même sur le site Web. Cet outil basé sur Windows est très facile à utiliser, il suffit de pointer vers les sites Web de la victime et d'appuyer sur un seul bouton.

2.HOIC

HOIC a été développé dans le cadre de l'opération Payback par Praetox par la même équipe qui a créé LOIC. La principale différence est que HOIC utilise le protocole HTTP et l'utilise pour envoyer un flux de requêtes HTTP GET et POST aléatoires. Il est capable d'attaquer simultanément 256 domaines. Vous pouvez le télécharger à partir de .

3.XOIC

XOIC est un autre outil DDOS très simple. L'utilisateur n'a qu'à définir l'adresse IP de la victime, sélectionner le protocole (HTTP, UDP, ICMP ou TCP) et appuyer sur la gâchette ! Vous pouvez le télécharger depuis

5. HULK

6. Inondateur UDP

UDP Flooder porte bien son nom - un outil conçu pour envoyer plusieurs paquets UDP à une cible. UDP Flooder est souvent utilisé dans les attaques DDOS sur les serveurs de jeux pour déconnecter les joueurs du serveur. Le programme est téléchargeable sur .

7. RUDY

8. Marteau de ToR

ToR's Hammer a été conçu pour fonctionner à travers réseau, afin d'obtenir un plus grand anonymat de l'attaquant. Le problème avec cet outil est que le réseau TOR est assez lent et réduit ainsi l'efficacité d'une attaque DDoS. Vous pouvez télécharger ce programme DDOS depuis Packet Storm ou .

9. Pyloris

Pyloris est un autre outil DDoS qui adopte une nouvelle approche. Il permet à un attaquant de créer sa propre requête HTTP unique. Le programme tentera alors de maintenir la connexion TCP ouverte avec de telles requêtes, réduisant ainsi le nombre de connexions disponibles sur le serveur. Lorsque la limite de connexion du serveur est atteinte, le serveur ne peut plus servir les connexions et le site devient indisponible. Cet outil est disponible en téléchargement gratuit sur le site.

10. Lame de commutation OWASP

Open Web Application Security Project (OWASP) et ProactiveRISK ont développé un outil Outil DoS Switchblade pour tester la résistance des applications WEB aux attaques DDoS, il dispose de trois modes de fonctionnement : 1. SSL Half-Open, 2. HTTP Post et 3. Slowloris. Vous pouvez le télécharger pour examen sur le site Web de l'OWASP.

11.DAVOSET

12. Outil DoS HTTP GoldenEye

13.THC-SSL-DOS

Cet outil DDOS (inclus avec Kali) diffère de la plupart des outils DDOS en ce qu'il n'utilise pas la bande passante Internet et peut être utilisé à partir d'un seul ordinateur. THC-SSL-DOS exploite la vulnérabilité du protocole SSL et est capable de "déposer" le serveur cible. À moins, bien sûr, que cette vulnérabilité existe sur celui-ci. Vous pouvez télécharger le programme à partir du site Web de THC ou utiliser KALI Linux où cet outil est déjà installé.

14. DDOSIM - Émulateur DDoS de couche 7

C'est là que se termine notre examen, mais à l'avenir, nous reviendrons sur le sujet des attaques DDoS sur les pages de notre blog.

Une attaque DDoS (Distributed Denial of Service attack) est un ensemble d'actions pouvant désactiver complètement ou partiellement une ressource Internet. Presque toutes les ressources Internet peuvent agir en tant que victimes, comme un site Web, un serveur de jeu ou une ressource gouvernementale. À l'heure actuelle, il est pratiquement impossible pour un pirate informatique d'organiser seul une attaque DDoS. Dans la plupart des cas, un attaquant utilise un réseau d'ordinateurs infectés par un virus. Le virus vous permet d'obtenir l'accès à distance nécessaire et suffisant à l'ordinateur infecté. Un réseau de tels ordinateurs est appelé un botnet. En règle générale, les botnets ont un serveur de coordination. Décidant de mettre en œuvre une attaque, l'attaquant envoie une commande au serveur de coordination, qui à son tour donne un signal à tout le monde pour commencer à exécuter des requêtes réseau malveillantes.

Raisons des attaques DDoS

Animosité personnelle

Cette raison est assez fréquente. Il y a quelque temps, le journaliste de recherche indépendant Brian Krebs a révélé les activités du plus grand service d'attaques DDoS personnalisées - vDOS. L'information a été présentée en détail, ce qui a provoqué l'arrestation des organisateurs de ce service. En réponse, les hackers ont organisé une attaque sur le blog du journaliste, dont la puissance a atteint 1 Tbps. Cette attaque est devenue la plus puissante au monde de toutes les années.

Divertissement

De nos jours, il est de plus en plus facile d'organiser soi-même une attaque DDoS primitive. Une telle attaque serait extrêmement imparfaite et non anonyme. Malheureusement, la plupart de ceux qui décident de se sentir comme un "hacker" ne sont conscients ni du premier ni du second. Cependant, de nombreux étudiants pratiquent souvent des attaques DDoS. L'issue de tels cas est très diverse.

Protestation politique (hacktivisme)

L'une des premières attaques sociales a été une attaque DDoS mise en œuvre en 1996 par le pirate Omega. Omega était membre de la coalition de hackers Cult of the Dead Crew (cDc). Le terme hacktivisme est devenu populaire dans les médias en raison de la fréquence croissante des cyberattaques à base sociale. Les représentants typiques des hacktivistes sont Anonymous et LulzSec.

Concurrence déloyale

De tels motifs se produisent souvent dans l'industrie des serveurs de jeux, mais dans l'industrie de la vente au détail, de tels cas sont assez courants. Un moyen assez efficace de concurrence déloyale qui peut détruire la réputation de la plateforme de trading si ses propriétaires ne se tournent pas vers des spécialistes pour obtenir de l'aide à temps. Un tel motif peut être distingué des autres comme étant le plus courant.

Extorsion ou chantage

Dans ce cas, l'agresseur exige une somme d'argent de la victime potentielle pour la non-réalisation de l'attaque. Ou de l'arrêter. Les grandes organisations sont souvent victimes de telles attaques, par exemple, en 2014, Tinkoff Bank et la ressource informatique Habrahabr, le plus grand tracker torrent Rutracker.org ont été attaqués (comment était-ce ?).

Conséquences des attaques DDoS

Les conséquences des attaques DDoS peuvent être très diverses, allant de l'arrêt de votre serveur par le centre de données à la perte totale de la réputation de la ressource et du flux client. De nombreuses organisations choisissent sans le savoir des fournisseurs de sécurité peu scrupuleux pour économiser de l'argent, ce qui n'apporte souvent aucun avantage. Pour éviter de tels problèmes, nous vous recommandons de contacter des professionnels de votre secteur.

Des attaques qui ont marqué l'histoire d'Internet

Les progrès technologiques avancent à pas de géant, et les attaquants, à leur tour, mettent tout en œuvre pour ne pas rester immobiles et mettre en œuvre des attaques de plus en plus complexes et puissantes. Nous avons compilé une brève description des cas les plus intéressants qui sont entrés dans l'histoire des attaques DDoS. Certains d'entre eux peuvent sembler ordinaires selon les normes d'aujourd'hui, mais à l'époque où ils ont eu lieu, il s'agissait d'attaques à très grande échelle.

Ping des morts. Une méthode d'attaque basée sur l'utilisation de la commande ping. Cette attaque a gagné en popularité dans les années 1990 en raison de l'imperfection des équipements réseau. L'essence de l'attaque consiste à envoyer une seule requête ping à l'hôte du réseau, tandis que le corps du paquet ne comprend pas les 64 octets de données standard, mais 65 535 octets. A la réception d'un tel paquet, l'équipement débordait la pile réseau et cela provoquait un déni de service.

Une attaque qui a affecté la stabilité d'Internet. En 2013, Spamhaus a été victime d'une attaque à 280 Gbps. La chose la plus intéressante est que pour l'attaque, les pirates ont utilisé des serveurs DNS d'Internet, qui à leur tour étaient très chargés avec un grand nombre de requêtes. Ce jour-là, des millions d'utilisateurs se sont plaints de la lenteur du chargement des pages en raison de la congestion du service.

Attaque record avec un trafic supérieur à 1 Tbit/s. En 2016, des pirates ont tenté de nous attaquer avec une attaque en rafale à 360 Mpps et 1 Tbps. Ce chiffre est devenu un record pour l'existence d'Internet. Mais même sous une telle attaque, nous avons résisté et la charge sur le réseau n'a que légèrement limité les ressources libres des équipements réseau.

Caractéristiques des attaques aujourd'hui

En excluant les pics d'attaques, nous pouvons dire que la puissance des attaques augmente chaque année de plus de 3 à 4 fois. La géographie des attaquants ne change que partiellement d'une année sur l'autre, car cela est dû au nombre maximal d'ordinateurs dans un pays donné. Comme le montre le rapport trimestriel 2016 préparé par nos experts, la Russie, les États-Unis et la Chine sont les pays qui battent des records en termes de nombre de bots.

Que sont les attaques DDoS ?

À l'heure actuelle, les types d'attaques peuvent être divisés en 3 classes :

Attaques par inondation de canaux

Ce type d'attaque comprend , et ;

Attaques qui exploitent les vulnérabilités de la pile de protocoles réseau

Les attaques les plus populaires et les plus intéressantes de ce type sont , / attack,

Pourquoi nous choisir? Nos équipements sont situés dans les principaux centres de données du monde et sont capables de repousser des attaques jusqu'à 300 Gbps ou 360 millions de paquets par seconde. Nous avons également un réseau de diffusion de contenu () et une équipe d'ingénieurs en service en cas d'attaque non standard ou de situations d'urgence. Par conséquent, étant sous notre protection, vous pouvez être sûr que votre ressource est disponible 24h/24 et 7j/7. Nous avons la confiance de : REG.RU, Arguments and Facts, WebMoney, la radio russe holding GPM et d'autres sociétés.

Vous ne pouvez mettre en place vous-même une protection que contre un petit nombre d'attaques, en utilisant l'analyse du trafic ou en définissant des règles de routage. Des moyens de se protéger contre certaines attaques sont donnés.