[Analyse technique] Approfondi et facile à comprendre : Introduction à l’attaque de l’attaque et de la défense en réseau

Les attaques DDoS (déni de service distribué) sont l’une des attaques les plus puissantes et difficiles à défendre, car le but principal des attaques DDoS est d’empêcher une cible désignée de fournir des services normaux ou même de disparaître d’Internet.

Les DDoS peuvent simplement être divisés en trois catégories selon la manière dont ils sont initiés.

La première catégorie gagne par la forceD’énormes paquets de données affluent de tous les coins d’Internet, bloquant l’entrée de l’IDC, rendant inutiles divers systèmes matériels puissants de défense et des processus d’urgence rapides et efficaces. Des exemples typiques de ce type d’attaque sont ICMP Flood et UDP Flood, qui sont aujourd’hui rares.

La deuxième catégorie l’emporte par l’intelligence, intelligent et imperceptible, envoyer un colis toutes les quelques minutes ou même ne nécessiter qu’un colis peut empêcher le serveur de configuration luxueux. Ce type d’attaque est principalement lancé en exploitant des vulnérabilités dans des protocoles ou des logiciels, telles que les attaques Slowloris, les collisions de hachage, etc., et nécessite des coïncidences environnementales spécifiques.

La troisième catégorie est un mélange des deux ci-dessusIl ne profite pas seulement des défauts du protocole et du système, mais il génère aussi une grande quantité de trafic, comme l’attaque SYN Flood et l’attaque DNS Query Flood, qui est la méthode d’attaque courante actuelle.

Cet article décrira ces méthodes d’attaque les plus courantes et représentatives une par une et présentera leurs options de défense.

Le SYN Flood est l’une des attaques DDoS les plus classiques sur Internet, apparue pour la première fois vers 1999, Yahoo étant alors la victime la plus célèbre. Les attaques SYN Flood exploitent des failles TCP triple de handshake qui peuvent rendre le serveur cible non réactif et difficile à localiser à un coût faible.

Le processus standard de poignée de main TCP à trois voies est le suivant :

• Le client envoie un paquet TCP contenant le drapeau SYN, SYN est synchronisé, et le paquet de synchronisation indique le port utilisé par le client ainsi que le numéro de série initial de la connexion TCP.
• Après avoir reçu le paquet SYN du client, le serveur renverra un paquet SYN+ACK (c’est-à-dire confirmation d’accusé de réception), indiquant que la demande du client est acceptée, et que le numéro de série initial TCP est automatiquement ajouté par 1.
• Le client renvoie également un message d’accusé de réception ACK au serveur, et le numéro de série TCP est également ajouté par 1.
  

Après ces trois étapes, la connexion TCP est établie. Afin d’assurer une transmission fiable, le protocole TCP a mis en place certains mécanismes de gestion des exceptions lors des trois poignées de main. À la troisième étape, si le serveur ne reçoit pas le dernier paquet d’accusé de réception ACK du client, le serveur reste en état SYN_RECV, ajoute l’adresse IP du client à la liste d’attente, puis renvoie le paquet SYN+ACK à la deuxième étape. Les reposts sont généralement effectués 3 à 5 fois, et la liste d’attente est interrogée une fois toutes les 30 secondes pour réessayer tous les clients. En revanche, après que le serveur ait envoyé le paquet SYN+ACK, il pré-alloue des ressources pour stocker les informations de la prochaine connexion TCP, qui sont conservées en attendant la nouvelle tentative. Plus important encore, si les ressources serveur sont limitées, l’état SYN_RECV qui peut être maintenu n’acceptera plus de nouveaux paquets SYN après avoir dépassé la limite, c’est-à-dire que de nouvelles connexions TCP seront rejetées.

SYN Flood utilise les paramètres du protocole TCP ci-dessus pour atteindre l’objectif de l’attaque. Les attaquants dissimulent un grand nombre d’adresses IP pour envoyer des paquets SYN au serveur, et comme les adresses IP falsifiées sont presque impossibles à exister, presque aucun appareil ne répondra au serveur. En conséquence, le serveur maintient une longue liste d’attente et tente sans cesse d’envoyer des paquets SYN+ACK, ce qui consomme beaucoup de ressources et ne peut pas être libéré. Plus important encore, la file d’attente SYN_RECV du serveur attaqué est remplie de paquets malveillants, les nouvelles requêtes SYN ne sont plus acceptées, et les utilisateurs légitimes ne peuvent pas effectuer trois poignées de main pour établir des connexions TCP. En d’autres termes, le serveur s’est vu refuser le service par SYN Flood.

