"Le gars qui a créé notre site Web a déjà mis en place une protection DDoS."
« Nous disposons d'une protection DDoS, pourquoi le site est-il tombé en panne ? »
« Combien de milliers Qrator veut-il ? »
Afin de répondre correctement à ces questions du client/patron, il serait bien de savoir ce qui se cache derrière le nom « protection DDoS ». Choisir les services de sécurité, c'est plus choisir un médicament chez un médecin que choisir une table chez IKEA.
Je supporte des sites Web depuis 11 ans, j'ai survécu à des centaines d'attaques contre les services que je prends en charge, et maintenant je vais vous parler un peu du fonctionnement interne de la protection.
Attaques régulières. 350 52 demandes au total, XNUMX XNUMX demandes légitimes
Les premières attaques sont apparues presque simultanément avec Internet. Le phénomène DDoS s'est répandu depuis la fin des années 2000 (consultez ).
Depuis 2015-2016 environ, presque tous les hébergeurs sont protégés contre les attaques DDoS, tout comme les sites les plus importants dans les zones concurrentielles (faites le whois par IP des sites eldorado.ru, leroymerlin.ru, tilda.ws, vous verrez les réseaux des opérateurs de protection).
S'il y a 10 à 20 ans, la plupart des attaques pouvaient être repoussées sur le serveur lui-même (évaluez les recommandations de l'administrateur système de Lenta.ru, Maxim Moshkov, dans les années 90 : ), mais les tâches de protection sont désormais devenues plus difficiles.
Types d'attaques DDoS du point de vue du choix d'un opérateur de protection
Attaques au niveau L3/L4 (selon le modèle OSI)
— Inondation UDP d'un botnet (de nombreuses requêtes sont envoyées directement des appareils infectés au service attaqué, les serveurs sont bloqués avec le canal) ;
— Amplification DNS/NTP/etc (de nombreuses requêtes sont envoyées depuis des appareils infectés vers des DNS/NTP/etc vulnérables, l'adresse de l'expéditeur est falsifiée, un nuage de paquets répondant aux requêtes inonde le canal de la personne attaquée ; c'est ainsi que le plus des attaques massives sont menées sur l'Internet moderne) ;
— Flood SYN/ACK (de nombreuses requêtes d'établissement de connexion sont envoyées aux serveurs attaqués, la file d'attente de connexion déborde) ;
— attaques avec fragmentation de paquets, ping de mort, ping Flood (Google s'il vous plaît) ;
- et ainsi de suite.
Ces attaques visent à « obstruer » le canal du serveur ou à « tuer » sa capacité à accepter du nouveau trafic.
Bien que l’inondation et l’amplification SYN/ACK soient très différentes, de nombreuses entreprises les combattent tout aussi bien. Des problèmes surviennent avec les attaques du groupe suivant.
Attaques sur L7 (couche application)
— HTTP Flood (si un site Web ou une API http est attaqué) ;
— une attaque sur les zones vulnérables du site (celles qui ne disposent pas de cache, qui chargent très fortement le site, etc.).
Le but est de faire « travailler dur » le serveur, de traiter beaucoup de « requêtes apparemment réelles » et de se retrouver sans ressources pour des requêtes réelles.
Bien qu’il existe d’autres attaques, celles-ci sont les plus courantes.
Les attaques sérieuses au niveau L7 sont créées d'une manière unique pour chaque projet attaqué.
Pourquoi 2 groupes ?
Parce que nombreux sont ceux qui savent bien repousser les attaques au niveau L3 / L4, mais soit n'assument pas du tout la protection au niveau de l'application (L7), soit sont encore plus faibles que les alternatives pour y faire face.
Qui fait quoi sur le marché de la protection DDoS ?
(mon avis personnel)
Protection au niveau L3/L4
Pour repousser les attaques par amplification (« blocage » du canal du serveur), il existe des canaux suffisamment larges (de nombreux services de protection se connectent à la plupart des grands fournisseurs de backbone en Russie et disposent de canaux d'une capacité théorique supérieure à 1 Tbit). N'oubliez pas que les très rares attaques d'amplification durent plus d'une heure. Si vous êtes Spamhaus et que tout le monde ne vous aime pas, oui, ils peuvent essayer de fermer vos chaînes pendant plusieurs jours, même au risque de la survie du botnet mondial utilisé. Si vous n'avez qu'une boutique en ligne, même s'il s'agit de mvideo.ru, vous ne verrez pas 1 Tbit d'ici quelques jours très bientôt (j'espère).
Pour repousser les attaques avec inondation SYN/ACK, fragmentation de paquets, etc., vous avez besoin d'équipements ou de systèmes logiciels pour détecter et arrêter de telles attaques.
De nombreuses personnes produisent de tels équipements (Arbor, il existe des solutions de Cisco, Huawei, des implémentations logicielles de Wanguard, etc.), de nombreux opérateurs de backbone l'ont déjà installé et vendent des services de protection DDoS (je connais les installations de Rostelecom, Megafon, TTK, MTS , en fait, tous les principaux fournisseurs font de même avec les hébergeurs avec leur propre protection (à la OVH.com, Hetzner.de, j'ai moi-même rencontré une protection sur ihor.ru). Certaines entreprises développent leurs propres solutions logicielles (des technologies comme DPDK permettent de traiter des dizaines de gigabits de trafic sur une machine physique x86).
Parmi les acteurs connus, tout le monde peut lutter plus ou moins efficacement contre les DDoS L3/L4. Maintenant, je ne dirai pas qui a la plus grande capacité de canal maximale (il s'agit d'informations privilégiées), mais ce n'est généralement pas si important, et la seule différence est la rapidité avec laquelle la protection est déclenchée (instantanément ou après quelques minutes d'arrêt du projet, comme chez Hetzner).
La question est de savoir dans quelle mesure cela est réalisé : une attaque par amplification peut être repoussée en bloquant le trafic en provenance des pays où le trafic nuisible est le plus important, ou seul le trafic réellement inutile peut être rejeté.
Mais en même temps, d'après mon expérience, tous les acteurs sérieux du marché y font face sans problème : Qrator, DDoS-Guard, Kaspersky, G-Core Labs (anciennement SkyParkCDN), ServicePipe, Stormwall, Voxility, etc.
Je n'ai pas rencontré de protection d'opérateurs tels que Rostelecom, Megafon, TTK, Beeline ; selon les avis de collègues, ils fournissent assez bien ces services, mais jusqu'à présent, le manque d'expérience affecte périodiquement : il faut parfois peaufiner quelque chose via le support de l’opérateur de protection.
Certains opérateurs disposent d'un service distinct de « protection contre les attaques au niveau L3/L4 », ou « protection des canaux », qui coûte beaucoup moins cher que la protection à tous les niveaux.
Pourquoi le fournisseur de backbone ne repousse-t-il pas les attaques de plusieurs centaines de Gbits, puisqu’il ne dispose pas de ses propres canaux ?L’opérateur de protection peut se connecter à n’importe lequel des principaux fournisseurs et repousser les attaques « à ses frais ». Vous devrez payer pour la chaîne, mais toutes ces centaines de Gbits ne seront pas toujours utilisées ; il existe des options pour réduire considérablement le coût des chaînes dans ce cas, le système reste donc viable.
Ce sont les rapports que je recevais régulièrement d’une protection de niveau supérieur L3/L4 tout en prenant en charge les systèmes du fournisseur d’hébergement.
Protection au niveau L7 (niveau application)
Les attaques au niveau L7 (niveau application) sont capables de repousser les unités de manière cohérente et efficace.
J'ai beaucoup d'expérience réelle avec
— Qrator.net ;
— DDoS-Guard;
- Laboratoires G-Core ;
— Kaspersky.
Ils facturent pour chaque mégabit de trafic pur, un mégabit coûte environ plusieurs milliers de roubles. Si vous avez au moins 100 Mbps de trafic pur, oh. La protection coûtera très cher. Je peux vous expliquer dans les articles suivants comment concevoir des applications afin d'économiser beaucoup sur la capacité des canaux de sécurité.
Le véritable « roi de la colline » est Qrator.net, les autres sont à la traîne. Qrator est jusqu'à présent le seul d'après mon expérience à donner un pourcentage de faux positifs proche de zéro, mais en même temps, ils sont plusieurs fois plus chers que les autres acteurs du marché.
D'autres opérateurs offrent également une protection stable et de haute qualité. De nombreux services que nous soutenons (y compris des très connus dans le pays !) sont protégés contre DDoS-Guard, G-Core Labs, et sont assez satisfaits des résultats obtenus.
Attaques repoussées par Qrator
J'ai également de l'expérience avec de petits opérateurs de sécurité comme cloud-shield.ru, ddosa.net, des milliers d'entre eux. Je ne le recommanderai certainement pas, parce que... Je n'ai pas beaucoup d'expérience, mais je vais vous parler des principes de leur travail. Leur coût de protection est souvent inférieur de 1 à 2 ordres de grandeur à celui des principaux acteurs. En règle générale, ils achètent un service de protection partielle (L3/L4) auprès d'un des plus grands acteurs + assurent leur propre protection contre les attaques de niveaux supérieurs. Cela peut être assez efficace + vous pouvez obtenir un bon service pour moins d'argent, mais ce sont encore de petites entreprises avec un petit effectif, gardez cela à l'esprit.
Quelle est la difficulté de repousser les attaques au niveau L7 ?
Toutes les applications sont uniques et vous devez autoriser le trafic qui leur est utile et bloquer celui qui leur est nuisible. Il n’est pas toujours possible d’éliminer sans équivoque les robots, vous devez donc utiliser de très nombreux degrés de purification du trafic.
Il était une fois le module nginx-testcookie qui suffisait (), et c’est encore suffisant pour repousser un grand nombre d’attaques. Lorsque je travaillais dans le secteur de l'hébergement, la protection L7 était basée sur nginx-testcookie.
Malheureusement, les attaques sont devenues plus difficiles. testcookie utilise des contrôles de robots basés sur JS, et de nombreux robots modernes peuvent les réussir.
Les botnets d’attaque sont également uniques et les caractéristiques de chaque grand botnet doivent être prises en compte.
Amplification, inondation directe à partir d'un botnet, filtrage du trafic de différents pays (filtrage différent pour différents pays), inondation SYN/ACK, fragmentation de paquets, ICMP, inondation http, tandis qu'au niveau application/http, vous pouvez proposer un nombre illimité de différentes attaques.
Au total, au niveau de la protection des canaux, des équipements spécialisés pour évacuer le trafic, des logiciels spéciaux, des paramètres de filtrage supplémentaires pour chaque client, il peut y avoir des dizaines et des centaines de niveaux de filtrage.
Pour gérer correctement cela et régler correctement les paramètres de filtrage pour les différents utilisateurs, vous avez besoin de beaucoup d'expérience et de personnel qualifié. Même un grand opérateur qui a décidé de fournir des services de protection ne peut pas « jeter bêtement de l'argent sur le problème » : il devra acquérir de l'expérience à partir de sites mensongers et de faux positifs sur du trafic légitime.
Il n’existe pas de bouton « repousser les DDoS » pour l’opérateur de sécurité ; il existe un grand nombre d’outils, et il faut savoir les utiliser.
Et encore un exemple bonus.
Un serveur non protégé a été bloqué par l'hébergeur lors d'une attaque d'une capacité de 600 Mbit
(« La perte » de trafic n'est pas perceptible, car un seul site a été attaqué, il a été temporairement supprimé du serveur et le blocage a été levé en une heure).
Le même serveur est protégé. Les assaillants se sont « rendus » après une journée d’attaques repoussées. L’attaque elle-même n’a pas été la plus forte.
L'attaque et la défense de L3/L4 sont plus triviales ; elles dépendent principalement de l'épaisseur des canaux, des algorithmes de détection et de filtrage des attaques.
Les attaques L7 sont plus complexes et originales ; elles dépendent de l'application attaquée, des capacités et de l'imagination des attaquants. La protection contre eux nécessite beaucoup de connaissances et d'expérience, et le résultat peut ne pas être immédiat ni à cent pour cent. Jusqu'à ce que Google propose un autre réseau neuronal pour la protection.
Source: habr.com