Les DDoS frappent comme des chiens enrag\u00e9s, mais les attaques les plus insidieuses sont souvent les attaques lentes qui vous \u00e9crasent lentement - ce n'est pas aussi spectaculaire qu'une attaque par inondation, mais plut\u00f4t comme faire bouillir une grenouille dans de l'eau ti\u00e8de, et le temps que vous vous en rendiez compte, les serveurs ont \u00e9t\u00e9 paralys\u00e9s depuis longtemps.<\/p>\n
L'ann\u00e9e derni\u00e8re, j'ai aid\u00e9 une plateforme d'\u00e9checs \u00e0 effectuer une intervention d'urgence, son fonctionnement et sa maintenance ont d'abord \u00e9t\u00e9 confiants : \u201cla bande passante est suffisante, les r\u00e8gles du pare-feu sont empil\u00e9es\u201d. Le r\u00e9sultat d'un coup d'\u0153il sur le moniteur, le CPU n'a pas explos\u00e9, le trafic n'a pas explos\u00e9, mais l'utilisateur est coinc\u00e9 en train de jurer. Finalement, l'analyse des paquets a permis de constater qu'il y a une IP qui envoie lentement, toutes les 30 secondes, un en-t\u00eate de paquet HTTP, la connexion est pinc\u00e9e dans les mains du mort qui ne la l\u00e2che pas, un serveur par des centaines de connexions de ce type pour \u00e9puiser les ressources.<\/p>\n
L'aspect le plus d\u00e9sagr\u00e9able de cette attaque HTTP lente est qu'elle semble trop \u201cnormale\u201d. Un pare-feu traditionnel pourrait la laisser passer, car chaque requ\u00eate est conforme \u00e0 la sp\u00e9cification du protocole. Mais l'attaquant s'appuie sur cette \u201clenteur\u201d pour \u00e9puiser votre pool de connexions, votre pool de threads et, en fin de compte, pour emp\u00eacher les utilisateurs normaux d'acc\u00e9der au r\u00e9seau.<\/p>\n
Ne comptez pas sur un pare-feu mat\u00e9riel pour r\u00e9soudre ce probl\u00e8me.<\/strong>. J'ai en fait test\u00e9 qu'une certaine marque de pare-feu mat\u00e9riel de plusieurs millions de dollars avec une politique par d\u00e9faut ne r\u00e9agit pratiquement pas aux attaques Slowloris - parce qu'il d\u00e9tecte les pics de trafic, et non les dur\u00e9es de connexion. Ce qui peut vraiment supporter la charge, c'est aussi un CDN \u00e0 haute s\u00e9curit\u00e9 combin\u00e9 \u00e0 un contr\u00f4le pr\u00e9cis des d\u00e9lais et \u00e0 une analyse comportementale.<\/p>\n Commen\u00e7ons par le r\u00e9glage du d\u00e9lai d'attente des requ\u00eates. Il ne s'agit pas simplement de modifier `keepalive_timeout` dans Nginx. Vous devez le d\u00e9composer en plusieurs dimensions bas\u00e9es sur les caract\u00e9ristiques de l'entreprise : d\u00e9lai d'\u00e9tablissement de la connexion, d\u00e9lai de r\u00e9ception de l'en-t\u00eate, d\u00e9lai de transmission du corps du message, d\u00e9lai d'inactivit\u00e9 de la connexion. Par exemple, pour une entreprise d'\u00e9checs, une requ\u00eate HTTP doit \u00eatre compl\u00e9t\u00e9e dans les 2 secondes, une connexion longue WS peut maintenir un niveau de minute, mais il doit y avoir un m\u00e9canisme de battement de c\u0153ur sous le capot.<\/p>\n Si l'on prend l'exemple de la configuration de Nginx, j'ai l'habitude de la superposer comme suit :<\/p>\n Mais cela ne suffit pas. Certains attaquants envoient intentionnellement le corps \u00e0 un rythme lent, par exemple 1 octet par seconde. Cette fois, vous devez mettre en place une politique globale de contr\u00f4le de flux au niveau du n\u0153ud p\u00e9riph\u00e9rique du CDN. Comme CDN5, cette maison a fait la r\u00e9partition : 10 secondes n'ont pas pass\u00e9 la taille de corps par d\u00e9faut (comme 1KB) directement d\u00e9connect\u00e9, et ne prend pas le pool de connexion de back-end.<\/p>\n L'interception des comportements anormaux est encore plus difficile. Il est difficile de se d\u00e9fendre contre les attaques lentes parce qu'une seule demande semble inoffensive. Mais si l'on examine plusieurs requ\u00eates dans leur contexte, le diable se cache dans les d\u00e9tails.<\/p>\n Je d\u00e9tecte g\u00e9n\u00e9ralement les anomalies en trois dimensions :vitesse de connexion<\/strong>(Les utilisateurs normaux ne cr\u00e9ent pas de nouvelles connexions sans envoyer de demandes),taux de transmission<\/strong>(Les utilisateurs normaux ne mettent pas 10 minutes pour passer un paquet de connexion),Distribution de la dur\u00e9e de survie<\/strong>(Alors que les sessions d'utilisateurs d'\u00e9checs fluctuent g\u00e9n\u00e9ralement, les connexions d'attaques ont tendance \u00e0 \u00eatre exceptionnellement stables).<\/p>\n L'\u00e9quipe d'algorithmes de CDN07 a mis au point un ensemble de biblioth\u00e8ques de fonctions sp\u00e9cialement con\u00e7ues pour d\u00e9tecter ce type de comportement \u201cfaussement lent\u201d. Par exemple, une IP est d\u00e9tect\u00e9e comme \u00e9tablissant une connexion toutes les 10 secondes, mais chaque connexion n'envoie que 5 octets et reste ensuite silencieuse, plus de 10 fois cons\u00e9cutives directement dans le processus de contestation. Le taux d'\u00e9limination mesur\u00e9 est inf\u00e9rieur \u00e0 0,1%, mais peut intercepter 99% variantes d'attaques lentes.<\/p>\n Une autre astuce consiste \u00e0 effectuer un contr\u00f4le de l'int\u00e9grit\u00e9 du protocole. De nombreux outils d'attaque lente ont en fait des impl\u00e9mentations de protocole d\u00e9fectueuses (par exemple, certains champs d'en-t\u00eate manquent d\u00e9lib\u00e9r\u00e9ment). Nous pouvons pr\u00e9construire la logique de la somme de contr\u00f4le sur le CDN :<\/p>\n Bien entendu, la strat\u00e9gie d\u00e9crite ci-dessus doit \u00eatre appliqu\u00e9e avec souplesse. Par exemple, les interfaces API et les connexions longues WS doivent \u00eatre trait\u00e9es diff\u00e9remment. Les n\u0153uds sp\u00e9cifiques aux \u00e9checs de 08Host proc\u00e8dent \u00e0 une identification intelligente : ils utilisent un timeout strict (10 secondes) pour le chemin \/api\/ et autorisent les connexions longues pour le chemin \/ws\/, mais exigent que l'intervalle entre les paquets heartbeat ne soit pas sup\u00e9rieur \u00e0 25 secondes.<\/p>\n Ne vous laissez jamais emporter par une solution unique<\/strong>. Un client a achet\u00e9 un CDN aupr\u00e8s d'un grand fabricant et pensait que tout irait bien, mais il a \u00e9t\u00e9 p\u00e9n\u00e9tr\u00e9 par Slowloris. Plus tard, il s'est rendu compte que le d\u00e9lai d'attente par d\u00e9faut du CDN \u00e9tait trop court (120 secondes de connexion inactive \u00e9taient autoris\u00e9es). Plus tard, nous avons travaill\u00e9 avec la politique personnalis\u00e9e de CDN5 pour r\u00e9duire le seuil de temporisation \u00e0 15 secondes, et en m\u00eame temps activ\u00e9 son \u201cSlow Connection Learning Mode\u201d - lib\u00e9rant d'abord 24 heures pour \u00e9tablir une base de r\u00e9f\u00e9rence, puis interceptant automatiquement les IP qui s'\u00e9cartent du comportement de base.<\/p>\n Enfin, j'aimerais mentionner un pi\u00e8ge : des param\u00e8tres de temporisation trop agressifs peuvent \u00e0 tort nuire aux utilisateurs de r\u00e9seaux lents. Mon exp\u00e9rience est de combiner la politique g\u00e9ographique, par exemple, pour les utilisateurs nationaux avec un d\u00e9lai uniforme de 10 secondes, pour les utilisateurs d'Asie du Sud-Est d'assouplir \u00e0 20 secondes, en m\u00eame temps avec l'algorithme du centre de gravit\u00e9 pour d\u00e9terminer - si l'IP de l'utilisateur est tr\u00e8s loin de la distance physique mais la latence est tr\u00e8s faible, la probabilit\u00e9 qu'il s'agit d'une falsification du trafic transfrontalier.<\/p>\n Dans la pratique, j'aime aussi enterrer quelques enjeux cach\u00e9s. Par exemple, dans la configuration du CDN, j'ai m\u00e9lang\u00e9 quelques domaines froids comme app\u00e2t, ces domaines ne seront scann\u00e9s que par les attaquants, les utilisateurs normaux ne les visiteront jamais. Une fois que ces domaines sont identifi\u00e9s comme ayant des tentatives de connexion lentes, bloquer directement le segment ASN entier. Cette astuce m'a permis d'arr\u00eater plusieurs vagues d'attaques cibl\u00e9es.<\/p>\n L'avantage du CDN est qu'il peut voir le trafic global, combin\u00e9 avec le contr\u00f4le des d\u00e9lais et l'analyse comportementale, et peut souvent \u00eatre trouv\u00e9 dans l'attaque pr\u00e9coce de la jeune pousse. Mais n'oubliez pas qu'il n'y a pas de solution unique, les r\u00e8gles efficaces d'aujourd'hui peuvent \u00eatre contourn\u00e9es le mois prochain, alors assurez-vous de laisser un canal pour la recherche manuelle et le jugement - le jugement de la machine 70% m\u00e9fiante sur la pouss\u00e9e d'alarme, de sorte que les gens prennent la d\u00e9cision finale.<\/p>\n Si vous utilisez CDN07 ou 08Host, n'oubliez pas de creuser dans le backend pour trouver leur module de protection contre les attaques lentes (certains sont cach\u00e9s dans \u201cAdvanced Security\u201d ou \u201cCustom Rules\u201d). La plupart des clients ne savent m\u00eame pas que ces fonctionnalit\u00e9s existent, et c'est un gaspillage de la prime annuelle. Apr\u00e8s tout, de nos jours, m\u00eame les CDN doivent \u201cpr\u00e9venir les co\u00e9quipiers\u201d - il ne s'agit pas de pr\u00e9venir les attaquants, mais de pr\u00e9venir votre propre utilisation.<\/p>","protected":false},"excerpt":{"rendered":" Les DDoS frappent comme des chiens enrag\u00e9s, mais les plus insidieux sont souvent ces attaques lentes qui vous broient lentement jusqu'\u00e0 la mort - ce n'est pas comme un d\u00e9luge, comme un bombardement, mais comme une grenouille bouillie \u00e0 l'eau ti\u00e8de, et attendez de vous en rendre compte, le serveur est paralys\u00e9 depuis longtemps. L'ann\u00e9e derni\u00e8re, j'ai aid\u00e9 une plateforme d'\u00e9checs \u00e0 r\u00e9agir en cas d'urgence, et son O&M \u00e9tait d'abord confiant : \u201cIl y a assez de bande passante et les r\u00e8gles du pare-feu sont superpos\u00e9es\u201d. Le r\u00e9sultat d'un coup d'\u0153il sur le moniteur : le processeur n'a pas explos\u00e9, le trafic n'a pas explos\u00e9, mais l'utilisateur est coinc\u00e9 en train de jurer. Finalement, l'analyse des paquets a permis de constater qu'il y a une IP lente toutes les 30 secondes pour envoyer un en-t\u00eate de paquet HTTP, la connexion est pinc\u00e9e dans les mains du mort qui ne la l\u00e2che pas, un serveur par des centaines de telles connexions pour \u00e9puiser les ressources. Ce type d'attaque HTTP lente (attaque HTTP lente)<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"gallery","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[150],"tags":[],"collection":[],"class_list":["post-985","post","type-post","status-publish","format-gallery","hentry","category-updates","post_format-post-format-gallery"],"_links":{"self":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/985","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/comments?post=985"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/985\/revisions"}],"predecessor-version":[{"id":1140,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/985\/revisions\/1140"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=985"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}