Si SYN Flood vous intéresse, vous pouvez jeter un œil au http://www.icylife.net/yunshu/show.php?id=367, que j’ai écrit en 2006, et qui a ensuite apporté plusieurs modifications, corrigé des bugs, réduit son agressivité, et qui a été utilisé uniquement pour les tests.

En tant que service le plus basique et central d’Internet, le DNS est naturellement l’une des cibles importantes des attaques DDoS. Faire tomber un service DNS peut indirectement faire tomber l’ensemble de l’activité d’une entreprise, ou un service réseau dans une région. Il y a quelque temps, le populaire groupe de hackers anonymous a également annoncé qu’il attaquerait 13 serveurs DNS sur Internet mondial, mais finalement il n’a pas réussi.

Les attaques UDP sont la méthode la plus simple pour initier un trafic massif, et la falsification IP par source aléatoire est difficile à retracer. Cependant, le filtrage est plus simple car la plupart des IP ne fournissent pas de services UDP, donc vous pouvez simplement ignorer le trafic UDP. Par conséquent, les attaques de trafic purement UDP sont désormais relativement rares, remplacées par des attaques DNS Query Flood portées par le protocole UDP. En résumé, les attaques DDoS lancées plus le protocole est élevé, plus il est difficile de se défendre, car plus le protocole est élevé, plus il est lié aux affaires et plus le système de défense est complexe.

Le DNS Query Flood se produit lorsqu’un attaquant manipule un grand nombre de machines sockpuppet pour lancer un grand nombre de requêtes de noms de domaine vers la cible. Pour éviter le filtrage basé sur les ACL, il faut améliorer l’aléatoire des paquets. Une pratique courante consiste à forger aléatoirement l’adresse IP source, à forger aléatoirement le port source, ainsi que d’autres paramètres à la couche UDP. Au niveau du protocole DNS, l’ID de requête est falsifié aléatoirement avec le nom de domaine à résoudre. En plus d’empêcher le filtrage, la résolution aléatoire de noms de domaine falsifiés peut aussi réduire la probabilité d’atteindre le cache DNS et consommer autant de ressources CPU que possible sur le serveur DNS.

Concernant le code pour DNS Query Flood, j’ai écrit un code en juillet 2011 pour tester les performances des serveurs, et le lien est http://www.icylife.net/yunshu/show.php?id=832. De même, ce code est artificiellement moins agressif et n’est utilisé qu’à des fins de test.

Le SYN Flood et le DNS Query Flood décrits ci-dessus peuvent être efficacement défendus à ce stade, et le véritable casse-tête pour les grands fabricants et les entreprises Internet est constitué des attaques HTTP Flood. HTTP Flood est une attaque contre un service web sur un protocole de septième couche. Son grand dommage se manifeste principalement sous trois aspects : une initiation facile, un filtrage difficile et un impact de grande portée.

SYN Flood et DNS Query Flood exigent que les attaquants contrôlent un grand nombre de bots disposant de privilèges root. Il faut du temps et des efforts pour collecter un grand nombre de privilèges root, et pendant l’attaque, la machine marionnette est lente à se réapprovisionner en raison de la perte rapide de ressources par l’attaquant due au trafic anormal détecté par l’administrateur, ce qui entraîne une réduction significative de l’intensité de l’attaque et ne peut pas être soutenue longtemps. Les attaques HTTP Flood sont différentes : les attaquants n’ont pas besoin de contrôler un grand nombre de bots, mais utilisent plutôt des scanners de port pour trouver des proxies HTTP anonymes ou SOCKS sur Internet, par lesquels l’attaquant initie des requêtes HTTP vers la cible d’attaque. Les proxies anonymes sont une ressource relativement riche, et il n’est pas difficile d’en obtenir en quelques jours, donc les attaques sont faciles à initier et peuvent durer longtemps.

En revanche, les attaques en inondation HTTP sont lancées à la couche HTTP, qui imite vigoureusement le comportement des requêtes de pages web des utilisateurs normaux, ce qui est étroitement lié à l’activité du site web, rendant difficile pour les fournisseurs de sécurité de fournir une solution commune qui n’affecte pas l’expérience utilisateur. Des règles qui s’appliquent bien au même endroit, changer de situation peut entraîner un grand nombre d’homicides involontaires.

Enfin, les attaques HTTP flood peuvent provoquer de graves réactions en chaîne, provoquant non seulement une réponse lente directement de la part du front-end web attaqué, mais aussi attaquant indirectement la logique Java et autres services de base de données de la couche métier ainsi que les services de base de données back-end, augmentant leur pression et affectant même les serveurs de stockage de journaux.

Fait intéressant, HTTP Flood a aussi un surnom historique appelé attaque CC. CC est l’abréviation de Challenge Collapsar, un dispositif de protection DDoS d’une entreprise de sécurité bien connue en Chine. À en juger par la situation actuelle, non seulement Collapsar, mais tout l’équipement matériel de défense est encore mis en question, et le risque n’a pas été levé.

En ce qui concerne les attaques, la première réaction est un trafic massif et des paquets massifs. Mais il existe une attaque qui fait l’inverse, connue pour être lente, de sorte que certaines cibles d’attaque sont tuées sans savoir comment elles meurent, qui est l’attaque de connexion lente, la plus représentative étant Slowloris inventée par rsnake.

Le protocole HTTP stipule que les requêtes HTTP se terminent par \r\n\r\n, indiquant que le client a terminé l’envoi et que le serveur a commencé le traitement. Et si tu n’envoies jamais \r\n\r\n ? Slowloris utilise cela à son avantage dans les attaques DDoS. L’attaquant règle la connexion en mode Keep-Alive dans l’en-tête de requête HTTP, demande au serveur web de ne pas déconnecter la connexion TCP, puis envoie lentement un format clé-valeur au serveur toutes les quelques minutes, comme a :b\r\n, ce qui fait croire au serveur que l’en-tête HTTP n’a pas été reçu et attend. Si un attaquant utilise le multithreading ou une marionnette pour faire de même, le conteneur web du serveur sera rapidement submergé par l’attaquant et n’acceptera plus de nouvelles requêtes.

Bientôt, diverses variantes de Slowloris commencèrent à apparaître. Par exemple, la méthode POST envoie des données au serveur Web, remplit une grande longueur de contenu mais un octet lent par octet du contenu du contenu réelle du contenu réel, etc. Concernant l’attaque Slowloris, rsnake fournit aussi un code de test, voir http://ha.ckers.org/slowloris/slowloris.pl.

Ce qui précède introduit plusieurs méthodes d’attaque de base, dont chacune peut être utilisée pour attaquer le réseau, voire pour vaincre des sites géants tels qu’Alibaba, Baidu et Tencent. Mais ce n’est pas tout, différents niveaux d’attaquants peuvent lancer des attaques DDoS complètement différentes, et leur utilisation est la même chose.

Les attaquants avancés n’utilisent jamais un seul vecteur pour attaquer, mais les combinent de manière flexible selon l’environnement cible. Le SYN Flood ordinaire est facile à filtrer par des dispositifs de nettoyage du trafic via détection inverse, cookies SYN et autres moyens techniques, mais si les paquets SYN+ACK sont mélangés dans le SYN Flood, de sorte que chaque paquet SYN falsifié possède un paquet de confirmation client falsifié correspondant, le correspondant ici fait référence à l’adresse IP source, au port source, à l’IP de destination, au port de destination, à la taille de la fenêtre TCP, au TTL, etc., qui sont tous en accord avec les caractéristiques du même hôte et du même flux TCP. La pression sur la performance de la détection inverse et des cookies SYN des équipements de nettoyage à flux augmentera considérablement. En fait, les paquets de données SYN et divers autres bits de drapeau ont des effets d’attaque spéciaux, qui ne sont pas introduits ici. Il existe également des techniques uniques pour le DNS Query Flood.

Tout d’abord, le DNS peut être divisé en DNS ordinaire et DNS de domaine autorisé, attaquant le DNS ordinaire, l’adresse IP doit être falsifiée aléatoirement, et le serveur nécessite une résolution récursive ; Cependant, lors de l’attaque du DNS du domaine autorisé, l’adresse IP source falsifiée ne doit pas être purement aléatoire, mais doit être collectée à l’avance les adresses DNS des FAI du monde entier, afin d’obtenir l’effet d’attaque maximal, de sorte que le dispositif de nettoyage du trafic se retrouve dans la situation embarrassante d’ajouter ou de ne pas ajouter une liste noire IP. L’ajouter entraînera un grand nombre d’homicides involontaires, et si vous n’ajoutez pas de liste noire, chaque paquet doit être examiné à l’inverse-test, ce qui augmente la pression sur les performances.

D’un autre côté, comme mentionné précédemment, pour augmenter la pression liée au nettoyage de l’appareil, il est nécessaire de randomiser le nom de domaine demandé sans toucher au cache, mais il convient de noter que le nom de domaine à résoudre doit avoir une certaine régularité dans la falsification, comme la falsification d’une seule partie du nom de domaine et la solidification d’une pièce pour franchir la liste blanche définie par le dispositif de nettoyage. La raison est simple : les serveurs de Tencent ne peuvent résoudre que les noms de domaine de Tencent, et des noms de domaine complètement aléatoires peuvent être directement abandonnés et devoir être solidifiés. Mais s’il est complètement réparé, il est facile de le jeter directement, donc il faut le contrefaire.

Deuxièmement, les attaques contre le DNS ne devraient pas se concentrer uniquement sur les ports UDP, qui sont également des services standards selon le protocole DNS. En cas d’attaque, les attaques UDP et TCP peuvent être menées simultanément.

L’objectif de HTTP Flood est de percer le cache sur le frontend et d’atteindre directement le serveur Web lui-même via les paramètres de champ dans l’en-tête HTTP. De plus, HTTP Flood est également très critique pour la sélection des cibles, et les attaquants ordinaires choisiront des pages nécessitant de nombreuses requêtes de données comme la recherche comme cible d’attaque, ce qui est très correct et peut consommer autant de ressources que possible du serveur. Mais cette attaque est facile à identifier en nettoyant les équipements grâce à l’identification homme-machine, alors comment résoudre ce problème ? C’est très simple, essayez de choisir des pages auxquelles les utilisateurs habituels accèdent aussi via l’APPLICATION, en général, différentes API Web. Les utilisateurs normaux et le trafic malveillant proviennent de l’APP, et la différence entre l’homme et la machine est très faible, ce qui rend difficile de distinguer l’intégration de base.

Chaque connexion TCP existe du côté serveur et sur elle-même, et elle doit également consommer des ressources pour maintenir l’état TCP, donc la connexion ne peut pas être trop maintenue. Si cela peut être résolu, l’agressivité sera grandement renforcée, c’est-à-dire que Slowloris peut lancer des attaques sans état, capturer le numéro de série TCP et confirmer la maintenance des connexions TCP sur le client par sniffing, et le noyau système n’a pas à prêter attention aux différents changements d’état de TCP, et un notebook peut générer jusqu’à 65 535 connexions TCP.

Les descriptions précédentes sont toutes des améliorations techniques d’attaque. Du côté humain, il existe d’autres moyens. Si SYN Flood envoie un grand nombre de paquets et est accompagné de connexions lentes de Slowloris, combien de personnes découvriront le secret ? Même si le serveur tombe, seules des attaques SYN peuvent être détectées, cherchant à renforcer le nettoyage de la couche TCP et en ignorant le comportement de la couche application. Toutes sortes d’attaques peuvent fonctionner ensemble pour obtenir un effet maximal. Le choix de l’heure d’attaque est également un point clé, comme choisir le personnel de maintenance lors du déjeuner, quand le personnel de maintenance est bloqué sur la route après avoir fini de travailler, ou lorsqu’il n’y a pas de signal sur la carte réseau sans fil dans le métro, ou lorsque l’entreprise cible organise un événement de grande envergure et que le trafic augmente.

C’est une attaque pure, donc aucun code n’est fourni ni explication approfondie.

Les méthodes d’attaque précédentes nécessitent plus ou moins certains bots, même HTTP Flood nécessite de rechercher un grand nombre de proxies anonymes. En cas d’attaque, il suffit d’émettre quelques instructions, et la machine s’ouvre automatiquement pour l’exécuter, ce qui est la solution parfaite. Cette attaque est déjà apparue, et cela vient des réseaux P2P.

Comme nous le savons tous, les utilisateurs P2P et le trafic sur Internet sont extrêmement importants. Si elles vont toutes à un endroit désigné pour télécharger des données et connecter des milliers d’adresses IP réelles, aucun appareil ne pourra les supporter. Prenez BT Download comme exemple : falsifier des torrents de vidéos populaires et les publier sur les moteurs de recherche suffit à tromper de nombreux utilisateurs et trafic, mais ce n’est qu’une attaque basique.

Les attaques P2P avancées sont des usurpations directes de serveurs de gestion de ressources. Par exemple, le client Thunder téléversera les ressources qu’il trouve sur le serveur de gestion des ressources, puis les transmettra à d’autres utilisateurs qui doivent télécharger les mêmes ressources, afin qu’un lien soit publié. Par l’inversion des protocoles, les attaquants forgent une grande quantité d’informations populaires sur les ressources et les distribuent via le centre de gestion des ressources, qui peuvent être instantanément diffusées sur l’ensemble du réseau P2P. Ce qui est encore plus terrifiant, c’est que cette attaque ne peut pas être arrêtée, même par l’attaquant lui-même, et l’attaque continue jusqu’à ce que l’officiel P2P trouve le problème, mette à jour le serveur et que l’utilisateur du téléchargement redémarre le logiciel téléchargé.

C’est tout ce qu’il y a dans l’introduction aux attaques DDoS, et je ne veux pas aller plus loin — il suffit de comprendre que beaucoup de défense suffisent.

En général, les attaques DDoS peuvent être habiles et gracieuses. La beauté de l’application réside dans l’unité de l’esprit.